FR2919403A1 - Procede et dispositif de transformation de pages de la toile pour affichage de liens - Google Patents

Abstract

Le procédé de transformation de pages de la toile comporte, au cours d'une étape (1305 à 1350) de réception d'une page de la toile :- une étape (1315, 1320) d'extraction d'au moins un lien hypertexte du contenu de la page et- une étape (1312, 1320 à 1340) d'affichage de chaque lien extrait du contenu de la page.Préférentiellement, au cours de l'étape d'affichage, on associe au moins un lien extrait avec une représentation graphique et on affiche ladite représentation graphique sur un écran.Dans des modes de réalisation, au cours de l'étape d'extraction, on extrait au moins une dite représentation graphique du contenu de la page en cours de réception.Dans des modes de réalisation, on associe un lien avec une dite représentation graphique extraite du contenu de la page en cours de réception, en fonction de la résolution de l'écran d'affichage, de la vitesse de réception de la page et/ou d'une durée estimée de réception de la page.

Description

PROCEDE ET DISPOSITIF DE TRANSFORMATION DE PAGES DE LA TOILE POUR

AFFICHAGE RAPIDE DE LIENS

10 La présente invention concerne un procédé et un dispositif de transformation de pages de la toile. Elle s'applique, en particulier, à la transformation de pages de la toile destinées à être accédées par un ordinateur, en pages accessibles avec un terminal mobile communiquant présentant peu de ressources (capacité de traitement et mémoire, 15 notamment), comme, par exemple, un téléphone mobile ou une assistant numérique personnel doté de fonctions de communication mobile. Le succès de la toile est dû, en partie, au fait que le langage de description des pages, le HTML (acronyme de HyperText Markup language pour langage de balisage hypertexte) et le Javascript (langage de programmation des pages dynamiques) sont fournis 20 par les serveurs de la toile aux navigateurs sous forme de texte source. Cela a, d'une part, évité d'avoir à définir des représentations binaires qui auraient pu être dépendantes d'une plate-forme, et a permis, d'autre part, à n'importe quel utilisateur d'apprendre à créer des pages en examinant simplement les codes descriptifs des pages déjà disponibles. Mais cette approche impose une charge de travail importante au navigateur du 25 terminal destinataire car il doit analyser le code descriptif et du Javascript avant de pouvoir, respectivement, les afficher et les exécuter. Ce n'est pas une contrainte sur les ordinateurs personnels modernes disposant d'une forte puissance de calcul, d'une grosse capacité mémoire et d'une connexion réseau rapide, mais devient très problématique dans des environnements contraints comme les téléphones mobiles, notamment ceux d'entrée ou de 30 milieu de gamme. La présente invention vise à remédier à ces inconvénients. A cet effet, selon un premier aspect, la présente invention vise un procédé de transformation de pages de la toile, caractérisé en ce qu'il comporte, au cours d'une étape de réception d'une page de la toile : 35 - une étape d'extraction d'au moins un lien hypertexte du contenu de la page et - une étape d'affichage de chaque lien extrait du contenu de la page.

Grâce à ces dispositions, avant que le contenu entier de la page ait été reçu, l'utilisateur dispose déjà des liens lui permettant de naviguer vers d'autres pages ou animations. Il n'a donc pas à attendre la fin du chargement de la page pour passer à une autre page. L'utilisateur gagne donc du temps, notamment lorsqu'il connaît la page en cours de chargement et ne souhaite pas la visualiser. Selon des caractéristiques particulières, au cours de l'étape d'affichage, on associe au moins un lien extrait avec une représentation graphique et on affiche ladite représentation graphique sur un écran. Grâce à ces dispositions, la représentation des liens est plus intuitive et peut être normalisée. Selon des caractéristiques particulières, au cours de l'étape d'extraction, on extrait au moins une dite représentation graphique du contenu de la page en cours de réception. Grâce à ces dispositions, un site peut fournir des représentations graphiques à afficher, en tête du contenu de la page, afin d'aider les utilisateurs munis de terminaux de faibles capacités de réception, d'affichage et'ou de traitement de contenus. Selon des caractéristiques particulières, au cours de l'étape d'affichage, on associe un lien avec une dite représentation graphique extraite du contenu de la page en cours de réception, en fonction de la résolution de l'écran d'affichage. Selon des caractéristiques particulières, au cours de l'étape d'affichage, on associe un lien avec une dite représentation graphique extraite du contenu de la page en cours de réception, en fonction de la vitesse de réception de la page. Selon des caractéristiques particulières, au cours de l'étape d'affichage, on associe un lien avec une dite représentation graphique extraite du contenu de la page en cours de réception, en fonction d'une durée estimée de réception de la page.

Grâce à chacune de ces dispositions, un terminal muni de fortes capacités de réception, d'affichage et de traitement peut attendre la fin du chargement de la page pour l'afficher, par exemple en moins d'une seconde et, inversement, un terminal muni de plus faibles capacités peut bénéficier rapidement des moyens de naviguer à partir de la page en cours de réception.

Selon des caractéristiques particulières, à la fin de l'étape de réception de la page, on donne accès au contenu de la page par l'intermédiaire d'une représentation graphique dédiée, tout en maintenant l'affichage de liens extraits du contenu de la page. Grâce à ces dispositions, l'utilisateur peut commuter de l'affichage des seuls liens, éventuellement associés à des représentations graphiques, à l'affichage de la page complète.

Selon un deuxième aspect, la présente invention vise un dispositif de transformation de pages de la toile, caractérisé en ce qu'il comporte un moyen de réception d'une page de la toile et un moyen de traitement adapté, au cours de la réception de la page : - à extraire au moins un lien hypertexte du contenu de la page et - à faire afficher chaque lien extrait du contenu de la page. Selon un troisième aspect, la présente invention vise un programme d'ordinateur, caractérisé en ce qu'il comporte des instructions exécutables par un ordinateur pour implémenter le procédé objet de la présente invention, tel que succinctement exposé ci-dessus.

Selon un quatrième aspect, la présente invention vise un support d'information lisible par un ordinateur et comportant des instructions exécutables par un ordinateur pour implémenter le procédé objet de la présente invention, tel que succinctement exposé ci-dessus. Les avantages, buts et caractéristiques particulières de ce dispositif, de ce programme d'ordinateur et de ce support d'information étant similaires à ceux du procédé objet de la présente invention, tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques ressortiront de la description qui va suivre faite dans un but explicatif et nullement limitatif en regard des dessins annexés, dans lesquels : - la figure 1 représente, sous forme d'un logigramme, des étapes d'une communication mises en oeuvre dans au moins un mode de réalisation particulier du procédé objet de la présente invention, - la figure 2 représente, sous forme d'un logigramme, des étapes mises en oeuvre dans un mode de réalisation particulier du procédé objet de la présente invention, - les figures 3 et 4 représentent, schématiquement, des interfaces utilisateurs mises en oeuvre, sur un terminal utilisateur mobile, dans différents modes de réalisation du procédé objet de la présente invention, - les figures 5 et 6 représentent, schématiquement, des interfaces utilisateurs mises en oeuvre, sur un écran d'ordinateur, dans différents modes de réalisation du procédé objet de la présente invention, - la figure 7 représente, schématiquement, une infrastructure de communication unifiée mise en oeuvre dans des modes de réalisation particuliers de la présente invention, - la figure 8 représente, schématiquement, un serveur passerelle pour la mise en oeuvre d'un navigateur objet d'un des aspects de la présente invention, - la figure 9 illustre, sous forme d'un logigramme, des étapes mises en oeuvre dans un serveur de routage,. selon un aspect de la présente invention, - la figure 10 illustre, sous forme d'un logigramme, des étapes mises en oeuvre dans une application de conférence, - la figure 11 illustre, sous forme d'un logigramme, des étapes mises en oeuvre dans une création automatique d'application informatique, - la figure 12 illustre, sous forme d'un logigramme, des étapes mises en oeuvre pour une transformation de page de la toile pour son affichage sur un terminal mobile communicant et - la figure 13 illustre, sous forme d'un logigramme, des étapes mises en oeuvre pour une transformation de page de la toile pour affichage rapide de liens hypertextes sur un terminal mobile communicant. Dans toute la description, on utilise les définitions suivantes : - Application , un programme interagissant avec un contexte d'exécution, - Service , la réponse à la demande d'un utilisateur, indépendamment du contexte, par exemple obtenir un taxi , réserver une table . On observe qu'un web service (en français service de la toile ) est une application. On observe aussi que la mise en place du service requiert généralement celle d'applications et - mobile , un terminal mobile communicant, par exemple un téléphone mobile, un assistant personnel numérique (en anglais PDA , acronyme de personal digital assistant ) ou un smartphone qui rassemble des fonctions de téléphonie mobile et des fonctions d'assistant numérique personnel. La structure matérielle supportant les services mis en oeuvre par la présente invention est basée sur une architecture distribuée comprenant : - une partie de support (en anglais backend ), résidant sur un ensemble de serveurs, conjointement appelés, dans la suite de la description le serveur partie accessible, en ce qui concerne sa configuration, via l'Internet (voir figures 5 et 6), et -des parties dites mobiles , résidant sur des terminaux mobiles communicants, accédant au serveur via des liaisons données classiques offertes par les opérateurs de téléphonie mobile et/ou par des liaisons locales sans fil (par exemple, Bluetooth ou WiFi, marques déposées).

Un protocole, ou langage, de communication nouveau, défini pour la mise en oeuvre de la présente invention, nommé GML (acronyme de Goojet Markup Language pour langage de balisage Goojet, Goojet étant une marque déposée) et mettant en oeuvre des balises, gère les interactions entre le serveur et les parties mobiles. Ce langage est décrit en regard de la figure 1.

On note que le terme GML désigne le concept de structure de services arborescente et qui peut être matérialisé aussi bien par des représentations XML propriétaires ( Goojet ) que par des représentations normalisées HTML. C'est l'approche structure. Outre leur structure distribuée, ces services sont aussi originaux dans leur comportement qui se distingue de l'état de l'art des services mobiles existants par les caractéristiques suivantes : - ils sont centrés sur l'utilisateur (en anglais user-centric ), c'est-à-dire que le comportement et la présentation de ces services peuvent s'adapter à chaque utilisateur, par opposition à un comportement générique, - ils possèdent une ubiquité, c'est-à-dire que ces services sont conçus, dès leur naissance, pour être accédés aussi bien par un mobile (accès dit mobile ) que par un ordinateur connecté à Internet (accès dit web ), - ils sont communautaires : ces services permettent à plusieurs utilisateurs de partager, tant en lecture qu'en écriture, des données communes, quel que soit leur moyen d'accès (mobile ou web), et - ils mettent en oeuvre un espace navigable : ces services sont organisés entre eux par un mécanisme de référencement qui permet aux utilisateurs de naviguer dans l'ensemble de ces services par étapes successives à partir d'un mobile. La plate-forme ici décrite est hétérogène en ce qu'elle permet d'organiser, d'accéder et d'utiliser des services de différentes natures : - services simples d'accès à de l'information distante (texte, texte riche, photo, vidéo, musique, fils RSS, page web, ...), - services créés par la société gérante de la plate-forme, - services de médiation vers des services de la toile appartenant à des tierces parties, - services interactifs et transactionnels, basés sur un système de gestion de transaction de bout en bout, à état, entre les utilisateurs et les services distants et services créés par les utilisateurs eux-mêmes, par agrégation et configuration de briques unitaires en des touts complexe et personnalisés, ou par développement de services originaux selon les règles et interfaces fournies par la société propriétaire de la plate-forme. Les innovations offertes par la mise en oeuvre de la présente invention couvrent plusieurs domaines : - la structure des objets distribués et du protocole de communication (appelé GML et décrit dans un paragraphe annexé) qui, ensemble, permettent l'implémentation de services ou d'applications objets de la présente invention, - la structure qui permet d'organiser, de gérer et d'exploiter l'ensemble de ces services, cet ensemble étant appelé l'espace de services et comporte l'ensemble des noeuds et services de l'utilisateur et - certains services objets de la présente invention.

L'infrastructure est basée sur une interface homme-machine déportée sur mobile, un navigateur matriciel représentant trois fois trois icônes, un menu de la toile (en anglais web ) et une structure récursive. Un des fondements de l'architecture est la répartition intelligente du travail (traitements, données, présentations) entre le mobile et le serveur : chaque service est découpé en : - une partie présentation sur interfaces utilisateur, dont l'aspect et le comportement sont modélisés dans le langage GML, et - une partie lourde, sur le serveur, comprenant données, traitements de données et interfaces avec d'autres composants (services web externes, autres utilisateurs, ...).

La partie la plus lourde réside ainsi sur le serveur et est accessible via l'internet, d'une part, et via le mobile, d'autre part. Grâce à ce modèle, le mobile est déchargé des traitements lourds. Par ailleurs, chaque accès à un service donné est adapté à l'usager. Cette répartition des charges et cette synchronisation à la demande entre la toile (en anglais web ) et le mobile via le protocole GML est, en quelque sorte, une extrapolation adaptée aux mobiles, du modèle client léger avec un navigateur de la toile. Le runtime mobile peut ainsi être considéré comme un type nouveau de navigateur, spécifiquement adapté à la structure des services objets de la présente invention et à l'organisation de leur espace. On observe, en figure 1, une étape 100 de démarrage du service implémentant la présente invention, par exemple par sélection d'une application conservée par le mobile mis en oeuvre. Au moment de l'ouverture de l'application implémentant les servies objets de la présente invention, l'écran du mobile : - soit affiche un menu au format de la matrice 3x3, dit menu local d'accueil , présent dans le téléphone, - soit, ce qui est supposé dans la suite de la description de la figure 1, émet une requête à destination du serveur qui gère la navigation, pour lui demander, en langage GML, la page d'accueil à afficher pour l'utilisateur considéré, notamment lorsqu'il a été préliminairement identifié), au cours de l'étape 105. Dans ce deuxième cas, au cours de l'étape 110, le serveur fournit au mobile du code qui décrit au moins une matrice d'icônes, en langage GML. On note que la requête émise par le mobile au cours de l'étape 105 permet au serveur d'identifier l'utilisateur ou, tout au moins, une partie de son profil. La partie présentation est ainsi envoyée, sur requête de la part du mobile, depuis le serveur à destination du mobile. Cette partie présentation est interprétées immédiatement par ce mobile, dans lequel se trouve un environnement d'interprétation (référencé sous le code de runtime mobile ) du GML : au cours d'une étape 115, le mobile parcourt le code reçu au cours de l'étape 110 pour en extraire un modèle, ou page, à afficher. Au cours d'une étape 120, le mobile détermine, à partir d'un identifiant de l'utilisateur ou de son mobile, le modèle à afficher sur l'écran du mobile, comme page d'accueil personnelle de l'utilisateur. Cette page d'accueil est formée et paramétrée par l'utilisateur, comme exposé en regard des figures 5 et 6, préférentiellement par accès, avec un ordinateur, à un serveur de la toile ( web ) dédié. Au cours d'une étape 125, le mobile affiche le modèle trouvé, comme exposé en regard des figures 3 et 4, et met en mémoire par pré-chargement ( prefetch ) des modèles pouvant être appelés à partir de la page d'accueil de l'utilisateur. Au cours d'une étape 130, le mobile attend et détecte la sélection d'une touche sur son clavier. Dès la détection de la sélection d'une touche du clavier du mobile, le mobile traite la signification de la touche sélectionnée, ou commande au cours de l'une des étapes 140 à 150. Si la touche sélectionnée est l'une des touches numériques entre 1 et 9 , au cours d'une étape 140, le mobile traite le contenu de l'arborescence correspondant à cette touche et, si l'icône sélectionnée correspond à une application ne mettant pas en oeuvre de modèle, lance cette application. En revanche, si la touche sélectionnée concerne un nouveau noeud de l'arborescence ou un modèle d'accueil ou de navigation dans une application dite fruit de l'arborescence, un nouveau modèle est sélectionné et on passe à l'étape 155. Si la touche sélectionnée est 0 , le mobile retourne au premier modèle, correspondant à l'accueil personnelle de l'utilisateur, au cours d'une étape 150.

Si la touche sélectionnée est # , le mobile revient au modèle précédent, au cours d'une étape 145. Si deux touches sont sélectionnées simultanément, dont la touche # et un nombre i représenté par le nombre affiché sur l'une des touches entre 1 et 9 , on supprime, au cours de l'étape 145, de l'historique de navigation i modèle(s) précédent(s). Par exemple, si on est arrivé au quatrième modèle en venant du deuxième modèle, la commande # et 2 permet de supprimer de l'historique de navigation les deux derniers modèles affichés, c'est-à-dire de revenir au deuxième affiché. Ainsi le serveur est capable de gérer un historique de navigation pour l'utilisateur. Dans le cas où l'un des icônes affichés (voir figures 3 ou 4) correspond à une assignation de variable, ou paramétrage, la gestion des variables permet de déterminer un contexte ou un périmètre de fonctionnement du mobile. Ce contexte définit un environnement de validité de variables au cours de la navigation et les variables associées ainsi que leur valeur par défaut. A cet effet, l'utilisation d'une commande dite as:var:value , qui comporte la sélection successive de la touche du clavier du mobile associée à l'icône d'assignation de variable et d'une touche représentant une valeur var représentée par la valeur d'une touche, entre 1 et 9 , permet de positionner à la valeur value la variable var . Ainsi, à l'intérieur même du langage GML (et sans implémenter un nouveau langage coté client), on est en mesure d'interpréter une commande et de réaliser une opération simple. La valeur de la variable peut-être récupérée à l'intérieur du langage en utilisant les signes { et } . La valeur de var est ainsi représentée par {var} . A la suite de l'une des étapes 140 à 150, le mobile détermine, au cours d'une étape 155, s'il a, en mémoire cache, le modèle sélectionné, grâce au pré-chargement effectué au cours de l'étape 125. Si oui, on retourne à l'étape 125 pour afficher le modèle sélectionné et pré-charger les modèles auquel le modèle sélectionné peut mener. Sinon, on retourne à l'étape 105 pour requérir le modèle sélectionné auprès du serveur. La figure 2 représente des étapes mises en oeuvre dans un mode de réalisation du procédé objet de la présente invention. Au cours d'une étape 205, on met en correspondance des applications avec une arborescence, au moins une dite application provenant de la toile. Cette mise en correspondance est effectuée en trois étapes : - d'une part, étape 206, on crée des services, le créateur du service pouvant être soit un partenaire, soit le gestionnaire des services objets de la présente invention, soit un utilisateur, soit automatiquement, à partir d'un courrier électronique (ou email ) pouvant provoquer la création d'une application supportant un tel service. Cette création est généralement effectuée à partir d'applications génériques (ou métagoojets ), c'est-à-dire des applications génériques dont les paramètres ne sont affectés d'aucune valeur et qui, une fois paramétrés, deviennent des services (ou Goojet ). Par exemple, une application générique de météorologie appelée météo utilise comme paramètre une valeur de lieu et la réception d'un courrier électronique ayant comme titre météo Toulouse attribue la valeur Toulouse au paramètre de lieu, - d'autre part, étape 207, l'utilisateur copie/colle ( drag and drop ) des icônes ou graphismes disponibles représentant les services créés, par exemple dans des menus déroulants ou par l'intermédiaire d'une boîte de dialogue de recherche ou de catalogue dans une arborescence de matrices 3 x 3, comme exposé en regard de la figure 5 et - enfin, au cours d'une étape 208, l'utilisateur peut associer des icônes de service à des icônes d'autres utilisateurs (amis ou contacts) afin de leur proposer ces services ou réciproquement, copier/coller des icônes proposés par des amis ou contacts, comme exposé en regard de la figure 6.

A la suite de l'étape 208, les applications supportant les services et les arborescences sont conservées par le serveur. L'utilisateur dispose alors d'un espace personnel de navigation auquel il peut accéder soit par l'utilisation d'un mobile, soit par l'utilisation d'un terminal connecté à Internet.

Au cours d'une étape 210, l'utilisateur sélectionne l'application implémentant la présente invention. On suppose, ici, qu'il utilise un mobile. Selon les modes de réalisation, soit le mobile émet alors une requête à destination du serveur, pour lui demander la page d'accueil en vigueur pour cet utilisateur, soit la dernière page d'accueil mise en oeuvre est immédiatement affichée. On suppose, ici que la première variante est mise en oeuvre. Aussi, au cours d'une étape 215, le serveur, relié à une base de données d'applications, réceptionne une requête de navigation de la part du terminal mobile communicant. Au cours d'une étape 220, le serveur fournit au mobile, du code écrit en GML qui décrit au moins une matrice d'icônes. Parmi ces matrices, l'une constitue un écran d'accueil et est immédiatement affichée par le mobile. Au cours d'une étape 225, l'utilisateur effectue, avec son mobile, une étape de sélection de l'un desdits noeuds ou l'une desdites feuilles. Cette sélection est effectuée en pressant l'une des neufs touches du clavier allant de 1 à 9 , de manière homothétique avec ce qui est affiché sur l'écran. Par exemple, l'icône le plus en haut à gauche est sélectionné en pressant sur la touche 1 . Au cours d'une étape 230, le mobile communique au serveur, un identifiant du noeud ou de la feuille sélectionné. Au cours d'une étape 235, le serveur détermine si un noeud a été sélectionné. Si oui, le serveur retourne à l'étape 220 et fournit au mobile, des identifiants de noeuds ou feuilles descendants du noeud sélectionné et on effectue une nouvelle itération des étapes de sélection, communication et détermination de type d'icône sélectionné. Si le résultat de l'étape 235 est négatif, au cours d'une étape 240 le serveur détermine si une application provenant de la toile a été sélectionnée. Si oui, le serveur effectue le lancement de cette application sélectionnée, au cours d'une étape 245.

Sinon, au cours d'une étape 250, on met en oeuvre l'application conservée par le mobile qui a été sélectionnée. Dans le mode de réalisation décrit ici, au moins une telle application met en oeuvre comme interface utilisateur, la même disposition en matrice 3x3 associée à 9 touches du clavier du mobile. On décrit, ci-après, une navigation à neuf touches mise en oeuvre dans des modes de réalisation particuliers du procédé et du dispositif objets de la présente invention. Comme illustré en regard des figures 3 et 4, l'utilisateur voit, sur l'écran 310 de son terminal mobile 305, une succession de matrices 315 d'icônes 320 et peut très facilement sélectionner une des branches de l'arborescence puis une feuille ou un fruit (application utilisant le navigateur mobile défini ci-dessous) en terminaison de l'arborescence. On appelle navigateur mobile , tout navigateur dédié à l'espace des services, par exemple sous forme d'une matrice 3x3. Ce navigateur peut se retrouver sur tout type de support, de page de la toile, ou de terminaux. Cette navigation à neuf touches est une solution de navigation qui permet à un utilisateur d'utiliser les touches 330 1 à 9 d'un clavier numérique 325, par exemple de téléphone mobile, pour interagir avec une application affichant, sur l'écran 310 en vis-à-vis du clavier, neuf représentations 320 de fonctions, par exemple sous forme graphique et, plus particulièrement, sous forme d'icônes. Le système de navigation par neuf touches est générique et peut être utilisé sur n'importe quel dispositif, physique ou logique, tel qu'un téléphone mobile ou un gadget logiciel embarqué dans un site web ( widgets ). La description qui est faite ici, par souci de simplification, suppose que le dispositif d'accueil de ce système de navigation est un téléphone mobile, appelé, par la suite mobile . En effet, un téléphone mobile est particulièrement adapté à ce mécanisme du fait de son petit écran, qui implique une gestion adaptée de l'espace et de la navigation, d'une part, et du fait de la présence, sur son clavier, de touches numérotées de 1 à 9 , organisées selon une matrice 3x 3, d'autre part). Le but de la navigation par neuf touches et d'utiliser les touches numérotées 1 à 9 du clavier 325 du mobile 305 pour, d'une part, naviguer dans un espace de services locaux ou distants (notion de menu étendu) et, d'autre part, utiliser les services ainsi atteints. Cette navigation sert donc non seulement une interface de navigation mais aussi une interface d'utilisation de certaines applications, dites fruits , en extrémité de l'arborescence. L'allocation entre les touches physiques du mobile et l'interface se fait en utilisant une matrice 3x3, comme suit : 1 2 3 4 5 6 7 8 9 Parmi ces matrices, l'une constitue un écran d'accueil et est immédiatement affichée par le mobile, au cours de l'étape 125. Dans le cas illustré en figure 3 où au plus neuf icônes sont à afficher, cet écran est construit sous forme de matrice 3x3 (trois lignes de trois colonnes) correspondant, par homothétie, aux neuf chiffres 1 à 9 dans la matrice du clavier 325 du mobile 305. A chaque instant s'affiche donc, sur l'écran 310 du mobile 305 de l'utilisateur, une matrice 3x3 présentant neuf données, sous la forme de neuf icônes 320.

Lorsque plus de neuf icônes 320 sont à afficher, préférentiellement et comme illustré en figure 4, on n'affiche que six d'entre elles, par exemple sur la partie haute de l'écran (deux lignes de trois icônes) et les lignes suivantes sont affectées de la manière suivante : 8 == 0 # Les flèches 405 et 410 correspondant aux touches 7 et 9 permettent de faire défiler les icônes 320 affichés dans les deux premières lignes, parmi tous les icônes 320 à afficher dans la page considérée. Ainsi, lorsqu'un noeud sélectionné comprend plus de neuf icônes 320, seulement les six positions des deux lignes les plus hautes (2x3) sont affectées à des icônes 320 et les icônes 405 et 410 de la troisième ligne permettent de faire défiler les icônes 320 présents sur les deux premières lignes, le 7 étant associé à une flèche 405 vers le gauche (précédent) et le 9 étant associé à une flèche 410 vers la droite (suivant). La touche centrale 415 de la troisième ligne d'icônes, correspondant au 8 duclavier, n'est pas utilisée pour la navigation et reste disponible pour des fonctionnalités choisies par l'application. Ce type de noeud de navigation correspond à une représentation de deux lignes d'icônes sur un cylindre virtuel et permet de fabriquer une arborescence de navigation dont les noeuds comporte un nombre non limité d'options (icônes), tout en restant dans le même paradigme de navigation à un doigt . Le système adapte automatiquement le format d'affichage d'un noeud (3x3 ou cylindre virtuel) lors de l'ajout ou du retrait dynamique d'options descendant du même noeud, selon que leur nombre est inférieur ou égal à neuf ou supérieur à neuf. Dans le cas des téléphones mobiles, la navigation est aussi basée sur les touches 335 à 337 * , 0 et # , respectivement affectées aux fonctions de navigation suivante : - touche 335 * permet d'accéder à l'aide sous forme de texte superposé aux icônes, ces textes, très courts, explicitant brièvement le contenu représenté par chaque icône, - touche 336 0 permet de revenir directement à la page d'accueil courante pour l'utilisateur et - touche 337 # permet d'accéder directement à la page précédente. La sélection d'une icône mène à l'une des actions suivantes : - dans le cas où l'icône qui est sélectionnée par appui sur une touche du clavier est un noeud de navigation dans l'arborescence des services, on ouvre une autre page matricielle d'icônes (avec un maximum de 3x3 icônes) ; l'utilisateur naviguant ainsi à un niveau de profondeur supérieur, où, de façon récursive, il retrouve une matrice d'icônes ou - invocation d'une action terminale : l'icône sélectionnée correspond à une feuille de l'arborescence des services ; l'utilisateur est au bout de sa navigation en ce qui concerne le chemin suivi et invoque le service. Deux types d'actions terminales existent : - les actions atomiques : l'infrastructure de navigation dispose d'un certain nombre d'actions terminales atomiques possibles, qui, ensemble, permettent de construire un service, par agrégation successive et par organisation hiérarchique et récursive. Ces actions terminales atomiques comprennent (liste non limitative) : - télécharger et/ou afficher un texte, - télécharger et/ou afficher une photo, - télécharger et/ou jouer (streaming) un fichier de musique, - télécharger et/ou jouer (streaming) un ficher vidéo, -déclencher un appel téléphonique (avec 1 ou plusieurs personnes), -déclencher l'envoi de SMS (acronyme de short message system pour système de messages courts) ou de MMS (acronyme de multimedia message system pour système de messages multimédias), - déclencher l'envoi de messages électroniques ( mails ), - choisir dans une ou des listes et transmettre le choix au serveur, - remplir une forme ou un formulaire (en anglais template ) par saisi de données textuelle ou numérique, puis la transmettre au serveur et - invoquer un service web prédéfini. - les applications : une application est un ensemble de traitements et d'actions qui s'exécutent soit sur le mobile soit sur le serveur, éventuellement de façon interactive avec l'utilisateur, en fin de navigation, mais qui requièrent un niveau de sophistication plus élevé que des actions atomiques prédéfinies et qui doivent être effectués dans un même contexte. Une application peut ainsi être constituée de plusieurs choix successifs, de plusieurs remplissages d'information, et de plusieurs transactions avec le serveur, mais tout en restant en feuille de l'arborescence, c'est-à-dire en restant dans un contexte unitaire, sans navigation supplémentaire dans l'arborescence. Une application se distingue donc par son unité de contexte (au sens navigation) et par sa complexité, par opposition à action atomiques. On note qu'une application peut-être créée par agrégation de plusieurs actions atomiques dans le même contexte de navigation que décrit ci-dessus, c'est-à-dire avec des pages comportant, au plus neuf icônes associées aux neufs touches 1 à 9 du clavier.

Une telle application est donc intégralement modélisée par GML. On l'appelle aussi, dans la description, un fruit de l'arborescence.

Une application, toujours en feuille de navigation donc, peut aussi invoquer un exécutable mobile propre. De telles applications ne rendent donc pas leur service par interprétation de GML, mais utilise GML et l'arborescence récursive de services pour être rendu accessibles. A ce titre, la structure mise en oeuvre dans l'implémentation de la présente invention est, à la fois, un ensemble de services interprétés par GML et une structure d'organisation, qui peut comprendre des services hétérogènes (GML pur, ou comprenant une partie exécutable sur le mobile). Il est important de noter que la solution de navigation par neuf touches permet d'invoquer des applications et services natifs (comme, par exemple, dans le téléphone, le carnet d'adresses, la fonction d'appel, un jeu installé par le fabricant du téléphone, etc.) et des application/services distants, résidants sur la toile et qui requièrent donc une communication et une interaction avec des systèmes externes au téléphone. L'utilisateur utilise donc le même système de navigation pour tous les services et la localisation de l'application n'a plus d'importance pour l'utilisateur. C'est une notion de menu étendu, où le même paradigme de navigation et d'usage s'étend pour passer d'une navigation locale à une navigation distante, mais aussi d'une navigation à une action terminale au sein même d'une application. Le modèle de données permettant le mécanisme de navigation à neuf touches casse donc les frontière entre local et distant et entre navigation et exécution, permettant une vision unifiée et simplifiée de l'usage.

Préférentiellement, un appui long (d'une durée supérieure à une durée limite, éventuellement paramétrable) sur une des neuf touches, donne accès à un menu contextuel avec de l'aide sur le contenu associé à l'icône concernée par l'appui et des options, comme par exemple envoyé le service à un ami ou contact . Le système fait de la résolution par raccourcis d'adressage lors de la navigation, et peut se positionner sur la cible d'une navigation sans passer par les étapes (noeud de navigation) intermédiaires : par exemple, si un service se trouve sur la Rième position de la Qième position de la Pième position de la page courante, la navigation de base demande de presser P , puis Q quand la page (noeud) correspondante s'est affichée, puis R , etc. Le système offre un mécanisme de raccourcis qui permet de presser P , Q et R rapidement, actions suite auxquelles le système va directement chercher la position finale requise, économisant ainsi les étapes intermédiaires. Ce sont les raccourcis par compression . Le système permet aussi d'attribuer des raccourcis d'accès explicite pour les services accessibles par la navigation par neuf touches : Tors de l'organisation d'un espace navigable par le système de navigation à neuf touche, il est possible de spécifier au système le raccourci souhaité, et le système ira placer le service à l'endroit correspondant, si disponible, dans l'arborescence. Par exemple, on peut indiquer 63836 au système pour un service Météo (au niveau des touches sur un téléphone portable, 63836 peut correspondre aux lettres du mot météo ). Cette fonctionnalité permet à l'utilisateur d'accéder directement à un service sans savoir ou dans la structure se trouve le service ; ce sont les raccourcis mnémotechniques.

En ce qui concerne les contenus des menus, ils sont dynamiques. En effet, la structure de l'arbre de navigation est construite et stockée côté serveur. Ceci permet à l'utilisateur d'accéder à son arborescence de services à partir de plusieurs types de clients, comme par exemple un navigateur web sur un ordinateur de bureau : la structure est unique mais son accès est partagé et multimodal.

Si l'utilisateur effectue une modification de son espace de services en utilisant par exemple un site web, il peut immédiatement voir les modifications sur son téléphone portable. Pour l'aider dans cette modification (ou édition ) une fenêtre représente une matrice 3x3 similaire à celle qui sera affichée sur l'écran du téléphone mobile. Une fois la solution de navigation par neuf touches est installée, l'utilisateur peut ajouter et supprimer des services pour son téléphone, sans besoin de changer la configuration de son téléphone ni d'installer des logiciels supplémentaires. Le système de navigation permet d'envoyer plusieurs pages à la fois au téléphone. Avec un système de cache sur le téléphone, le système n'a pas besoin de contacter le serveur quand l'utilisateur navigue entre les pages. Une navigation sur des services distants peut donc être momentanément locale au téléphone, réduisant ainsi la latence d'accès aux services. Le système marque les informations dynamiques qui doivent être rafraîchies lors d'une navigation en cache. Par ailleurs, lors de la définition d'un service ou d'une espace (ensemble de noeuds de navigation et de services formant un tout cohérent, conceptuellement similaire à un portail thématique), il est possible de marquer plusieurs noeuds ou services unitaires comme corrélés pour en forcer le chargement en une seule requête atomique sur le téléphone. L'ensemble de données ainsi chargé lors de l'accès au point d'entrée dans ce service ou espace est donc plus lourd que la simple donnée correspondant à ce point d'entrée, mais la corrélation a été établie pour permettre ensuite une navigation locale (en cache) sans requête supplémentaire au serveur, diminuant ainsi la latence globale de la navigation au travers de ce service ou de cet espace. Le système tient un journal exhaustif de toute navigation par tout utilisateur au travers de l'arborescence gérée par ce processus de navigation à neuf touches . Ce journal permet de définir, de façon dynamique, le profile de chaque utilisateur en fonction de sa navigation. Ce profile est ensuite exhibé par le système pour des utilisations tierces et externes, comme par exemple l'envoi ciblé de message à certains utilisateur en fonction de leur profil. Mais ce mécanisme de calcul profile de profile est aussi utilisé de façon interne et intrinsèque au procédé de navigation à neuf touche, par le biais d'un algorithme de prefetching basé sur le profil de navigation : des chemins statistiques de navigation sont calculés pour chaque utilisateur et les noeuds ou services successifs des chemins statistiques de navigation les plus fréquents sont corrélés dynamiquement pour chaque utilisateur, de sorte ce que l'entrée dans un tel chemin par un utilisateur déclenche le chargement atomique en cache de N niveau de navigation sur le dit chemin. L'objet étant une fois de plus de réduire le nombre de requête entre le navigateur et le serveur et donc de réduire la latence globale. Le nombre N de niveau est calculé en fonction de la fréquence du chemin et de la mémoire disponible sur le cache. La fréquence du chemin est la donnée principale du profil (par exemple, le profile détermine que l'utilisateur Lambda, lors de son accès au noeud N1, va ensuite dans X% des cas accéder au noeud ou service N2, puis dans Y% des cas accéder au noeud N3, etc. Un tel calcul mène à la définition d'un poids statistique, aussi appelé fréquence, pour chaque noeud du chemin de navigation û dans ce cas le poids du noeud N3 est X*Y à partir du noeud Ni pour l'utilisateur Lambda). La taille du cache disponible, elle, est connue grâce au profil statique du navigateur (en fonction du mobile qu'il utilise pour naviguer, dont les caractéristiques sont connues dans une base de données dite de profiles statiques). L'algorithme de prefetching , basé sur le profil, corrèle dynamiquement (c'est-à-dire que cette décision de corrélation est recalculée après chaque navigation) pour l'utilisateur, tous les noeuds du chemin de navigation dont la fréquence est supérieure à un seuil (par exemple 80%, variable d'ajustement du système) et tant que la mémoire cache le permet. Cette décision de corrélation sur profil de navigation peut être ensuite affinée par deux algorithmes supplémentaires. Le premier, appelé super profil est relatif à un profil de groupe. Pour simplifier les calculs et rendre le système globalement plus performant, le système de profile crée aussi des schémas de navigation de groupe , permettant de faire du prefetching proactif pour un utilisateur n'ayant pas encore parcouru un certain chemin : les profiles de tous les utilisateurs sont comparés entre eux et des profils de comportements sont définis. Un super profil, pour un chemin donné, est un profil de navigation qui correspond, dans la limite d'un écart variable d'ajustement du système, au profil de navigation de plusieurs utilisateurs. Ces utilisateurs sont alors regroupés ensemble sur la base de l'homogénéité de leur navigation dans un certain nombre de chemins. Lorsqu'un utilisateur est considéré comme appartenant un super profil, sur la base de son comportement de navigation sur N chernins, et qu'il va naviguer pour la première fois sur un N+1 ième chemin, et s'il existe un profil type de navigation pour ce chemin N+1 dans le super profil auquel adhère cet utilisateur, alors le système va pro-activement corrélé les éléments dudit chemin pour ledit utilisateur, en fonction de ce super profil, bien que cet utilisateur n'ai encore jamais navigué sur ce chemin.

Le second algorithme supplémentaire concerne une corrélation personnalisée : l'utilisateur a la possibilité de forcer le prefetching , c'est-à-dire la corrélation d'éléments de chemin de navigation, lors de la gestion de son arborescence de navigation. Le concept est similaire à celui d'utilisation de caches et de corrélations, sauf que, précédemment, la corrélation concernait un ensemble d'éléments constituant, ensembles, un tous homogène et corrélé donc de façon générique pour tous ces utilisateurs, alors qu'ici l'utilisateur peut décider de corréler, pour lui uniquement, des éléments de son arborescence qui n'ont pas, à priori, de corrélation d'usage. Ce n'est que la personnalisation de ses chemins de navigation et non l'agrégation d'éléments en un tout homogène.

La gestion intelligente du cache et lies différents algorithmes de prefetching ont pour motivation principale la réduction du nombre des requêtes entre le navigateur et le serveur, pour améliorer globalement l'expérience de l'utilisateur (la latence est moindre car la navigation est aussi locale que possible). Une autre motivation importante de la navigation locale en cache est le mode déconnecté : la fraction de l'arborescence qui est chargée en cache reste accessible au procédé de navigation à neuf touches même en cas d'absence, volontaire ou involontaire, de connexion entre le navigateur et le serveur. Le procédé de navigation indique clairement au navigateur que certaines données sont potentiellement obsolètes mais permet leur usage en local en l'absence de connexion. Les données sont ensuite rafraîchies à la demande lors de la prochaine navigation en mode connecté. Ce procédé, utilisé conjointement avec le procédé de corrélation personnalisée décrit ci-dessus, permet, entre autres, de charger en mémoire, en une seule requête, un ensemble de données explicitement identifiées et organisées dans l'arborescence globale comme un ensemble de données, à priori hétérogènes et dispersées, et de les garder en mémoire. En cas de déconnexion, la partie de l'arborescence qui n'était pas chargée en mémoire n'est plus accessible par le procédé de navigation à neuf touches (jusqu'à la prochaine connexion) mais les données en cache restent accessibles via le même mécanisme de navigation et d'utilisation. La structure qui permet d'organiser, de gérer et d'exploiter l'ensemble des services est appelé un espace . Quand un utilisateur définit des services ou applications ou espace ou partie d'un espace, il peut indiquer l'audience souhaitée pour ces éléments, parmi les choix suivants : - publique : tout le monde a accès et donc tout les utilisateurs de la plate-forme peuvent augmenter leur propre espace de services en faisant référence, dans un des noeuds ou feuille de leur arbre, à cet élément; - privée : ce service ne peut-être navigué et utilisé que par l'utilisateur lui-même, - communautaire : ce service peut-être référencé (et donc navigué et utilisé) par un ou des ensembles d'utilisateurs désigné(s) par le créateur du service. Outre la capacité de partage, cette possibilité donne une caractéristique dynamique importante à l'espace de services et à sa navigation : un utilisateur peut faire référence, dans son propre espace, à une partie publique de l'espace d'un autre utilisateur, qui peut s'enrichir, l'autre utilisateur ajoutant des branches ou des services qui se trouvent ajoutés également à l'espace navigable du premier utilisateur. Un utilisateur peut, aussi, à son tour, faire référence à une partie publique ou communautaire d'un troisième, etc. De proche en proche, les espaces peuvent donc avoir une intersection ou s'inter- polléniser , permettant une navigation par affinités successives dans un espace vivant, dynamique et ouvert, bien que restant contrôlé et toujours user-centric . En ce qui concerne la promotion de la plate-forme, comme on l'a vu, l'espace d'un utilisateur est une arborescence, avec ses branches publiques ou privées, choisies et/ou définies par l'utilisateur via une interface web. Cette arborescence devient navigable via son mobile et mène, en ses feuilles, à une collection de services. Le fait que certaines de ces branches soient des références à d'autres branches publiques crée un premier niveau de dynamisme dans la structure de l'espace de cet utilisateur, car les branches publiques qu'il référence peuvent évoluer. Lors d'une navigation dans une arborescence, par le procédé de navigation à neuf touches, l'utilisateur peut, à tout moment, marqué un service (ou un noeud de navigation) visité comme préféré (notion de bookrnark ). La référence d'un élément ainsi marqué sera dupliquée, par le système, dans une branche prédéfinie de l'arborescence (branche appelée préférences définie dans l'espace administration , lui-même présent, par exemple, en icône 1 dans la page d'accueil de tout utilisateur. L'utilisateur peut donc à tout moment, en navigant simplement dans sa branche préférences , retrouver un accès direct à tout élément qu'il aurait découvert lors de ses navigations. En ce qui concerne la réception d'un nouvel élément dans l'arborescence, comme exposé plus haut, l'arborescence est dynamique et peut donc grandir et être modifiée. Par ailleurs, et en complément à cet aspect dynamique, le procédé de gestion d'arborescence comprend, pour chaque utilisateur, une branche de navigation dédiée pour la réception d'élément nouveau (noeud ou service). De façon conceptuellement similaire à la branche dédiée aux références d'éléments préférés, le procédé de navigation à neuf touches dispose dans un espace identique pour chaque utilisateur, d'une branche référençant les éléments reçus par chaque utilisateur. Cela permet à l'utilisateur de parcourir un chemin simple et constant pour découvrir les éléments nouveaux ajoutés à son espace. On note que, comme pour les éléments référencés dans la branche de préférences , les éléments référencés dans la branche de réception d'éléments nouveaux peuvent être, s'il le désire et quand il le désire, ranger par chaque utilisateur à un endroit qu'il juge pertinent dans son arborescence û donc y compris nulle part si l'élément concerné n'est pas ou plus intéressant pour l'utilisateur ; ce rangement à pour effet de supprimer la référence des branches de préférence ou de réception concernées.

En ce qui concerne la récursivité, dans la structure mise en oeuvre, le modèle est ouvert. A chaque objet (action atomique, noeud de navigation ou application) est attaché un identifiant et un icône. Une action terminale atomique est un service. Une application sophistiquée est aussi un service. Un noeud de l'arborescence ouvre une porte sur d'autres noeuds et/ou des services. Un service peul: donc, par extension du modèle, être un sous espace, une branche complète, dans laquelle sont ensuite organisés plusieurs autres niveaux de services, plusieurs autres branches, etc. Par analogie à la sémantique du web, un service complexe qui agrège plusieurs autres services, voire plusieurs branches de services, peut aussi être appelé un portail . En ce qui concerne l'espace de services d'un utilisateur et la personnalisation de cet espace, il est conservé dans une base de données de services, chacun d'entre eux étant potentiellement constitué par l'agrégation arborescente d'autres services. Chaque utilisateur défini ensuite son propre espace de service, qui est la mobilisation d'un sous-espace de service défini pour cet utilisateur : l'espace de services d'un utilisateur est donc une arborescence de services, organisée selon les même règles structurantes que l'espace global (donc à base de matrices, de récursivité, de noeud, d'actions atomiques et d'applications). On observe, en figure 5, que, lors de l'accès à l'interface utilisateur 500 des services objets de la présente invention, à partir d'un ordinateur (ou d'un terminal disposant d'un écran de résolution suffisante), l'utilisateur dispose d'une liste 505 de services, représentés par des icônes 510 et d'une représentation 515 simulant l'organisation en matrice 3x3 telle qu'elle sera affichée sur le terminal mobile lors d'un accès à partir de ce terminal mobile. Cette représentation 515 comporte des cases 520 prédéfinies dans la matrice 3x3. Pour sélectionner un service et l'incorporer dans l'arborescence, dont on rappelle qu'une matrice 3x3 représente les descendants d'un même noeud, l'utilisateur se place, d'abord, dans la partie de l'arborescence où l'icône doit être insérée, en utilisant la représentation 515 comme s'il utilisait un mobile pour naviguer. Puis, l'utilisateur effectue un drag and drop (sélection et déplacement symbolisée par une flèche en figure 5) d'une icône se trouvant dans la liste 505. En d'autres termes, après avoir disposé le pointeur d'un dispositif de pointage, tel qu'une souris, sur une icône 510, de la liste 505, l'utilisateur clique sur le bouton gauche du dispositif de pointage et déplace le pointeur jusqu'à la case 520 de la matrice 515 où il souhaite voir cette icône, puis il relâche le bouton gauche du dispositif de pointage. On observe qu'un menu déroulant (non représenté) permet à l'utilisateur de naviguer, dans la liste 505. Comme on l'observe en figure 6, pour soumettre un service à un correspondant (généralement appelé ami ), l'utilisateur effectue la même procédure de drag and drop depuis la représentation 515, vers une représentation 610 de ses correspondants (en figure 6, trois correspondants sont représentés par les lettres A à C ). L'utilisateur définit cette arborescence via une interface web qui met à sa disposition plusieurs outils de construction intuitive de son espace. Une fois crée sur le site web, cette arborescence est dite mobile , c'est-à-dire accessible par mobile, grâce au protocole GML. L'utilisateur pourra ensuite, quand il le souhaite, revenir, sur cette interface web pour éditer son espace de services. La base (racine) de cette arborescence sera la page d'accueil de l'application supportant les services, sur l'écran du mobile de cet utilisateur. De cette page, l'utilisateur peut donc ensuite naviguer dans son espace de services. Cet espace est constitué par l'utilisateur : l'utilisateur a choisi les services auxquels il désire accéder par l'intermédiaire de son mobile et les a organisé selon ses goûts. Son espace de services n'est donc pas l'intégralité de l'espace de service universel, ou global, mais un sous ensemble, organisé selon les goûts et besoins de chaque utilisateur. L'intérêt de cette vue user centric (donc filtrée) du monde global est très différente de la vue globale de l'Internet tel que donnée par les navigateurs web classiques s'appuyant sur le protocole WAP. L'importance de cette vue filtrée et user-centric vient de la différence fondamentale de comportement d'usage entre une situation web (où l'utilisateur dispose d'un certain confort et en général d'un certain temps, et où il attend donc complétude et richesse lors de sa navigation) et une situation de mobilité (où l'utilisateur dispose d'un terminal plus limité et probablement d'un environnement plus pressant, et où il demande vitesse, facilité et pertinence) ; cette vue filtrée d'un monde global navigable, dépendant de l'utilisateur (en anglais user-dependent ), est une des caractéristiques préférentielles de la mise en oeuvre de la présente invention et repose, d'une part, sur l'organisation matricielle récursive modélisée par le GML et, d'autre part, sur des services de paramétrage et de profilage (en anglais profiling ) qui permettent d'extraire des vues personnalisées. Par référence au paragraphe sur la récursivité, ci-dessus, on comprend que l'espace personnel d'un utilisateur étant constitué d'une arborescence de services est lui-même un service.

En ce qui concerne la gestion intelligente du cache, d'un point de vue exécution, cet arbre qui représente l'espace de services propre à un utilisateur donné est maintenu dans le serveur ; sa représentation est envoyée au mobile à la demande, en fonction de la navigation de l'utilisateur : lorsque l'utilisateur invoque un service sur son mobile, le système lui envoie (toujours via GML) la représentation de sa page d'accueil, à partir de laquelle il peut naviguer et invoquer des services. Au fur et à mesure de cette navigation et de ses invocations, le serveur, via GML, envoie au mobile les représentations nécessaires (pages suivantes de services et noeuds dans l'arborescence, représentation des actions terminales requises, etc). Cet envoi GML d'information de représentation est dynamique et s'appuie sur une gestion intelligente du cache : le système optimise les échanges entre les mobiles et le serveur en faveur de l'expérience utilisateur, c'est à dire pour réduire les temps de latence lors de la navigation. Typiquement, cela met en oeuvre des algorithmes de prefetching (prévision de choix à venir) qui s'appuient sur le profile d'usage de l'utilisateur ainsi que sur la structure de son espace de services : lors de l'envoi d'une page représentant neuf services, si, en général, lors de son passage sur ce noeud, l'utilisateur va ensuite dans plus de 80% des cas sur la case 4 du noeud suivant puis invoque ensuite l'action terminale 7 , au moins deux pages de ce chemin seront pré-chargées ( prefetch ) lors de la première invocation (préchargement en profondeur). Si, par contre, le système ne sait pas vers où l'utilisateur va probablement naviguer, le système va pré-charger, en largeur, l'intégralité (ou le maximum, selon les capacités du mobile) des représentations de services du niveau suivant. En ce qui concerne la personnalisation des services, les profils explicites et les profils inférés, au-delà de l'aspect de la création d'une vue personnelle à chaque utilisateur de l'arbre global, le système permet aussi d'adapter le comportement final, c'est-à-dire l'action terminale ou l'application qui est invoquée en fin de navigation. Ainsi les actions terminales comprennent en général des paramètres qui peuvent être choisis pour l'utilisateur, soit explicitement par l'utilisateur lors de sa définition et de l'optimisation de son propre espace, soit automatiquement par lesystème, se basant alors soit sur des données de préférences indiquées par l'utilisateur lors de la définition de son profil, soit sur des inférences par le système basées sur le comportement dynamique de l'utilisateur lors de sa présence dans son espace de services. Typiquement, si un utilisateur navigue souvent sur des branches ou utilise souvent des actions terminales faisant référence à Paris , on lui proposera un paramétrage utilisant Paris s'il vient à naviguer sur une action terminale de location de voiture. En ce qui concerne les branches privées, les branches publiques, l'évolution dynamique d'un espace de services et la navigation par affinités successives, quand un utilisateur définit des services (ou branches de services, ou portails de services), il peut indiquer l'audience de ces services. - publique : tout le monde à accès et donc tout les utilisateurs de l'application supportant les services peuvent augmenter leur propre espace de services en faisant référence, dans un des noeuds ou feuilles de leur arbre, à ce service ; privé : ce service ne peut-être navigué et utilisé que par l'utilisateur ou - communautaire : ce service peut-être référencé (et donc navigué et utilisé) par un ou des ensembles d'utilisateurs désigné(s) par le créateur du service. Outre la vertu du partage, cette possibilité donne une caractéristique dynamique importante à l'espace de services et à sa navigation : un utilisateur peut faire référence, dans son propre espace, à une partie publique de l'espace d'un autre utilisateur, qui peut s'enrichir, l'autre utilisateur ajoutant des branches ou des services qui, par transitivité, se trouvent ajoutés également à l'espace navigable du premier utilisateur. Un utilisateur peut, aussi, à son tour, faire référence à une partie publique ou communautaire d'un troisième, etc. De proche en proche, les espaces peuvent donc avoir une intersection ou s'inter- polléniser TN, permettant une navigation par affinité successive dans un espace vivant, dynamique et ouvert, bien que restant contrôlé et toujours user-centric. En ce qui concerne la promotion des services, comme on l'a vu, l'espace d'un utilisateur est une arborescence, avec ses branches publiques ou privées, choisies et/ou définies par l'utilisateur via une interface web. Cette arborescence devient navigable via son mobile et mène, en ses feuilles, à une collection de services. Le fait que certaines de ces branches soient des références à d'autres branches publiques crée un premier niveau de dynamisme dans la structure de l'espace de cet utilisateur, car les branches publiques qu'il référence peuvent évoluer. Un deuxième niveau de dynamisme est offert par le mécanisme dit de InGoojet : dans tout espace de tout utilisateur, une branche est réservée par le système supportant l'implémentation de la présente invention, pour ajouter dynamiquement des services à disposition de cet utilisateur : c'est une extension du concept de boite aux lettres, mais structurée pour des référencements à des services. Cette branche réservée est structurée de façon linéaire : en première page, elle ne contient que deux représentations de services : un service vide , qui est une place réservée au premier service qui sera envoyé à cet utilisateur (service vide dit place holder ) et un second service formant noeud qui mène simplement, en seconde page, à une page structurée de la même façon que la première (ce service noeud est donc un service suivant ), et ainsi de suite, récursivement, selon les besoins. Cela permet à l'utilisateur de naviguer simplement linéairement dans cette branche, dont la taille varie dynamiquement en fonction des services qu'il y reçoit.

Des services peuvent être envoyés à des utilisateurs par des actions de promotions : sur le site web ou via son mobile, un utilisateur peut décider de partager un service avec un autre utilisateur ou avec une communauté d'utilisateur et ainsi promouvoir ce service, dont la référence sera alors ajoutée dynamiquement par le serveur sur les représentations des arborescences de chaque récipiendaire, en bout de liste de la branche InGoojet . Chaque utilisateur a ainsi immédiatement accès à un nouveau service. Il peut, s'il le souhaite, le faire disparaître de sa branche InGoojet ; il peut aussi, via l'interface web, réorganiser son espace de services et mettre ce service, s'il souhaite le conserver, à une autre place dans son propre espace de services. En plus de son utilisation dans le cadre de promotion ou d'échange de services, cette branche dynamique InGoojet est aussi utilisée directement par l'utilisateur s'il souhaite ajouter l'accès à un service dans son espace de services sans, pour autant, avoir accès à une interface web (qui est, comme décrit plus haut, le moyen nominal de création et de gestion d'un espace de services). Ce besoin peut être opportuniste et urgent : le système met donc à la disposition de l'utilisateur, via son interface mobile et en complément de l'interface web, un service spécial appelé Goojet Picker qui permet à l'utilisateur de sélectionner un service dans la base de services en saisissant son identifiant unique. La référence du service ainsi sélectionné sera ajoutée dans la InGoojet de l'utilisateur, comme pour un service reçu par promotion d'un tiers. La notion fondamentale associée à cette capacité de promotion ou de visibilité d'un service goojet picker est la mise en place d'un annuaire de services propre au système implémentant la présente invention. En d'autres termes, le système définit le GRL (acronyme de Goojet Ressouce Link ou lien de ressource Goojet). Le GRL est un identifiant multimodal qui permet d'accéder à un service à la fois mobile et Web unique. Sur le Web, le GRL prend sa source après la notion d'URL (www.goojet.com). Sur le mobile, cela donne accès directement à un ensemble de ressources/applications authentifiées par l'organisme gérant les services objets de la présente invention et représentées sur une icône qui peut se trouver dans des arborescences différentes suivant les mobiles qui la référence mais qui au demeurant référence la même ressource unique. Lorsqu'un utilisateur crée un service, on lui attribue un identifiant unique (GRL). Cet identifiant lui réserve une entrée unique dans l'annuaire des services. Le serveur donne accès aux informations sur la propriété du service, par un mécanisme de Whols .

Un exemple qui illustre l'intérêt du mécanisme est celui d'un service Restaurant . On peut avec la plate-forme de services, créer une application qui permette de renseigner un restaurant (lieu, menus, prix, coordonnées) et à la fois d'effectuer une réservation pour ce dit restaurant. S'il est possible à quiconque sans gage d'unicité de la part de la plate-forme de se créer un service Restaurant , on peut se retrouver avec une incohérence majeure en situation de mobilité (réserver un restaurant qui n'est pas celui escompté). De façon similaire à InGoojet , le système met à disposition de l'utilisateur un troisième niveau de dynamisme : le marque page, ou bookmark . Le bookmark est une structure linéaire en tout point similaire à InGoojet , dans laquelle s'ajoutent, de façon dynamique, les références aux services que l'utilisateur veut rendre immédiatement disponible. Le bookmark est particulièrement utile quand l'utilisateur navigue une branche inconnue de l'espace (typiquement une branche publique à laquelle il aura eu accès par navigations publiques successives) et y trouve un service intéressant. Le fait de le marquer, ou bookmarker , lors de son passage, envoie la référence dans la InGoojet , pour accès immédiat et pour réorganisation ultérieure éventuelle lors de l'utilisation, par l'utilisateur de l'interface web. En ce qui concerne la création de services, le système permet à l'utilisateur de créer son propre espace mobile en sélectionnant et agrégeant des actions atomiques, des services, des branches de services ou des espaces publiques entre eux, dans une organisation arborescente qui lui sied. Utilisant ces mêmes mécanismes de sélection, de paramétrage et d'agrégation, l'utilisateur peut aussi créer des services (ou sous espace de services) non pas nécessairement pour les référencer dans son espace propre, mais pour les mettre à disposition des autres utilisateurs. Ainsi, le système offre la capacité nouvelle à un utilisateur, par agrégation et paramétrage d'éléments préexistants, de créer de nouveaux services, qui seront disponibles à d'autres utilisateurs mobiles, sans avoir eu à développer de code informatique ni avoir eu à distribuer, par un quelconque canal, des applications mobiles. L'espace global de services est donc ouvert à la navigation mais est aussi ouvert à la contribution et affranchit l'utilisateur des étapes réputées complexes liées, en l'absence de la mise en oeuvre de la présente invention, à la création, la distribution et l'exploitation d'applications mobiles. En ce qui concerne les communautés explicites et les communautés inférées, au même titre que les profiles utilisateurs peuvent être explicites ou inférés, les communautés (pour déclaration de droit d'accès à des branches, pour promotions de services, par exemple) peuvent être : - explicites, c'est-à-dire définies par listes explicites d'identifiants d'utilisateurs ou de numéros de mobiles, - inférées, c'est-à-dire calculés, en temps réel, par le système en se basant sur des statistiques d'usage et de comportement. Typiquement, une telle inférence utilise un calcul de distance sémantique entre les utilisateurs : se basant sur le type de navigation et le type de services utilisés, le système identifie dynamiquement des communautés d'usage (sportifs habitant à Paris, adolescents aimants le rock'n roll, etc). Ces communautés inférées sont utilisées pour la promotion pertinente de services, pour divers services communautaire (par exemple, recherche de partenaire au tennis, service de covoiturage, etc) et, pour permettre, lors d'opérations commerciales de partenaires commerciaux, d'atteindre avec pertinence le publique optimal pour leurs messages et promotions. Le serveur fait donc de l'acquisition constante de données sur tous les utilisateurs et tous les services pour nourrir des algorithmes de profilage (en anglais profiling ), dont les résultats sont ensuite utilisés pour la personnalisation des services et espaces de services et pour l'envoi pertinent d'information ou de services. Cette capacité est un des piliers de l'exploitation commerciale du système. En ce qui concerne l'ubiquité web -- mobile, les services définis sur l'infrastructure mise en oeuvre ont pour vocation d'être référencés dans des arborescences accessibles de mobiles pour ainsi offrir des services en situation de mobilité. Mais la structure de ces services les rend également accessibles par internet (via un navigateur web). Cela permet aux utilisateurs de partager informations, données et services quel que soit leur moyen d'accès. Par ailleurs, le système reconnaît le moyen d'accès à un service et offre un niveau de richesse différent selon le moyen d'accès utilisé. Par exemple, le serveur supportant une application de vote affiche simplement le résultat courant du vote lors d'un accès mobile, alors qu'il offre une grande variété d'analyses statistiques et historiques lors d'un accès web.

La figure 7 représente, de manière schématique, une infrastructure de communication unifiée 701, aussi appelée ICU . Cette infrastructure permet de traiter quatre types flux de messages standards (IM pour instant messaging ou messagerie instantanée, SMS, courrier électronique et communication vocale), ainsi que celui fourni par une plate-forme communautaire propriétaire. L'infrastructure ICU fournit des passerelles entre ces types de flux (entrants/sortants). L'infrastructure comporte : une passerelle 702 vers et depuis des services de transmission de voix, notamment sur internet, une passerelle 703, vers et depuis des services de messages courts SMS, une passerelle 704, vers et depuis des serveurs de courrier électronique, le serveur 705 conservant les logiciels et données pour la mise en oeuvre de la présente invention et supportant l'infrastructure 701, et une passerelle 706, vers et depuis des services de messagerie instantanée. Dans des modes de réalisation, l'ICU 701 gère un routage (fonction connue sous le nom de transfert ou forward ) conditionnel en fonction : de l'identité de l'émetteur du message, - d'une période donnée (heure, jour ...), - d'éléments de contenu et/ou d'un signal de présence (si le destinataire est identifié comme présent sur un des canaux configurés dans le routage, le message est d'abord ou uniquement émis sur ce canal).

L'ICU peut aussi gérer un workflow de routage. Cela signifie qu'il existe un niveau de priorité d'émission pour chaque canal et un temps d'attente entre chaque émission. Cette fonctionnalité évite de dupliquer le contenu du message si l'utilisateur considère que dès l'instant où il l'a acquitté, il ne souhaite pas le voir sur un autre médium.

L'ICU peut permettre la gestion (création/modification/suppression) de tout ou partie d'applications telles que décrites dans l'exposé de la création d'applications riches à la volée. L'ICU 701 réalise ainsi, dans un serveur de routage, comme illustré en figure 9 : une étape 910 de réception de données à transmettre, lesdits données étant associées à un identifiant du destinataire, - une étape 915 de détermination d'un contexte de transmission des données au destinataire, - une étape 920 de sélection d'au moins un canal de réception associé audit destinataire en fonction du dit contexte et - une étape 925 de transmission des données sur chaque canal de réception sélectionné. Ainsi, le canal, ou les canaux, utilisé(s) pour transmettre les données au destinataire varie en fonction du contexte. Au cours de l'étape 915, le contexte de routage est représentatif : d'un identifiant (adresse unique sur un canal, adresse électronique, adresse de courrier électronique, numéro de téléphone, par exemple) de l'émetteur des données à transmettre, d'un horodatage des données à 'transmettre, par exemple leur heure et minute de réception par le serveur, - du contenu des données à transmettre, - d'un accès à un canal disponible pour l'utilisateur (c'est-à-dire l'information, pour chaque canal, que l'utilisateur est connecté au support de ce canal), et/ou - d'une priorité de canaux. Ainsi, par exemple : l'utilisateur peut demander que les données en provenance d'au moins un interlocuteur lui soient transmises sur un canal prédéfini ou sur l'ensemble des canaux permettant la transmission des données, par exemple, - inversement, les autorités ou un supérieur hiérarchique du destinataire peuvent obtenir que toute donnée de leur part soit transmise par tous les canaux de réception associés à l'utilisateur, l'utilisateur peut demander que les données lui arrivant aux heures de bureau lui soient transmises sur un canal prédéfini alors que les mêmes données arrivant en dehors des heures de bureau lui seront transmises sur un autre cana prédéfini, - l'utilisateur peut demander que les données d'un message comportant une référence particulière (par exemple un numéro de dossier) lui soient transmises sur un canal prédéfini, lorsque l'utilisateur n'a pas d'accès au réseau téléphonique mobile, par exemple, il peut obtenir que les données lui soient transmises sur une ligne fixe, et/ou l'utilisateur peut demander que les données d'un message lui soient transmises sur un premier canal prédéfini, qu'en l'absence d'acquittement de réception de sa part dans un délai prédéterminé, elles lui soient transmises sur un deuxième canal prédéfini et ainsi de suite. On évite ainsi de dupliquer le contenu du message sur différents canaux tout en optimisant les chances d'une réception rapide des données par l'utilisateur. Dans des modes de réalisation, au cours de l'étape de sélection, on met en oeuvre une table de correspondance entre des valeurs de paramètres du contexte et des canaux de transmission des données. La sélection est ainsi aisée et la table de correspondance peut être facilement éditée par l'utilisateur. Dans des modes de réalisation, au cours de l'étape de transmission des données, on effectue un formatage des données en fonction du canal de transmission sur lequel les données sont transmises, comme exposé ci-dessous. On peut ainsi passer de la voix au texte, ou inversement, d'un courrier électronique à un message court, ou inversement, etc.

Dans des modes de réalisation, au cours de l'étape de transmission on crée un programme applicatif en fonction des données à transmettre et on transmet le programme applicatif à l'utilisateur. Dans le mode de réalisation particulier exposé en regard de la figure 7, l'infrastructure ICU effectue les opérations suivantes : - l'ICU 701 reçoit un message provenant d'une passerelle 702, 703, 704 ou 706, ou du serveur 705 ; -l'ICU 701 analyse le contenu du message en fonction de l'émetteur pour en extraire des éléments structurants ; - pour chaque destinataire du message : - l'ICU 701 détermine, dans la table de conversion, les envois à réaliser et - l'ICU 701 effectue l'émission du message pour chaque canal configuré en fonction d'un ensemble de règles de gestion (conditionnelles). L'association d'étiquettes, ou Tag , aux les flux entrants permet d'enrichir le comportement de la plate-forme lors de la création des flux sortants. L'infrastructure permet de diffuser tout type de médias en utilisant des capacités de formatage adaptées au média. Les émetteurs ou destinataires de médias considérés sont, en particulier : un ordinateur via : - un navigateur Web sur une URL dédiée, - un client mail sur un compte dédié, - un client IM et - une application dédiée sur un format propriétaire et - un téléphone via : - le client SMS, - une application dédiée, - un navigateur WAP et - une boîte vocale.

L'ICU est configuré par chaque utilisateur pour définir les passerelles qu'il souhaite paramétrer. Le tableau ci-dessous donne une présentation de différents flux. L'utilisateur renseigne, lors de la configuration de l'ICU : - les comptes IM utilisés, - pour les SMS, le numéro de téléphone, - pour les courriers électroniques, l'adresse email, - pour les communications vocales, le numéro de téléphone et - pour l'utilisation de la plate-forme implémentant les services objets de la présente invention, un identifiant de compte. Le tableau ci-dessous référence, par des numéros entre 1 et 20 , des besoins de conversion de flux : Emission/Réception IM SMS Mail Vocale Plate-forme IM x 1 2 3 4 SMS 5 x 6 7 8 Mail 9 10 X 11 12 Vocale 13 14 15 x 16 Plate- forme 17 18 19 20 x Ce tableau reprend les différents types de messages en émission et en réception. Cela signifie que les numéros apparaissant dans les différentes cases seront repris pour expliquer les traitements réalisés par l'infrastructure dans chacun des cas. Les x présents dans la diagonale du tableau signifient qu'il n'y a, à priori, aucun traitement nécessaire. Emission d'un SMS : lorsqu'un SMS est reçu par l'ICU, chaque texte terminé par le symbole @ est analysé comme étant un destinataire. Par exemple, le message Dl @ D2@ bonjour comment vas-tu ? : sera traité comme le message bonjour comment vas- tu ? émis à l'ICU pour les destinataires Dl et D2. L'ICU effectue les traitements suivants : Cas 1 (le destinataire à configurer un ou plusieurs canaux IM sur lesquels il souhaite être informé) : l'intégralité du SMS (hors champs destinataires) est transmis sur l'IM avec l'identité de l'émetteur Cas 10 (le destinataire à configurer une adresse email sur laquelle il souhaite être informé) : l'intégralité du SMS (hors champs destinataires), ainsi que l'identité de l'émetteur sont incorporés dans le corps de l'email. Le sujet contient la plate-forme vous informe de la réception d'un SMS Cas 14 (le destinataire à configurer une boîte vocale) : l'intégralité du SMS (hors champs destinataires) est converti par un procédé TextTOSpeach ainsi que l'identité de l'émetteur. Pour chaque destinataire du message, l'ICU effectue un appel vocal. Cas 18 (le destinataire est abonné à une plate-forme communautaire) : l'intégralité du SMS est transmis à la plate-forme pour analyse. Le traitement des champs destinataires est réalisé sur la plate-forme (les Identifiants des destinataires peuvent être différents de ceux connus par l'ICU).

Emission de courriers électroniques : lorsqu'un courrier électronique est envoyé à l'adresse du destinataire au travers de l'infrastructure de messagerie unifiée, il est analysé suivant les cas suivants : Cas 2 (le destinataire à configurer un ou plusieurs canaux IM sur lesquels il souhaite être informé) : le sujet du courrier électronique est transmis sur l'IM en premier avec l'identité de l'émetteur. Le contenu texte est extrait du corps du courrier électronique et mis en forme pour être transmis sur l'IM. Cas 6 (le destinataire à configurer le canal SMS) : le sujet du mail est transmis dans le corps du SMS, ainsi que l'identité de l'émetteur. Cas 15 (le destinataire à configurer une boîte vocale) : le sujet de l'email est converti par un procédé TextTOSpeach ainsi que l'identité de l'émetteur. Cas 19 (le destinataire est abonné à une plate-forme communautaire) : l'ensemble de l'email est analysé de la manière suivante : - sujet : le sujet peut contenir un tag donnant un caractère métier au message (exemple : [ALARME] intrusion chez destinataire aura pour effet de solliciter la plate- forme avec le tag ALARME pour générer un comportement dédié au traitement d'une alarme). Si la plate-forme ne sait pas interpréter le tag , elle utilise le comportement par défaut ; - pièces attachées : chaque pièce attachée est analysée pour définir le type de document est permettre ainsi à la plate-forme d'effectuer une transformation sur la source pour l'adapter aux capacités de la plate-forme ; - corps du message : le corps du message peut contenir des tags qui permettent d'orienter la plate-forme sur le traitement du corps du message en complément généralement avec le Tag contenu dans le sujet. Emission d'un appel vocal : lorsqu'un appel vocal est reçu par l'ICU, le message est enregistré puis l'ICU demande d'entrer les identifiants des destinataires du message. Les identifiants peuvent être des Identifiants préenregistrés sur l'ICU et associés au numéro de l'appelant. Exemple : un utilisateur ayant le numéro de téléphone 0607080910 a prédéfini les destinataires Dl et D2 en leur donnant les identifiants 1 et 2 . Lorsqu'il appelle l'ICU depuis son mobile, l'ICU identifie le numéro d'appelant et à la fin du message vocale si l'utilisateur entre #1#2#, l'ICU transmettra le message aux destinataires Dl et D2. L'ICU effectuera les traitements suivants : Cas 3 (le destinataire à configurer un ou plusieurs canaux IM sur lesquels il souhaite être informé) : le message suivant est publié sur l'IM : La personne au numéro xxxx vous à laisser un message vocal .

Cas 7 (le destinataire à configurer le canal SMS) : le message suivant est envoyé par SMS : La personne au numéro xxxx vous à laisser un message vocal . Cas 11 (le destinataire à configurer une adresse email sur laquelle il souhaite être informé) : le message vocal est attaché en pièce jointe à l'email. Le sujet contient la plate-forme vous informe de la réception d'un message vocal laissé par xxxxx .

Cas 20 (le destinataire est abonné à une plate-forme communautaire) : le message vocal est transmis à la plate-forme ainsi que les Id entrés à la fin du message. Emission par la plate-forme : lorsque la plate-forme émet un message vers l'ICU, elle effectue un prétraitement du message pour les différentes catégories de flux existants. L'ICU reçoit des données formatées directement transmissibles : Cas 4 (le destinataire à configurer un ou plusieurs canaux IM sur lesquels il souhaite être informé) : texte destiné à l'IM. Cas 8 (le destinataire à configurer le canal SMS) : texte destiné à l'envoi de SMS. Cas 12 (le destinataire à configurer une boîte vocale) : message vocal destiné à être laissé sur une boite vocal.

Cas 16 (le destinataire à configurer une adresse email sur laquelle il souhaite être informé) : l'ensemble de l'email est préparé: - sujet, -pièces attachées et - corps du message.

L'ICU peut gérer optionnellement un routage (fonction connue sous le nom de transfert ou forward ) conditionnel en fonction : - de l'identité de l'émetteur du message, d'une période donnée (heure, jour

.), - d'éléments de contenu et/ou d'un signal de présence (si le destinataire est identifié comme présent sur un des canaux configurés dans le routage, le message est d'abord ou uniquement émis sur ce canal) L'ICU peut aussi gérer un workflow de routage. Cela signifie qu'il existe un niveau de priorité d'émission pour chaque canal et un temps d'attente entre chaque émission. Cette fonctionnalité évite de dupliquer le contenu du message si l'utilisateur considère que dès l'instant où il l'a acquitté, il ne souhaite pas le voir sur un autre médium...DTD: L'ICU peut permettre la gestion (création/modification/suppression) de tout ou partie d'applications tel que décrites dans l'exposé de la création d'applications riches à la volée, ci-dessous. Dans la suite de cette description, des éléments additionnels descriptifs sont donnés, sur l'architecture d'un mode de réalisation du système implémentant la présente invention, et sur les services objets de la présente invention. Pour prévenir l'utilisateur de la survenance d'un événement liée à un service, des ping ou signaux sont transmis à l'aide de lignes téléphoniques. Un appel mettant en oeuvre un numéro d'appelant prédéfini est transmis brièvement l'utilisateur (qui ne décroche pas) pour lui notifier un événement (nouveau message, nouvelle mise à jour etc...), le numéro prédéfini servant d'identifiant de l'événement. Après avoir reçu ce court appel, l'utilisateur n'a plus qu'à se connecter au serveur. Dans un service, un utilisateur peut importer tout ou partie de l'espace de services d'un autre utilisateur dans le sien. Cela rend la notion de partage de services et d'informations transparente. A cet effet, on utilise le niveau de visibilité affecté à chaque service de l'autre utilisateur, un peu comme on peut le faire sur Flickr avec les images (public/amis/famille), et qu'on ne puisse pas faire une action (par exemple une réservation) à la place d'une personne parce qu'on a importé son espace dans le sien. D'ailleurs, l'ajout dans la buddy-list devrait être soumis à autorisation (comme dans la plupart des systèmes).

Partitionnement des données piloté par la proximité sociale : dans les systèmes à très gros volume, une base de données ne suffit plus à stocker l'ensemble des données, et il faut partitionner, c'est à dire avoir des bases de données ne contenant qu'une partie des utilisateurs. Les approches traditionnelles sont simplement basées sur un modulo d'un identifiant unique (genre id-user % nb-machines) ou un équilibrage du volume de données.

Dans des modes de réalisation du système implémentant la présente invention, on améliore l'efficacité du système en conservant, sur un même serveur, les utilisateurs fortement reliés. Le partitionnement est alors piloté par la connectivité des graphes. Cela n'empêche pas la distribution géographique des données, puisqu'un graphe connexe d'utilisateurs peut être stocké dans un centre de données ( datacenter ) localisé à l'emplacement moyen de ce graphe. La présente invention permet la créationd'applications riches à la volée via l'utilisation de différents médias. Par exemple, il s'agit de créer une application à partir de la réception d'un courrier électronique, par analyse de l'émetteur et, s'il est connu, pour aller dans son compte, les sujet, corps et attachement(s) du courrier électronique étant transformés en application informatique. Par exemple, un courrier électronique comportant des photos attachées devient une application album photo avec, comme titre, le sujet du courrier électronique. Dans un autre exemple, un courrier électronique possédant, comme sujet, selon une syntaxe particulière, date/heure et lieu de rendez-vous, se transforme dans une application calendrier en un événement pour la date/heure avec, comme titre, le lieu de rendez-vous et, comme description, le corps de l'email. Dans les exemples précédents, il a été seulement considéré le média de courrier électronique. Cependant, on peut aussi prendre en compte de nombreux autres médias, par exemple les médias suivants : SMS, MMS, - IM, - téléphone (représentation électronique d'une communication téléphonique : fichier son :), - télécopie (représentation électronique du fax : tiff, pdf, ...) et - UL Web (HTML, XHTML, ...). Plus généralement, toutes source électronique (textuelle, sonore, image, quel que soient les formats avec syndication ou non des sources (texte+image, texte seul, ...)) est la source d'entrée pour la création d'une application riche reprenant tout ou partie du contenu. Il est entendu par application riche toute application complète déjà existante, partielle, générée à la volée, propriétaire ou non. En ce qui concerne l'identification de l'utilisateur, dans la plupart des cas, une identification de l'utilisateur peut/doit être nécessaire pour permettre l'ajout de cette nouvelle application à son compte. Dans la plupart des médias sources proposés ci-dessus, il y a des moyens d'identification automatique sans ajout de cette information au reste du contenu : numéro d'appelant, identifiant ou pseudo, ...

Le procédé permet de gérer tout ou partie d'applications riches en envoyant, soumettant ou récupérant tout document (seul ou multiple) des formats listés ci-dessous (les listes de formats et de types de format ne sont pas exhaustives) au moyen de tout média possible (téléphone, email, IM, Fax, ...). Formats des fichiers sonores : RAVI, WAV, MP3 (MPEG-1 Layer III), XAC, AIFF, AIFC, IFF, AU, VOC, SND, Ogg Vorbis (ou OGG), AAC ou MPEG-2 AAC, MP3pro, VQF ou TwinVQ (acronyme de Transform-domain Weighted Interleave Vector Quantization pour quantification vectorielle entrelacée pondérée de transformation de domaines), WMA (acronyme de Windows Media Audio , marque déposée), ASF (acronyme de Advanced Streaming Format pour format de flux avancé), SDS, SMP, VOX, MAT et FLAC. Formats des images : JPEG, GIF, TIFF, APNG, MNG, PNG, PCX, BMP, Silicon Graphics IRIS, Raster SUN, PPM, Postscript encapsulé, Pixmap X, photoshop, PGM, DICOM, Bitmap X, AliasiWavefront PIX. Formats des vidéos : Divx, QuickTime, Real, Xvid, VP7, X264, AAC, Ogg Vorbis. Formats des documents textes : Doc, Docx, Odt, Sxw, Rtf, Sdw, Pdf, Txt, XML, HTML et XHTML.

Comme illustré en figure 11, pour créer des applications informatiques, à partir de la réception d'un message possédant un contenu, étape 1105, on détermine un type d'application informatique susceptible d'être associé audit contenu en fonction dudit contenu, étape 1110, et on effectue le paramétrage d'une application générique du type d'application déterminé avec ledit contenu pour constituer ladite application informatique, étape 1115.

Lors de la détermination d'un type d'application informatique, le type d'application informatique dépend - de l'identité de l'émetteur dudit message, - d'au moins un attachement audit message et/ou de mots clés inclus dans le contenu dudit message.

En ce qui concerne la navigation sur la toile, ( web ), la présente invention concerne aussi un navigateur web évolué pour terminaux de faible capacité. En effet, le succès du web est dû, en partie, au fait que le HTML (langage de description des pages web) et le Javascript (langage de programmation des pages web dynamiques) sont fournis par les serveurs web aux navigateurs sous forme de texte source. Cela a d'une part évité d'avoir à définir des représentations binaires qui auraient pu être dépendantes d'une plateforme, et a permis d'autre part à n'importe quel utilisateur d'apprendre à développer des pages web en examinant simplement leur source. Mais cette approche impose une charge de travail importante au navigateur qui doit analyser la source du HTML et du Javascript avant de pouvoir respectivement les afficher et les exécuter. Ce n'est pas une contrainte sur les ordinateurs personnels modernes disposant d'une forte puissance de calcul, d'une grosse capacité mémoire et d'une connexion réseau rapide, mais devient très problématique dans des environnements contraints comme les téléphones portables d'entrée ou de milieu de gamme. Pour permettre aux téléphones portables de faible capacité d'afficher des pages web en HTML, ainsi que l'exécution de code Javascript, on pré-analyse ces éléments dans une passerelle entre le téléphone et le site web. Par ailleurs, on propose aussi la capacité, offerte au code Javascript contenu dans la page web, d'utiliser des fonctions dites natives du téléphone comme l'envoi de SMS, l'établissement de communications ou la capture d'image. On propose aussi un mécanisme permettant d'utiliser le même code Javascript pour obtenir des fonctions similaires sur le navigateur d'un ordinateur personnel.

Le navigateur ainsi créé est capable, en addition ou en remplacement du GML, de recevoir du code HTML et Javascript sous une forme binaire particulière, permettant son exploitation sur tout type de mobile. La binarisation (transformation en chiffres binaires) est effectuée par un serveur dit serveur passerelle 840 (voir figure 8). Pour accéder à un serveur web 880, le navigateur 820 sur mobile 810 envoie une requête 890a à ce serveur passerelle 840, qui la transmet, par le message 890b, au serveur effectif 880. Ce serveur effectif fournit la page web et son code Javascript, par des messages 805. Le serveur passerelle 840 effectue le processus de binarisation/compilation et transmet le résultat de ce processus, par le message 815, au navigateur Goojet du téléphone mobile 820. La binarisation comporte plusieurs actions (l'ordre effectif peut être différent de celui présenté ci-dessous) effectuée par le serveur passerelle : - expansion des styles CSS 850, définissant l'aspect (taille, police, couleur) de chaque élément de la page HTML, - transcodage des éléments HTML 860 en une représentation binaire utilisable efficacement par le téléphone mobile, - compilation du code Javascript 870 en un bytecode compact pouvant être interprété efficacement par le téléphone mobile Une caractéristique optionnelle du procédé de navigation est que la transformation est totalement transparente pour le code Javascript contenu dans la page. En particulier, celui-ci peut modifier la structure de la page après son affichage sur le terminal mobile 810.

L'interface DOM Document Object Model est disponible pour permettre la construction d'interactions locales au terminal, n'impliquant pas le serveur d'origine. Une autre caractéristique optionnelle est que le résultat des transformations peut être conservé par le serveur passerelle 840 dans un système de stockage temporaire 825 pour ne pas effectuer de façon répétitive la transformation du même contenu qui serait demandé fréquemment soit par le même téléphone mobile, soit par des téléphones différents. Utilisation des fonctions natives du téléphone L'environnement dans lequel le code Javascript est exécuté dans le téléphone comporte des fonctions particulières permettant d'utiliser les fonctions et périphériques natifs 830 du mobile. En particulier, et de façon non limitative : - l'envoi de SMS, - l'établissement de communications téléphoniques, - la consultation du carnet d'adresse et - l'utilisation de l'appareil photo intégré au téléphone pour capturer des images fixes ou de la vidéo. La présente invention visant à fournir un environnement d'exécution transparent pour les applications, ces fonctions seront aussi disponibles sur un navigateur fonctionnant sur un ordinateur personnel. A cet effet, l'environnement d'exécution sur ordinateur personnel fournit aux pages web un environnement d'exécution Javascript comportant une implémentation de ces fonctions. Les moyens utilisés seront, de façon non limitative : - une passerelle web/SMS pour l'envoi de SMS, - l'utilisation de téléphones mettant en oeuvre le logiciel SIP ou Skype (marques déposées) pour l'établissement de communications téléphoniques, - la consultation du carnet d'adresses téléchargé depuis le téléphone et synchronisé avec le serveur, - l'utilisation d'extension du navigateur, de type plugin Flash pour utiliser une webcam ou autre appareil de photographie et vidéo connecté à l'ordinateur. A cet effet, on effectue une pré-analyse sur le serveur passerelle des caractéristiques de mise en forme du contenu HTML (styles CSS) sur le serveur, on transforme sur le serveur passerelle du HTML et sa mise en forme sous une forme binaire compacte, on compile sur le serveur passerelle du Javascript en instructions bytecode directement exécutables On assure ainsi une transparence du processus de binarisation/compilation pour le code Javascript contenu dans les pages web, la mise à disposition du Javascript de fonctions d'accès aux fonctions natives du téléphone et l'implémentation des fonctions natives du téléphone pour les navigateurs sur ordinateur personnel à l'aide de téléphones logiciels et de webcam ou autre périphérique de photographie et capture vidéo. On observe, en figure 12, des étapes mises en oeuvre pour transformer une page de la toile en vue de son affichage sur un terminal mobile communicant. Au cours d'une étape 1205, le terminal mobile communicant émet, à destination d'un serveur passerelle, une requête identifiant la page à afficher. Au cours d'une étape 1210, le serveur passerelle émet une requête identifiant ladite page au serveur hébergeant ladite page. Au cours d'une étape 1215, le serveur passerelle reçoit la page de la toile comportant un contenu HTML et du Javascript.

Au cours d'une étape 1220, le serveur passerelle effectue une pré-analyse des caractéristiques de mise en forme du contenu HTML de ladite page. Au cours d'une étape 1225, le serveur passerelle effectue une transformation, dans une forme binaire compacte, sur le serveur passerelle, du contenu HTML et de sa mise en forme. Préférentiellement, au cours de l'étape 1225 de transformation dans une forme binaire, on effectue une étape d'expansion de styles CSS du contenu HTML de la page définissant l'aspect d'éléments du contenu HTML de la page et on maintient accessible l'interface DOM (acronyme de Document Object Model ) de la page. Au cours d'une étape 1230, le serveur passerelle effectue une compilation du Javascript de ladite page en instructions directement exécutables par le terminal mobile communicant. Préférentiellement, au cours de l'étape 1230 de compilation, on compile le Javascript de la page en instructions bytecode directement exécutables par le terminal mobile communicant. Au cours d'une étape 1235, le serveur passerelle effectue une association du code Javascript contenu dans la page et d'au moins une fonction native de la partie de téléphonie mobile du terminal mobile communicant. Au cours d'une étape 1240, le serveur passerelle fournit au terminal mobile communicant, la forme binaire compacte du contenu HTML, des instructions provenant de la compilation du Javascript et des éléments d'association à des fonctions natives de téléphonie mobile. On observe, en figure 13, des étapes mises en oeuvre pour transformer une page de la toile en vue de l'affichage rapide de liens hypertextes sur un terminal mobile communicant. Au cours d'une étape 1305, le terminal émet une requête à destination d'un serveur distant hébergeant un site de la toile pour accéder à une page de ce site, de manière connue en soi, par exemple après saisie, par l'utilisateur du terminal d'une adresse électronique ( URL ) ou par sélection ( clic ) d'un lien dans une application informatique ou sur une autre page de la toile. Au cours d'une étape 1310, le serveur commence à transmettre le contenu de la page requise. Ce contenu est décrit, par exemple, sous forme de code HTML ou XML, d'animations, d'images, de fichier sonore et/ou de fichier vidéo. Au cours d'une étape 1315, pendant: la réception du contenu de la page, le terminal détecte, dans le contenu de la page déjà reçu, et extrait, au moins un lien hypertexte, selon des techniques connues. Au cours d'une étape 1320, le terminal détermine si un graphisme, éventuellement animé, est associé, dans le contenu de la page, au lien hypertexte extrait. Préférentiellement, au cours de l'étape 1320, le terminal ne considère qu'un graphisme de faible résolution. L'association recherchée peut être de type connu, c'est-à-dire qu'une sélection du graphisme ( clic ) déclenche une requête sur le lien associé, ou de type dédié à la mise en oeuvre de la présente invention, par exemple sous forme d'une liste de liens hypertextes et de graphismes en tête des données de contenu de la page en cours de réception. Si un graphisme est associé, dans le contenu de la page, au lien en cours de traitement, on passe à l'étape 1335. Si aucun graphisme n'est associé, clans le contenu de la page, au lien en cours de traitement, au cours d'une étape 1325, le terminal détermine s'il a un graphisme en mémoire à associer au lien. Par exemple, un lien comportant le mot home ou accueil est automatiquement associé à un graphisme représentant une maison. Si un tel graphisme existe, on passe à l'étape 1335. Sinon, au cours d'une étape 1330, on détermine une partie de l'adresse électronique du lien pour en extrait des mots d'un dictionnaire, préférentiellement multilingue. On retire ainsi, entre autres, les premières lettres de cette adresse (par exemple, http://www. ) et les dernières lettres de cette adresse (par exemple .html ou des symboles liés à des adresses dynamiques). Préférentiellement, au cours de l'étape 1330, on recherche aussi la partie (ou le mot du dictionnaire) la plus identifiante de l'adresse du lien. Par exemple, si plusieurs liens présentent le même début, ce début n'est pas considéré comme identifiant. Inversement, si les mots de dictionnaires extraits sont tous identiques pour deux liens, on ajoute des symboles différentiant provenant des adresses initialement extraites. Les parties considérées comme identifiantes sont alors représentées en caractères plus gros que les autres parties de l'adresse pour créer un graphisme alphanumérique permettant à l'utilisateur de reconnaître facilement chaque lien. Puis on passe à l'étape 1335. Préférentiellement, les graphismes issus des étapes 1320, 1325 et 1330 sont normalisés en dimensions. Préférentiellement, ces dimensions sont adaptées à la résolution de l'écran d'affichage du terminal. Par exernple, on vise à ce que neuf graphismes associés aux liens puissent être affichés sur l'écran du terminal, de manière à correspondre aux touches numériques du clavier du terminal, comme exposé plus haut. Au cours d'une étape 1335, on positionne les graphismes dans une page correspondant à l'écran du terminal. Préférentiellement, les positionnements sont déterminés en fonction des positions des liens dans la page originale en cours de réception. Ainsi, un lien plus à droite qu'un autre, dans la page initiale, reste plus à droite, dans la page générée au cours de l'étape 1335. Puis, au cours d'une étape 1340, on affiche la page générée au cours de l'étape 1335, sur l'écran du terminal. Ainsi, avant même que le contenu entier de la page ait été reçu, l'utilisateur dispose déjà des liens lui permettant de naviguer vers d'autres pages ou animations. II n'a donc pas à attendre la fin du chargement de la page pour passer à une autre page. L'utilisateur gagne donc du temps, notamment lorsqu'il connaît la page en cours de chargement et ne souhaite pas la visualiser. Au cours d'une étape 1345, on détermine si l'utilisateur du terminal a sélectionné l'un des liens, par l'intermédiaire de son graphisre, avec mise en oeuvre d'un écran tactile ou du clavier numérique, comme expliqué plus haut. Si oui, le terminal retourne à l'étape 1305 pour émettre une requête pour recevoir le contenu associé au lien sélectionné ou, le cas échéant, lancer l'application associée à ce lien. Si non, au cours d'une étape 1350, on détermine si l'ensemble des liens de la page en cours de réception a été traité. Si non, on retourne à l'étape 1310. Si oui, au cours d'une étape 1355, on détermine si l'ensemble du contenu de la page a été reçu. Si non, on retourne à l'étape 1315. Si oui, au cours d'une étape 1360, on génère un graphisme représentatif de la page reçue et on l'insère dans la page affichée sur l'écran du terminal. On donne ainsi à l'utilisateur un accès à l'affichage de la page reçue, tout en maintenant l'affichage de liens extraits du contenu de la page. Préférentiellement, la représentation graphique de la page reçue est dédiée. Par exemple, elle est uniforme et représente le terme page ou une page type miniaturisée (et donc illisible). La représentation graphique des liens est plus intuitive que l'affichage du lien lui-même et peut être normalisée en dimensions, charte graphique, etc. En particulier, un site peut fournir des représentations graphiques à afficher, en tête du contenu de la page, afin d'aider les utilisateurs munis de terminaux de faibles capacités de réception, d'affichage et/ou de traitement de contenus. La représentation graphique est préférentiellement automatiquement adaptée au terminal et/ou à la réception de page en cours, par exemple, en fonction de la résolution de l'écran d'affichage pour que le nombre de liens représentés soit constant ou croissant avec cette résolution, en fonction de la vitesse de réception de la page ou en fonction d'une durée estimée de réception de la page pour qu'un terminal muni de fortes capacités de réception, d'affichage et de traitement n'affiche pas de liens extraits mais attende la fin du chargement de la page pour l'afficher mais que, inversement, un terminal muni de plus faibles capacités utilise les liens extraits et leur affichage pour donner à l'utilisateur rapidement des moyens de naviguer à partir de la page en cours de réception.

Par exemple, la valeur limite de durée au delà duquel, les liens sont extraits et affichés est de une seconde. On observe que, pour mettre en oeuvre cette variante, on prévoit une étape intermédiaire 1312 entre l'étape 1310 et l'étape 1315 de détermination de la vitesse de réception et/ou de la durée estimée de cette réception et de comparaison de cette vitesse et/ou de cette durée avec une valeur limite prédéterminée.

En ce qui concerne les services objets de la présente invention, l'infrastructure mise en place permet de développer, promouvoir et exploiter des services innovants, dont des exemples sont présentés ci-dessous : 1/ service de conference call ou téléconférence synchrone à la demande : ce service permet de mettre en relation simultanée, sur leur mobile, plusieurs utilisateurs distants, sans qu'ils aient eu à préparer ou réserver une conférence. Ce service est particulièrement pratique en situation de mobilité et de dispersion des interlocuteurs. Ce service permet à un utilisateur de sélectionner, soit par saisie explicite d'identifiants de mobiles, soit par saisie automatique d'identifiants par le système (en interprétant la liste des contacts représentés dans la page depuis laquelle le service est invoqué) des candidats à une conférence téléphonique. La simple évocation de l'action terminale conference call , choisie dans l'espace de services de l'utilisateur, amène le serveur à envoyer aux candidats des notifications d'invitation à une conférence. Ces notifications peuvent être multimodales et comprennent, entre autres, un SMS et une notification via l'interface du service (réponse GML à un polling). Sur réception de la notification, chaque destinataire peut, par simple acceptation, être mis directement en relation avec le serveur qui organise la conférence. La partie mobile de ce service consiste en la sélection des candidats et la gestion de la notification (déclenchement côté utilisateur qui a invité, acceptation côté invités). La tâche du serveur consiste alors, essentiellement, dans l'envoi des notifications et la mise en relation lors de l'acceptation de chaque destinataire. Au-delà de cette fonction, le serveur de cette application de conférence offre aussi des fonctions de gestion de conférence à valeur ajoutée, tels que enregistrements et/ou statistiques, dont l'exploitation est accessible via l'interface web. Chaque interlocuteur potentiel, ou candidat, reçoit un numéro d'appel et une interface graphique indiquant les correspondants dont les numéros de téléphone sont en cours de numérotation (action d'appeler le numéro et sonnerie sur le numéro active). Le système réserve le numéro pour la conférence, car connaissant le numéro des appelants potentiels, il peut filtrer des personnes indésirables qui appelleraient au même moment le numéro. Le responsable (en anglais leader ) de la conférence peut décider, sur un simple clic, de basculer tout le monde en conférence (début de la facturation pour chaque appelant). Lorsqu'un utilisateur est convié à une conférence, il dispose d'un déclencheur (en anglais trigger ). La sélection, ou clic , sur ce déclencheur provoque l'apparition d'une page avec les avatars des personnes conviées à la conférence téléphonique (pour une personne non identifiée, on fait apparaître son nom ou son numéro de téléphone). Un statut est représenté à côté ou sur chaque icône de l'avatar et indique si l'utilisateur correspondant est entré dans la conférence téléphonique. En option, le statut identifie la personne qui parle. Préférentiellement, le serveur ne prend pas la communication d'un participant, tant qu'il n'y a pas au moins un autre participant qui l'appelle. Cela évite à un utilisateur d'être connecté pour rien.

La figure 10 illustre un mode de réalisation particulier du procédé implémentant cette application de conference cati . Dans la description, les termes d'utilisateur et d'interlocuteur sont équivalents et utilisés indifféremment. On observe, tout d'abord, en figure 10, une étape 1005 de lancement de la communication, par une premier utilisateur, au cours de laquelle le premier utilisateur sélectionne une application dans une arborescence, avec son téléphone mobile, comme exposé ci-dessus. Puis, au cours d'une étape 1010, on effectue une sélection, par ledit premier utilisateur, d'au moins deux utilisateurs, dits deuxièmes . Cette sélection peut être réalisée : deuxième interlocuteur par deuxième interlocuteur, en composant leurs numéros de téléphone ou en sélectionnent ce numéro dans un répertoire ou en sélectionnant des avatars ou des photos les représentant et/ou en sélectionnant une application dans laquelle un ensemble de deuxièmes interlocuteurs potentiels est déjà référencé (avec éventuelle élimination d'interlocuteurs potentiels). Après validation par le premier interlocuteur de la liste de deuxièmes interlocuteurs invités à la conférence, un serveur implémentant le service de conférence reçoit cette liste de la part du premier interlocuteur, au cours d'une étape 1015 et réserve un numéro affecté à ladite conférence.

Au cours d'une étape 1020, le serveur effectue une notification de chaque deuxième utilisateur sélectionné, au cours de laquelle chaque deuxième utilisateur reçoit des informations d'une interface graphique représentant le premier utilisateur et chaque autre deuxième utilisateur sélectionné ainsi que le numéro réservé. Pour l'étape de notification, le serveur peut mettre en oeuvre différents types de canaux de communication avec les différents deuxièmes utilisateurs. De plus, les notifications peuvent être multimodales, selon des capacités de communication des deuxièmes interlocuteurs. Préférentiellement, au cours de l'étape de notification, en l'absence de réponse d'un deuxième utilisateur, on notifie de nouveau ledit deuxième utilisateur absent par l'intermédiaire d'un canal de communication différent de celui utilisé pour la première notification du deuxième utilisateur absent. Ainsi, un interlocuteur qui n'aurait pas répondu avec un téléphone mobile peut être appelé sur un téléphone fixe, par exemple. Au cours d'une étape 1025, chaque terminal de deuxième utilisateur muni de l'application de conférence affiche ladite interface graphique.

Au cours d'une étape 1030, le serveur détermine si un deuxième interlocuteur a accepté de participer à la conférence. Pour accepter, chaque deuxième utilisateur n'a qu'à sélectionner un icône d'acceptation représenté sur l'interface graphique. Si non, Au cours d'une étape 1035, le serveur détermine si un deuxième interlocuteur a refusé de participer à la conférence. Pour refuser, chaque deuxième utilisateur n'a qu'à sélectionner un icône de refus représenté sur l'interface graphique. Si non, on retourne à l'étape 1030. Si le résultat de l'étape 1035 est positif, au cours d'une étape 1040, on transmet à chaque interlocuteur, premier ou deuxième, une information d'interface graphique représentant le refus de participer de la part du deuxième interlocuteur, ainsi que l'identification de ce deuxième interlocuteur et on retourne à l'étape 1025. Si le résultat de l'étape 1030 est positif, au cours d'une étape 1045, on transmet à chaque interlocuteur, premier ou deuxième, une information d'interface graphique représentant l'acceptation de participer de la part du deuxième interlocuteur, ainsi que l'identification de ce deuxième interlocuteur et chaque interface graphique effectue l'affichage de cette information. Puis, au cours d'une étape 1050, on détermine si le premier interlocuteur déclenche la conférence. Pour déclencher la conférence, le premier interlocuteur n'a qu'à sélectionner un icône dans l'interface graphique. Si non, on retourne à l'étape 1030. Si oui, au cours d'une étape 1055, le premier interlocuteur et chaque deuxième interlocuteur ayant accepté de participer à la conférence reçoit le numéro réservé à la conférence et, éventuellement après une dernière validation de la part des deuxièmes utilisateurs, tous les mobiles des interlocuteurs ayant accepté la conférence sont mis en communication téléphonique ou visiophonique, pour ceux qui disposent des moyens de visiophonie, par l'intermédiaire du numéro réservé. Au cours d'une étape 1060, si le premier utilisateur a sélectionné une option d'enregistrement, et pour chaque deuxième interlocuteur acceptant ultérieurement de participer à la conférence, on demande une autorisation d'enregistrement à chaque deuxième interlocuteur participant à la conférence. En cas d'autorisation, au cours d'une étape 1065, on effectue un enregistrement du contenu de la conférence et, à la fin de la conférence, étape 1075, on effectue une étape 1080 de mise à disposition dudit enregistrement à chaque participant à la conférence, par exemple par transmission d'un fichier audio et/ou vidéo à des adresses électroniques des participants. Au cours de la conférence, étape 1070, on effectue une détection de l'interlocuteur qui parle (par simple traitement du signal audio des différents participantset on provoque l'affichage sur les interfaces graphiques des différents participants, d'une identification de l'utilisateur qui parle. Le suivi de la conférence est ainsi facilité. On note que, en cas d'appel du premier utilisateur entre les étapes 1005 et 1070, cet appel est rejeté. On évite ainsi qu'un tiers non convié à la conférence en perturbe le déroulement. En variante, à la place de l'étape 1050, on déclenche automatiquement la mise en communication dès lors qu'au moins un deuxième utilisateur a accepté la conférence. On évite ainsi de facturer la communication au premier utilisateur en attente d'acceptation de la conférence par les deuxièmes utilisateurs. Les notifications indiquées ci-dessus peuvent êtres effectuées par message court (SMS), message court multimédia (MMS), appel vocal avec message vocal, appel vocal puis raccroché, courrier électronique, message dans l'application de conférence ou toute autre application compatible ou connectée. 2/ services transactionnels web-mobiles autonomes : dans ce service, le serveur gère des transactions entre des clients et des fournisseurs, et peut donc, dans certains cas, se substituer à des services informatiques ou Internet lourds. Ces services sont rendus possibles grâce au découpage intelligent des traitements entre présentation mobile et serveur. Par exemple, le service de réservation est défini de la façon suivante : - le fournisseur, par exemple un restaurant, créer son service û ce service est une branche de divers services agrégés, dont de l'information sur le restaurant, des liens vers d'autres services jugés pertinents ou connexes par le restaurant. L'une des feuilles de l'arborescence est le service applicatif de réservation, paramétré par le restaurant pour son besoin, lors de la création de son service transactionnel. Une fois créé, ce service complexe dans lequel se trouve le service applicatif de réservation paramétré pour ce restaurant, est disponible pour la communauté des utilisateurs de la présente invention. Public, il peut être promu. Ainsi, il peut se retrouver dans les espaces d'utilisateurs potentiels sans que ceux-ci aient eu à recherche ce service. Le service applicatif de réservation se compose de plusieurs pages de saisie de choix (chaque page de saisie de choix étant un atome paramétrable), qui, ensemble, forment les éléments d'une requête. Par exemple, l'utilisateur choisit une heure et un nombre de personnes (le même concept s'appliquant bien sûr à tout type de requête, le nombre de choix successifs et les candidats pour chacun de ces choix étant des paramètres saisis par le créateur du service à sa création). Puis il envoie sa requête, que le serveur reçoit et traite. Le traitement du serveur consiste à envoyer la requête au restaurant, dans le format choisi par le restaurant lors de la création de son service de réservation. Le restaurant peut choisir une notification multimodale : par exemple par SMS, courrier électronique, appel téléphonique, invocation d'un service web avec son système informatique de gestion, dont le contenu est fabriqué par le serveur en fonction des paramètres envoyés par la partie mobile du client lors de sa requête. Parmi les multiples modes possibles, l'un est aussi un service : le restaurant peut disposer de la partie mobile fournisseur du même service. Ce service se structure en effet en une partie mobile client , utilisée par chaque client du restaurant pour envoyer leur requête, d'un serveur pour traiter les requêtes, et d'une partie mobile fournisseur qui complète la transaction. Avec ce service, le restaurant peut donc recevoir la requête directement dans l'espace applicatif et traiter la demande en temps quasi réel, depuis son mobile : sur acceptation ou rejet, il complète la transaction via le serveur jusqu'à l'émetteur de la requête. Il peut aussi se servir de sa partie mobile fournisseur pour des opérations de gestion (par exemple afficher complet pour les futurs utilisateurs). Il peut aussi, en utilisant un accès web au serveur. avoir accès à plus de richesses sur ce service, dont des statistiques divers sur l'utilisation du service, des informations sur les requérants, etc. Grâce à sa structure distribuée et grâce à son accès bimodal web û mobile, ce service d'un type nouveau se substitue à la fois à un service vocal de réservation et à un système d'information et de gestion classique. Le service transactionnel de réservation, basé sur une paire complémentaire de partie mobiles, l'une pour le client et l'autre pour le fournisseur et sur un serveur de médiation et de gestion est nouveau. 3/ service d'interaction entre univers réel et univers virtuel : il s'agit de permettre d'entrer dans un monde virtuel avec les outils de communications du monde réel (connexion téléphonique, accès à une messagerie instantanée, telle que IM , marque déposée ou courrier électronique, ou mail ). La nouveauté repose sur le fait que l'on peut connecter deux avatars entre eux en cachant leur identité dans la vie réelle. La prise en compte du profil de l'avatar est intégrée dans l'utilisation d'un filtre de voix, par exemple une filtre transposant les fréquences vocales dans les aigus pour la voix d'un homme qui choisit un avatar féminin. Pour la mise en oeuvre de ce service d'interaction entre univers réels et virtuels : - la plate-forme mise en oeuvre par le serveur permet de référencer les identités de chaque utilisateur dans différents environnernents ou mondes virtuels, - la plate-forme reçoit et traite les messages qui proviennent de différents mondes virtuels et - pour chaque identité reconnu, la plate-forme procède au routage de messages vers le canal adapté/configuré par l'utilisateur (propriétaire de l'identifiant). Par exemple, dans le monde virtuel MV1, l'utilisateur U1 possède l'identifiant ul et une personne U2 de ce monde virtuel MV1 possède l'identifiant u2. - ul appelle u2 en utilisant le service MV1, - l'application supportant le service d'interaction fait une demande de mise en relation dans le monde MV1 de ul avec u2 (sans connaître l'identité réelle de U2), - le service d'interaction obtient les coordonnées de U2, - le service d'interaction transmet la demande à l'ICU (voir figure 7), qui effectue l'ensemble des actions associées à U2 (si U2 n'est pas identifié sur l'ICU, seul l'appel est possible), - le service d'interaction déclenche les actions liées à U2 (paramétrage de l'ICU) ou un simple appel de ul (car ce service connaît le numéro du demandeur abonné) vers u2 si U2 n'est pas connu.

Ce qui est décrit ci-dessus est vrai pour tout type de messages pouvant être émis d'un monde MV1 vers le monde réel ou d'un monde MV1 vers un monde MV2 ou au sein d'un même monde virtuel MV1. 4/ service de panneau publicitaire sur mobile : il s'agit d'offrir une infrastructure qui permette à des annonceurs de publier des informations sur une page dédiée. Le concept de ce service publicitaire repose sur celui d'un message publicitaire qui apparaît dans l'espace utilisateur de temps à autres, ce message comportant préférentiellement une information liée au profil de l'utilisateur. Pour la mise en oeuvre de ce service publicitaire : -l'utilisateur dispose d'un espace publicités qui réside en permanence sur son téléphone (suivant l'abonnement qu'il a pris, il est plus ou moins invité à consulter cet espace), - lorsqu'un service est sollicité par l'utilisateur, la plate-forme supportant le service publicitaire détermine s'il existe un élément publicitaire qui est connexe à sa demande, - si la plate-forme trouve au moins un élément publicitaire connexe, l'espace publicitaire est enrichi d'au moins une nouvelle publicité et l'utilisateur en est informé. Dédié aux annonceurs, cet espace se remplit en fonction d'algorithmes complexes incluant la cible que l'annonceur souhaite atteindre et le nombre de publications qu'il souhaite avoir. Cet espace peut aussi être utilisé pour transmettre des messages ciblés, par exemple, de l'information publicitaire que l'utilisateur à accepter de recevoir, sur divers supports. 5/ service d'ADN Numérique : il s'agit d'une modélisation d'un individu au travers d'une chaîne de données binaires. Ce service met en oeuvre une suite de propriétés binaires qui peuvent représenter tout individu, à la fois ce qu'il est et ce qu'il aime. Cette description universelle et publique du génome numérique peut être utilisée pour faire du pattern matching (en français correspondance de motifs ou de profils) efficace entre individu. 6/ service Push to Get : il s'agit d'offrir une infrastructure de communication de type prompteur sur mobile qui puisse être interactive. Le mobile est abonné à un flux de messages immédiats qui défilent en fonction de l'actualité produite par une source authentifiée (par exemple AFP , auféminin.com , Auto/moto , marques déposées). L'utilisateur peut demander plus d'information en appuyant sur une certaine touche du mobile au moment où le message apparaît. En réponse, le serveur prend en compte le message objet de la demande et construit un dossier qui est envoyé à l'utilisateur sur le média qu'il a choisi (courrier électronique, vocal, services objets de la présente invention). 7/ service de Tamagoshi (marque cléposée) : il permet de créer des objets vivants virtuels (animaux ou autres) et de les animer seul ou en communauté depuis son/ses services. Des objets/classes mis en oeuvre du côté serveur gèrent des comportements de l'animal virtuel. L'utilisateur peut dériver ces classes et créer d'autres animaux ou mondes virtuels. On note que les échanges entre le serveur et les mobiles sont gérés par le serveur. Chaque élément constituant l'animation de ha vie du Tamagoshi est mis en correspondance avec une touche du téléphone, par l'intermédiaire d'une icône. 8/ service de matchs : il met en relation deux équipes, des règles pour se passer un ballon d'un utilisateur à l'autre et des conditions d'interception et de tir au but. 9/ service collaboratif : l'infrastructure des services objets de la présente invention permet le développement de services collaboratifs, définis comme des services nécessitant des possibilités d'interaction et de partage entre plusieurs utilisateurs. On rappelle que des services classiques de lecture d'information partagée, à laquelle plusieurs utilisateurs peuvent accéder à partir de leur mobile, en lecture seulement, ne sont pas considérés comme collaboratifs. Le nouveau service offert, en termes collaboratifs, consiste à mettre en oeuvre ensemble les éléments suivants : - une application distribuée ayant : - une partie centralisatrice résidant sur Internet ; c'est la partie serveur, -plusieurs parties distribuées sur des terminaux mobiles û les parties clients mobile, accédant à la partie serveur via le protocole GML, - des accès via des navigateurs web, sur des parties clients léger, sur PC, - des interactions entre la partie serveur et d'autres applications résidant sur d'autres serveurs web, utilisant des API ou web services sur internet, - la possibilité donnée aux parties mobiles de fournir des informations (données, requêtes) à la partie serveur et aux autres parties mobiles, via la partie serveur, et - la possibilité donnée aux parties clients d'accéder et de modifier simultanément des données partagées gérées par la partie serveur. Dans ce service objet de la présente invention, une application dédiée qui permet le partage et les transactions est présente dans les parties mobiles. Sur ce principe, plusieurs services collaboratifs sont offerts par le système, dont Glog , une extension du concept de blog pour mobiles. Glog est une base de données partagées résidante sur et gérée par la partie serveur. Cette base de données permet un accès ordonné à des données qui lui sont soumises. Les données soumises à Glog sont tout objet pouvant être générer et transmis par un mobile (texte, photo, son, vidéo, message vocal, données structurées par GML tel signal social, identification d'un service et choix d'action dans ce service, etc). Les données, stockées par Glog, sont ordonnées suivant plusieurs critères - fil de discussion (thread), thème, - date/heure et - origine. Un fil de discussion est un ordonnancement linéaire basé sur la notion de réponse : un fil à un point de départ puis une navigation simple par suivant / précédent (en lecture), et une réponse à un fil ajoute simplement un élément en fin de fil, en agrandissant ainsi la taille. Un fil Glog choisi peut être accédé en lecture par un mobile via un service objet de la présente invention : les derniers éléments, au nombre maximum de neuf, sont accessibles via une page de service dédiée puis affichés à la demande selon leur format (texte, son, image, etc). L'accédant à un fil peut y ajouter un élément (réponse). Les fils sont hétérogènes et peuvent contenir des éléments de tout type. Le thème est une méta-donnée sélectionnée par le créateur d'un fil. Le thème permet aux lecteurs de fils de faire des recherches ciblées. Comme Glog est, à l'instar de tout service objet de la présente invention, conçu pour l'ubiquité d'accès web û mobile, le thème peut-être librement choisi à la création si la création (initialisation d'un fil) est faite à partir du site web. Si la création est faite à partir d'un mobile, le créateur peut soit également choisir librement un thème en entrant un texte, soit choisir un thème parmi neuf via une page dédiée. Les neuf thèmes proposés sont soit les neuf thèmes que l'utilisateur à choisi sur son profil, via le web (philosophie générale de préparation via le web de son propre espace mobile, qui, une fois mobile, n'est plus aussi exhaustif que le web, mais est ciblé pour son usage propre, pertinent et rapide), soit les neuf thèmes les plus utilisés sur Glog, tel que calculés par le système et proposés à l'utilisateur. En accès d'un fils existant, le lecteur peut également sélectionner un thème via cette même fenêtre de thèmes, ou sélectionner via la fenêtre qui indique les neuf fils les plus actifs, ou encore via sa fenêtre d'abonnement à ses neuf fils préférés, tel qu'il peut le définir sur son profile de glogeur, via le web.

Le champ Date et heure permet, d'une part, une organisation chronologique mais aussi, via un accès web, des recherches dans le temps (alors que l'accès mobile donnera par défaut les neuf dernières entrées dans chaque fil). Le champ origine est l'identité de l'utilisateur qui a initialisé le fil ainsi que l'identité, pour chaque entrée dans le fil, du contributeur. La partie serveur de glog utilise ce champ également pour calculer, et offrir via un accès web, des statistiques d'activité par du glog ou de l'utilisateur. On note que le glog peut-être utilisé en conjonction du service gVote qui permet, génériquement, à chaque utilisateur d'allouer un statut (parmi un maximum de neuf statuts prédéfinis pour chaque instance du service gVote) à un candidat (parmi un maximum de neuf candidats prédéfinis pour chaque instance du service gVote). Une instance typique de gVote peut être d'allouer une note (en anglais rating ) à un objet (service, photo, fil de discussion, événement, etc). En conjonction de Glog, gVote permet donc aux utilisateurs de noter les fils de discussions, les thèmes, les contributions et les contributeurs. La partie mobile de gVote permet de donner une note et d'afficher le résultat courant, alors que la partie serveur, accédée via le web, permet d'afficher une grande richesse de résultats historiques et statistiques, enrichissant ainsi Glog. 10/ Un autre service collaboratif est le service d'alarme partagée. C'est un élément d'un ensemble de services autour de l'organisation du temps au sein d'un groupe de personne ; cet ensemble comprend, entre autres, un agenda partagé, offert par une application web tierce, et vers laquelle la partie serveur fait de la médiation, permettant ainsi à des utilisateurs mobiles d'accéder, tant en lecture qu'en écriture, à un agenda partagé. Le service d'alarme rentre dans cette catégorie. II comprend deux différences structurelles avec l'agenda : d'une part, il est intégralement géré par le système et ne requiert pas de médiation vers un service tiers et, d'autre part, il nécessite un traitement d'évènements dans les parties mobiles Le service d'alarme de groupe fonctionne de la façon suivante : un utilisateur utilise son interface mobile ou web pour sélectionner la date et l'heure d'une alarme et l'audience de cette alarme. Il peut sélectionner également les médias utilisés par le système pour informer l'audience cle l'alarme, lorsqu'elle se déclenche. Sauf telle sélection spécifique (mail, appel par serveur vocal automatique, etc), le système va fonctionner en deux étapes : - le serveur du service alarme , sur réception d'une requête d'alarme de groupe, ajoute un élément correspondant dans la boite d'événements de chaque membre du groupe destinataire qui est un utilisateur de services objets de la présente invention ; - lorsque ces utilisateurs vont mettre à jour leurs évènements, par le mécanisme générique de gestion et de notification d'événements de service, GML envoie à leur partie mobile respective un message d'armement de leur alarme locale. Ces utilisateurs sont alors avertis du déclenchement de l'alarme localement par leur mobile. L'intérêt de cet armement à distance (par opposition à notification de l'alarme à distance) est que les destinataires sont alarmés même s'ils ne sont pas en réception du service lors de l'heure de l'alarme et - pour les destinataires non utilisateurs de services objets de la présente invention, ou pour les destinataires qui n'auraient pas synchronisé leur gestionnaire d'évènements avant l'heure de l'alarme, la partie serveur du service alarme envoie un message par un canal sélectionné par l'utilisateur qui à organisé cet alarme ; typiquement, un SMS. Une alarme de groupe ainsi organisée comprend donc une heure et date, une audience, mais aussi un thème , qui peut être un texte libre ou un thème parmi neuf sélectionnables via une fenêtre de choix dédiée. Comme dans tout autre service objet de la présente invention, ces neuf thèmes sont soit les thèmes préférés de l'utilisateur définis dans son profile pour ce service, via le web, soit, par défaut, les neuf thèmes les plus probables calculés et proposés par le système basé sur les profiles d'usages de ce service. On note, concernant le service de gestion d'évènements de services objets de la présente invention, que plusieurs cas d'usage de service nécessitent de notifier un utilisateur qu'un évènement le concerne. Le serveur du système n'ayant pas la capacité d'envoyer spontanément une requête à un utilisateur client mobile, il ne peut pas lui-même notifier l'utilisateur de l'évènement qui le concerne. Le mécanisme générique utilisé est donc le suivant : - d'abord, pour chaque utilisateur, il existe dans le serveur, un espace où les évènements relatifs à cet utilisateur sont stockés, en fonction de leur heure d'arrivée et de leur priorités (ces évènements peuvent avoir des sources variées et hétérogènes telles qu'un service autonome nécessitant un envoi d'information ou de notification à un utilisateur, ou un service collaboratif par lequel un autre utilisateur souhaite interagir avec cet utilisateur, soit encore une requête provenant d'un service tiers pour lequel le système fait de la médiation vers les utilisateurs mobiles). Cet espace événements est répliquée sur le mobile lors d'opération de synchronisation : la partie mobile vient s'informer automatiquement de l'état de l'espace évènement. L'espace évènement est, lui-même, organisé selon la structure d'arborescence ayant, préférentiellement, un maximum de neuf branches à chaque noeud. - ensuite la partie mobile û ou l'utilisateur lui-même pour les notifications ne menant pas à des opérations automatique û peut traiter ces événements comme nécessaire. La partie mobile va s'enquérir du besoin éventuel de synchronisation de la liste d'évènement à chaque fois qu'un accès au serveur web est requis ; ainsi, la synchronisation est fréquente. Par ailleurs, un polling (tirage au sort d'instants) additionnel, paramétrable par l'utilisateur, assure une synchronisation périodique qui, elle-même, assure que les évènements ne deviennent pas trop obsolètes même en cas de période prolongée sans accès au serveur par la partie mobile. Et, finalement, pour les évènements de haute priorité, un SMS (ou autre média choisi par l'utilisateur, comme un appel vocal synthétisé ou un courrier électronique) est envoyé à l'utilisateur, dans le cas où l'évènement prioritaire est imminent et où que la dernière synchronisation est ancienne. 11 / service de Messagerie inversée : dans ce nouveau mode de traitement de la messagerie électronique, on n'a qu'une seule instance du message, qui est stockée sur le serveur de l'émetteur. Les destinataires du message viennent lire le message sur le serveur de l'émetteur.

Ce mode de traitement est particulièrement adapté aux messages entre correspondants identifiés au sein d'une même organisation ou ensemble communautaire. Lorsqu'un message est envoyé par un émetteur E vers des destinataires Dn, les destinataires sont avertis que E leur a envoyé un message. Chaque destinataire Dn peut alors se connecter au serveur de E avec son identifiant (sécurisé) et de ce fait lire tous le message que E a envoyé à Dn. Si E a envoyé plusieurs messages à Dn alors Dn verra la liste des messages que E lui a envoyés (nouveaux et anciens).

Si l'émetteur E souhaite envoyer un message à un destinataire D avec qui il n'a pas établi de relation de confiance, le serveur envoie un mail suivant la méthode classique pour demander au destinataire s'il accepte d'établir une relation de confiance avec E. Si le destinataire accepte, il est connecté à E et réciproquement. Cette nouvelle approche de la messagerie permet: - de réduire la consommation d'espace mémoire sur les serveurs de messagerie, - de supprimer de fait les messages non sollicités, ou spams , car, pour envoyer un message vers un destinataire, il faut que celui-ci ait établi la relation de confiance. Dans l'établissement de la relation de confiance, il n'y a pas la possibilité de passer un quelconque message ou pièce attachée, - à l'émetteur de savoir si le message a été lu par un ou par l'ensemble des destinataires, - de gérer une notion nouvelle d'un message envoyé aux seuls premiers (définis par un nombre prédéterminé par l'émetteur du message) qui le lisent : un émetteur E peut émettre un message vers N destinataires en mentionnant que dès qu'au moins un nombre X de destinataires ont lu le message les autres ne sont plus notifiés qu'ils ont un message à lire, - de gérer des dates de validité sur un message, -de mieux déceler un problème de messagerie interne ou externe car si le message n'est pas lu par un ou plusieurs des destinataires c'est qu'il y a un problème potentiel. - de limiter la visibilité de certaines parties d'un même message en fonction de la catégorie des destinataires (gestion de liste de diffusion restreinte), - de limiter la diffusion/prolifération d'un message en ne permettant pas de le rapatrier en local sur le poste du destinataire. Si E ne souhaite pas que le message soit diffusé ou rapatrié par le ou les destinataires, il utilise une option de chiffrement ( encryption ) qui ne permettra que la copie d'écran pour dupliquer le contenu et - de retirer ou d'éditer un message émis. L'approche de la messagerie inversée est appropriée à la notion de diffusion sur plusieurs canaux hétérogènes. Le serveur de l'émetteur peut supporter plusieurs classes de lecteurs : - applications spécifiques (lecteur, cu reader , sur ordinateur ou mobile), - utilisation d'un client de messagerie classique et - application Web (utilisable depuis un navigateur sur PC ou téléphone). 12/ La présente invention concerne aussi la notion de widgets complémentaires . C'est-à-dire que des services proposés comportent la notion de Yin et de Yang applicatifs : deux service complémentaires permettent de proposer un service complet (c'est le cas du signal social par exemple, ou pour la réservation de restaurant décrite ci-dessus). 13/ service de signal Social : les services complémentaires Social Picker et Social Reader visent à proposer la fonctionnalité de présence sociale . Le Social Picker permet aux utilisateurs de dire où ils sont, ce qu'ils font, avec qui ils sont, comment ils vont etc... via le portail de services objets de la présente invention. Le social Reader est lui un moyen d'agrégation de tous ces flux. Chaque utilisateur définit qui est membre de sa communauté et il suit les mises à jour de statuts de ces membres. En ce qui concerne la configuration, le social Picker est un service modulable par l'utilisateur : il choisit, sur le portail correspondant, quels sont les types d'informations, la catégorie qu'il veut mettre à jour et communiquer lorsqu'il sera en situation de mobilité. Il peut donc choisir entre une et plusieurs catégories ( quoi , comment , où , etc...).

Une catégorie annexe lui permet aussi de rentrer directement un texte personnalisé. Après avoir sélectionné les catégories qu'il désire pour le social Picker , l'utilisateur peut configurer cette catégorie en y ajoutant de 1 à x actions, représentées par une image (à choisir à partir de la banque d'actions proposées ou en uploadant une image personnalisée).

La configuration du social Reader est relativement simple : il s'agit juste de sélectionner les amis dont les statuts seront visibles et mis à jour automatiquement. En ce qui concerne l'utilisation : pour mettre à jour son statut, l'utilisateur va tout simplement picker ou sélectionner dans le social picker les nouveaux éléments qui le caractérisent. Il peut donc choisir une ou plusieurs catégories à mettre à jour. Pour mettre à jour, il devra juste sélectionner l'icône de l'action. Lorsqu'il a fini de mettre à jour la ou les catégories, il peut valider et les informations sont alors envoyées. Ces informations sont mises à jour et peuvent être visualisées de deux manières différentes : - en allant sur le social picker d'un utilisateur : - en ouvrant le social reader qui affiche alors les x dernières mises à jour des profils amis. Par ailleurs, cette application peut s'interfacer avec d'autres types de services web puisque les informations du statut peuvent être mises en forme (forme de phrase par exemple) et envoyées ainsi à des services tiers ( twitter ). Par le principe de pick d'informations c'est donc une façon très innovante de mettre à jour des outils externes de microblogging disponibles. 14/ les services Notes et Images sont des services qui font partie de la gamme de services bureautiques qui permettent d'afficher du contenu sur le mobile. Grâce à l'architecture du système implémentant la présente invention, l'ubiquité entre le web et le mobile est utilisée par ces services. Le contenu peut donc être modifié à loisir sur le web, et il est mis à jour automatiquement sur le téléphone mobile. Grâce à ces éléments techniques d'instantanéité de services, les utilisations peuvent être nombreuses (mises à jour de listes de courses en temps réel par la personne restée à domicile, travail collaboratif entre une personne mobile et une autre devant un ordinateur connecté au web, etc...) 15/ le service To-do-list fait partie de la catégorie de services bureautiques . II s'agit de donner la possibilité de gérer une liste de tâches. Chaque tâche est représentée par une case de la matrice et dispose de plusieurs paramètres : date limite, catégorie, détail,titre, personne, etc... et enfin un bouton pour marquer la tâche comme effectuée ou non. 16/ le service Agenda fait aussi partie de la catégorie de services bureautiques pour mobile. Il permet de suivre des évènements et est interfacé avec d'autres services qui peuvent venir y insérer des informations etc... Grâce à l'architecture du système implémentant la présente invention, ces services peuvent être accessibles directement via l'agenda. Le service Agenda peut importer et exporter des informations à partir des standards d'utilisations de type Ical etc... 17/ le service Vote permet à l'utilisateur de créer une procédure de vote, ou d'élection, et de le promouvoir à ses amis, pour avoir leur avis sur un sujet. Sur le portail, il suffit à l'utilisateur de sélectionner la queston, ainsi que les réponses (et les icones-images associées) et le service vote est automatiquement créé. L'utilisateur se charge ensuite de définir l'audience du vote, où s'il est public, de simplement en faire la promotion en l'envoyant aux amis. Les utilisateurs qui affichent le service vote sur le mobile peuvent voter par simple sélection de la réponse. Sur le portail, des possibilités supplémentaires sont offertes en ce qui concerne les résultats et les statistiques du vote : on peut suivre l'évolution des scores dans le temps, connaître le nombre de votants etc... De façon très facile, les utilisateurs peuvent donc réaliser des réels sondages et obtenir de précieuses informations sur les amis, les clients etc... 18/ le service QCM (acronyme de questionnaire à choix multiples ) est une extension du service Vote puisqu'il s'agit de mettre à la suite de ce service Vote , un nombre quelconque de questions. A la différence du service vote cependant, les résultats ne seront pas affichés sur le mobile, mais ne seront disponibles que sur le web (et que pour le créateur du questionnaire à choix multiples). De la même manière que pour le service vote , des outils avancés sur le portail web permettent l'administration du service QCM ainsi que la récolte et l'interprétation des résultats. Grâce à l'architecture du système implémentant la présente invention, les utilisateurs peuvent donc, en quelques instants, créer des sondages pour mobiles ce qui leur donne un vecteur très intéressant et instantané de récolte d'informations. 19/ le service Party Planner est un service qui vise à faciliter l'organisation d'événements au sein d'une communauté, C'est un dossier qui permet de créer ou de visualiser des événements, ou events . Pour chaque événement, cela comprend : - le choix du nom, - le choix d'une audience (personnes habilitées à voir et agir sur l'événement), - des votes sur la date, le lieu, l'heure. Ce sont des propositions initiales par l'initiateur de l'événement mais il peut décider d'accepter ou pas les nouvelles propositions, - une liste de tâches (choses à faire, choses à apporter, etc...). L'audience peut ajouter des éléments ou en marquer comme effectués, - une page d'informations, - l'intégration d'un service de conference call (décrit ci-dessus) et - une page de commentaires, pour suivre les évolutions. Ce service est le premier qui permette à des utilisateurs en mobilité de s'organiser sans avoir besoin de faire des aller-retour téléphoniques. C'est la première fois qu'on outil de management , de gestion de projet est proposé à des utilisateurs mobiles. Sur le portail, des outils plus évolués d'administration et de statistiques sont proposés. 20/ le service To-Do List partagée , est le premier service de la gamme de services collaboratifs pour des utilisations de gestion de projet, pour de la bureautique etc... La to-do list partagée est une to-do list qui est modifiable par un groupe de personnes. Cela permet donc de s'organiser à distance lors d'un ensemble de tâches à effectuer etc... Via ce service, les personnes peuvent savoir qui doit faire quoi et surtout qui a fait quoi. 21/ le service Ask the community est un service d'entraide par questions/réponses entre utilisateurs. Lorsque l'utilisateur est en déplacement, en situation de mobilité, il peut avoir besoin subitement d'une information mais il n'a pas accès à internet pour la chercher et la trouver. Via le service, il n'a pas prévu ce besoin donc il n'a pas pu placer le service adéquat dans son espace de services, et il ne se souvient pas de service d'un ami qui répondrait à son besoin (et peut-être n'existe-il pas encore de service associé à ce besoin). Grâce au service Ask the community , il peut envoyer une question à la communauté et celle-ci va se charger de lui trouver la réponse, puisque soit la personne aura la réponse directement soit elle aura un accès web qui lui permettra de chercher sur le net. En d'autres termes, ce service répond à la question de l'utilisateur : je suis en situation de mobilité, j'ai besoin d'une information mais je n'avais pas prévu donc ce n'est pas (encore) dans mon espace de services . Grâce au service Ask the community , les gens peuvent chercher l'information pour cet utilisateur.

Pour inciter les gens à répondre, des outils communautaires sont mis en place pour promouvoir les meilleurs profils, mais la base est que ce soit les micro-communautés qui répondent. En ce qui concerne la configuration, sur le mobile, l'utilisation du service consiste à ouvrir une nouvelle question, que l'on tape via le clavier du téléphone et qui est ensuite envoyée au système. Plusieurs questions peuvent donc être ouvertes en même temps. De l'autre côte, la communauté (ou une micro-communauté) peut s'activer pour répondre à la question. Les personnes (qui ont choisi de qui ils voulaient recevoir les requêtes et questions) ont plusieurs moyens pour recevoir et répondre aux questions venant du service ask the community : via le portail web, via un widget de bureau, via email, via messagerie instantanée mais aussi via un service de réponse. A chaque fois, la solution technique permet de lire la question, et d'y répondre. Lorsque l'utilisateur à reçu la bonne réponse il peut fermer la question et l'archiver, ce qui est aussi visible par la communauté, pour éviter aux retardataires cle répondre par exemple. Le système implémentant la présente invention est le premier outil qui mette en relation une personne isolée avec une communauté connectée. L'environnement garde trace de ces requêtes et peut ainsi faire des propositions de créations de services basés sur les réelles requêtes des utilisateurs. Les services ainsi crées par la personne, par la communauté ou directement par les développeurs spécialisés ont ainsi une très forte chance de répondre à un réel besoin, et de plaire beaucoup aux utilisateurs. Le système peut aussi chercher pour voir si la question n'a pas été déjà posée et si la réponse n'existe pas. 22/ le service Sudoku (marque déposée) concerne un jeu bien connu du grand public. Ce service envoie une matrice 9x9 et l'utilisateur peut la remplir ensuite à son rythme, en plusieurs fois etc... sans aucun accès web. Ce n'est que lorsque l'utilisateur choisit d'envoyer que les informations sont envoyées pour vérification etc. 23/ le service Poker met en oeuvre les capacités collaboratives du système implémentant la présente invention. Grâce à ces capacités, Il est possible de faire des parties de poker asynchrones. C'est-à-dire que la partie ne continue que lorsque tous les participants ont effectué leur action. Un log permet de suivre ces actions. 24/ le service Inbox correspond à un dossier Inbox qui regroupe deux types d'éléments : d'une part les services qui ont été envoyés et proposés par la communauté (communauté d'amis, abonnements à des services, directement par le système etc...) et - d'autre part tous les logs d'évènements des services. Cet inbox permet donc de recevoir tous les éléments. 25/ les services applicatifs transactionnels répondent à des demandes très connues des utilisateurs : horoscope, programme télévisuel, programme de cinémas, météo, flux RSS etc... Grâce à l'architecture du système implémentant la présente invention, qui permet de segmenter et profiler les utilisateurs du service, il est possible de proposer le contenu qui va plaire à l'utilisateur ou, tout au moins, lui correspondre. Par un système de filtres, on propose uniquement le contenu dont l'utilisateur est susceptible d'avoir besoin. Les programmes de cinéma ou télévisuels peuvent donc être configurés sur le portail web par l'utilisateur mais ils seront ensuite proposés dynamiquement, selon les critères définis et selon des similitudes détectées.

Claims (8)

REVENDICATIONS

1 - Procédé de transformation de pages de la toile, caractérisé en ce qu'il comporte, au cours d'une étape (1305 à 1350) de réception d'une page de la toile : - une étape (1315, 1320) d'extraction d'au moins un lien hypertexte du contenu de la page et - une étape (1312, 1320 à 1340) d'affichage de chaque lien extrait du contenu de la page.

2 û Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape (1320 à 1340) d'affichage, on associe au moins un lien extrait avec une représentation graphique et on affiche ladite représentation graphique sur un écran.

3 û Procédé selon la revendication 2, caractérisé en ce que, au cours de l'étape (1315, 1320) d'extraction, on extrait au moins une dite représentation graphique du contenu de la page en cours de réception.

4 û Procédé selon l'une quelconque des revendications 2 ou 3, caractérisé en ce que, au cours de l'étape (1312) d'affichage, on associe un lien avec une dite représentation graphique extraite du contenu de la page en cours de réception, en fonction de la résolution de l'écran d'affichage.

5 û Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que, au cours de l'étape (1312) d'affichage, on associe un lien avec une dite représentation graphique extraite du contenu de la page en cours de réception, en fonction de la vitesse de réception de la page.

6 û Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que, au cours de l'étape (1312) d'affichage, on associe un lien avec une dite représentation graphique extraite du contenu de la page en cours de réception, en fonction d'une durée estimée de réception de la page.

7 û Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, à la fin (1350) de l'étape de réception de la page, on donne accès au contenu de la page par l'intermédiaire d'une représentation graphique dédiée, tout en maintenant l'affichage de liens extraits du contenu de la page.

8 û Dispositif de transformation de pages de la toile, caractérisé en ce qu'il comporte un moyen de réception d'une page de la toile et un moyen de traitement adapté, au cours de la réception de la page : - à extraire au moins un lien hypertexte du contenu de la page et - à faire afficher chaque lien extrait du contenu de la page.9 - Programme d'ordinateur, caractérisé en ce qu'il comporte des instructions exécutables par un ordinateur pour implémenter un procédé selon l'une quelconque des revendications 1 à 7. 10 - Support d'information lisible par un ordinateur et comportant des instructions 5 exécutables par un ordinateur pour implémenter un procédé selon l'une quelconque des revendications 1 à 7.