FR2882875A1 - Procede et dispositif de mise en relation automatique de terminaux proches - Google Patents

Abstract

Le procédé comporte une procédure de détection mutuelle en tâche de fond comportant en alternance :. une étape de détection des terminaux détectables (200) et. une étape au cours de laquelle le terminal est lui-même détectable (400).Préférentiellement, le procédé comporte, pour au moins un cycle, une étape de tirage aléatoire et, en fonction du résultat dudit tirage, une étape de définition, pour ce cycle, de la durée d'au moins une des étapes de détection ou de détectabilité.

Description

PROCEDE ET DISPOSITIF DE MISE EN RELATION AUTOMATIQUE DE TERMINAUX

PROCHES

La présente invention concerne un procédé et un dispositif de mise en relation automatique de terminaux proches. Elle s'applique, en particulier, à la communication sans fil par ondes radio à courte portée (appelée en anglais "Short range wireless").

On connaît de nombreux moyens d'aider les personnes qui se trouvent géographiquement proches, à rentrer en contact. On peut citer, par exemple, les badges qui identifient les personnes et permettent aux autres personnes de déterminer si elles ont une raison de rentrer en contact. On peut aussi citer les annonces classées des journaux locaux, les sites de la toile ("web" en anglais) qui utilisent un critère géographique pour mettre en correspondance deux utilisateurs et les services de rencontre par minimessages (en anglais "SMS" acronyme de "short message system") proposés par les opérateurs de téléphonie mobile.

Ces moyens présentent de nombreux inconvénients: leur mise en oeuvre est onéreuse lorsqu'ils utilisent des supports physiques, le critère géographique n'est pas assez précis et représente, en général, le domicile ou le lieu de travail des personnes et non leur réelle position "nomade" ou mobile, ils manquent de confidentialité puisqu'ils imposent la présence d'un tiers ou opérateur et, souvent, le stockage de données dans un système informatique.

Il est très facile d'établir manuellement une liaison durable entre deux appareils placés à proximité munis de systèmes de communication sans fil à courte portée, par exemple mettant en oeuvre le standard "Bluetooth" (marque déposée). En revanche, ni l'établissement, ni l'interruption de cette communication ne sont automatiques.

La communication sans fil Bluetooth sert essentiellement à remplacer des câbles. On crée une liaison Bluetooth. On met l'un des appareils en mode détectable et un autre en mode détection. On sélectionne le premier appareil parmi tous ceux qui ont été détectés par le deuxième, puis on établit la liaison. Parfois, il faut que le premier appareil accepte la liaison. Parfois, il faut même saisir un code identique sur les deux appareils pour créer la liaison. De plus, les terminaux de communication sans fil à courte portée ne sont pas capables d'effectuer simultanément plusieurs fonctions de communication. Ils ne peuvent pas en même temps détecter les autres terminaux, être détectables, tenter d'établir des connexions et échanger des données.

La présente invention vise à donner à des utilisateurs de dispositifs mobiles munis de systèmes de communication à courte portée, un moyen automatique de rentrer en contact et d'échanger des informations, s'ils le désirent. Ces informations peuvent représenter toute ou partie de l'identité de l'utilisateur, ce qu'il recherche, ce qu'il offre ou qui il souhaite rencontrer, par exemple.

D'une manière générale, la mise en oeuvre de la présente invention permet de développer des applications de communication par liaison sans fil à courte portée comportant une détection automatique, en tâche de fond, des autres terminaux susceptibles de communiquer, puis une connexion avec ces terminaux et un échange de données automatisé.

Plus précisément, la présente invention vise, dans le cas de la mise en oeuvre du standard Bluetooth, à permettre une détection entre terminaux et un échange de données automatique en moins d'une minute.

Selon un premier aspect, la présente invention vise un procédé de mise en relation automatique de terminaux proches, caractérisé en ce qu'il comporte une procédure de détection mutuelle en tâche de fond comportant en alternance, dans un cycle: une étape de détection des terminaux détectables et une étape au cours de laquelle le terminal est lui-même détectable.

Grâce à ces dispositions, le terminal "local" peut entrer en communication avec un autre terminal "distant", en permanence et en tâche de fond, ou à la demande, sans avoir aucune connaissance préalable du terminal distant.

Pour l'utilisateur, le terminal alternant ces étapes semble être en même temps et en permanence détectable et en train de détecter les autres terminaux.

Grâce à ces dispositions, un terminal mettant en oeuvre le procédé objet de la présente invention peut détecter automatiquement tout autre terminal susceptible de communiquer avec lui, sans perturber les applications fonctionnant en premier plan sur ledit terminal. Si au moins deux terminaux mettant en oeuvre le procédé objet de la présente invention se trouvent à portée l'un de l'autre, chacun des terminaux peut détecter chaque autre terminal se trouvant à portée.

Une liaison de courte durée entre des équipements de différentes personnes est ainsi établie de façon rapide et automatique sans demande spécifique de leur part.

La présente invention permet ainsi la mise en place de communications automatiques, directes et complexes entre des terminaux sans passer par un serveur central grâce à une technologie de communication sans fil à courte portée, par exemple la technologie Bluetooth.

Selon des caractéristiques particulières, le procédé comporte, pour au moins un cycle, une étape de tirage aléatoire et, en fonction du résultat dudit tirage, une étape de définition, pour ce cycle, de la durée d'au moins une des étapes de détection ou de détectabilité.

Grâce à ces dispositions, si deux terminaux mettant en oeuvre le procédé objet de la présente invention sont synchronisés et qu'ils ne peuvent pas se détecter puisqu'ils sont simultanément détectables puis simultanément en recherche de détection, le tirage aléatoire permet de les désynchroniser rapidement, permettant ainsi leur détection mutuelle.

Selon des caractéristiques particulières, le tirage aléatoire est équiprobable et définit la durée de l'étape de détectabilité en fonction d'un multiple de la durée de l'étape de détection et du résultat du tirage aléatoire.

Par exemple, la durée D de l'étape de détection est fixe. A chaque cycle, la durée de l'étape de détectabilité est définie aléatoirement et peut prendre trois valeurs différentes équiprobables: 2D, 3D, ou 4D. De cette façon, deux terminaux parfaitement synchronisés au cours d'un cycle ont deux chances sur trois de choisir des durées différentes et d'être suffisamment désynchronisés pour se détecter au cycle suivant. Le temps consacré aux étapes de détectabilité est alors, en moyenne, trois fois plus important que le temps de détection.

Selon des caractéristiques particulières, une fois qu'un terminal a détecté un autre terminal susceptible de communiquer, il effectue au moins une tentative de connexion à cet autre terminal. Grâce à ces dispositions, la connexion entre ces terminaux est automatique.

Selon des caractéristiques particulières, le nombre de tentatives de connexion successives avec le même terminal est inférieur à une valeur prédéterminée. Grâce à ces dispositions, on évite de consacrer une part trop importante du cycle aux tentatives de connexion et on conserve du temps pour les autres étapes de détection et de détectabilité.

Selon des caractéristiques particulières, si des tentatives de connexions avec plusieurs terminaux sont à effectuer, on ne tente pas plusieurs fois de suite de se connecter au même terminal. Grâce à ces dispositions, on augmente les chances de se connecter à un des terminaux avec lesquels on tente successivement de se connecter.

Selon des caractéristiques particulières, un nombre limite de tentatives de connexion par terminal est défini, lorsque ce nombre de tentatives est atteint sans qu'une connexion puisse être établie, on attend pendant au moins une durée prédéterminée, avant d'effectuer de nouveau au moins une tentative de connexion avec ce terminal.

Dans l'art antérieur, pour qu'un terminal reconnaisse un autre terminal susceptible d'échanger des données, il doit, après la détection de l'autre terminal, soit tenter d'établir une connexion, soit effectuer une reconnaissance grâce à un protocole de découverte connu sous le nom de "Service Discovery Protocol". Chacune des ces procédures consomme 10 à secondes par terminal détecté.

Or, pour faire communiquer entre eux deux terminaux, il serait intéressant qu'avant même d'établir une connexion, dès la détection, le terminal détecté soit reconnu comme susceptible ou non de communiquer avec les applications du terminal qui l'a détecté.

Le deuxième aspect de la présente invention vise à remédier à ces inconvénients. A cet effet, selon un deuxième aspect, la présente invention vise un procédé de mise en relation automatique de terminaux proches, caractérisé en ce qu'il comporte: - une étape de modification du nom détectable du terminal pour y incorporer un signe de reconnaissance d'une application prédéterminée en fonctionnement et susceptible d'échanger des données avec d'autres terminaux et - pendant une étape de détectabilité, en cas de détection par un autre terminal, une étape de transmission dudit nom détectable.

- pendant une étape de détection, en cas de détection d'un autre terminal, une étape d'analyse du nom du terminal détecté afin d'y rechercher ledit signe de reconnaissance.

Grâce à ces dispositions, dès la détection du terminal, l'autre terminal qui l'a détecté est capable de savoir qu'une application prédéterminée est susceptible de communiquer avec lui, sans avoir à établir de liaison avec ce terminal, par la simple analyse de son nom détectable. Ainsi le terminal ne tente d'établir une connexion qu'avec les terminaux reconnus comme susceptibles d'accepter cette connexion et évite de perdre du temps à tenter de se connecter aux autres.

Selon des caractéristiques particulières, au cours de ladite étape de modification du nom détectable, on ajoute au moins un caractère reconnaissable en début du nom détectable.

Selon des caractéristiques particulières, au cours de l'étape de modification de nom détectable, on ajoute le caractère ")" au nom détectable.

Selon des caractéristiques particulières, au cours de l'étape de modification du nom détectable, on modifie le nom détectable pour y incorporer soit un premier signe de reconnaissance indiquant l'installation sur ledit terminal d'une application prédéterminée, ladite application étant arrêtée, soit un deuxième signe de reconnaissance indiquant l'installation sur ledit terminal de l'application prédéterminée, ladite application étant en fonctionnement.

Grâce à ces dispositions, le terminal qui a détecté ledit terminal peut agir de manière différente selon les cas, par exemple pour envoyer ladite application lorsqu'elle n'est pas installée, c'est-à-dire lorsque aucun des deux signes de reconnaissance n'a été incorporé dans le nom détectable.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de recherche de détection d'au moins un terminal possédant un nom détectable possédant ledit signe de reconnaissance, et cette étape est interrompue dès qu'un tel terminal a été détecté.

Selon des caractéristiques particulières, au cours de l'étape de modification du nom détectable du terminal, on y incorpore plusieurs informations organisées selon un format prédéterminé.

Selon des caractéristiques particulières, les dites informations comportent: - une identification de leur format et - des informations organisées selon ledit format.

Selon des caractéristiques particulières, en cas de détection d'un autre terminal, on effectue une étape d'analyse du nom du terminal détecté afin d'y rechercher lesdites informations.

Dans l'art antérieur, les liaisons sans fil à courte portée étant mises en place sur l'initiative de l'utilisateur, et généralement entre deux terminaux choisis à l'avance, comme indiqué ci-dessus, il n'est pas nécessaire d'optimiser les procédures de mise en communication des terminaux, par exemple lorsque plusieurs tentatives de connexion successives échouent.

Dans le cas de liaisons automatiques de courte durée, il serait intéressant d'éviter des échanges de données inutiles, notamment lorsque, après détection, l'établissement d'une liaison entre deux terminaux pose problème. En particulier, il peut y avoir d'autres terminaux accessibles et un terminal ne doit pas perdre trop de temps à entrer en communication avec un terminal particulier, puisque la durée de maintien à courte portée des autres terminaux peut être limitée.

Le troisième aspect de la présente invention vise à remédier à ces inconvénients. A cet effet, la présente invention vise un procédé de mise en relation automatique d'un terminal utilisateur avec des terminaux proches, caractérisé en ce qu'il comporte: - une étape de détection d'un autre terminal et - une étape de mémorisation d'au moins: un identifiant dudit autre terminal et la date de la dernière de ces tentatives.

Grâce à ces dispositions, on peut tenir compte des difficultés à établir une liaison pour décider de poursuivre, ou non, lesdites tentatives et, si oui, à quel moment.

Selon des caractéristiques particulières, au cours de l'étape de mémorisation, on mémorise, en outre, un nombre de tentatives d'établissement de connexion avec ledit autre terminal déjà effectuées.

Grâce à ces dispositions, on peut tenir compte de ce nombre pour décider de poursuivre, ou non, lesdites tentatives et, si oui, à quel moment.

Selon des caractéristiques particulières, après un nombre prédéterminé de tentatives infructueuses concernant un autre terminal, on arrête les tentatives d'établissement de liaison avec ledit autre terminal.

Selon des caractéristiques particulières, au cours de l'étape de mémorisation, on mémorise, en outre, si une application prédéterminée fonctionne sur ledit autre terminal.

Grâce à ces dispositions, on peut tenir compte de la présence de cette application pour décider de poursuivre, ou non, lesdites tentatives et, si oui, à quel moment. Par exemple, lorsqu'une application est susceptible de rendre moins disponible le canal de communication, on augmente le nombre de tentatives d'établissement de liaison.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape de détermination de probabilité de présence et une étape de tentative de connexion au cours de laquelle on tient compte d'une probabilité de présence dudit autre terminal pour déterminer si une tentative de connexion doit être effectuée.

Grâce à ces dispositions, on évite des tentatives de connexion inutiles avec des terminaux qui ne sont plus à proximité.

Selon des caractéristiques particulières, au cours de l'étape de détermination de probabilité de présence, on calcule la probabilité de présence d'un terminal en fonction du nombre d'étapes de détection successives pour lesquelles ledit terminal n'a pas été détecté depuis sa dernière détection.

Selon des caractéristiques particulières, au cours de l'étape de détermination de probabilité de présence, on calcule la probabilité de présence d'un terminal en fonction du fonctionnement d'une application sur ledit terminal et rendant ledit terminal plus difficile à détecter.

Selon des caractéristiques particulières, au cours de l'étape de détermination de probabilité de présence, on calcule la probabilité de présence d'un terminal en fonction du type dudit autre terminal.

Selon des caractéristiques particulières, au cours de l'étape de détermination de probabilité de présence, on calcule la probabilité de présence d'un terminal en fonction de l'historique des détections dudit terminal.

Ainsi, plus un terminal aura été détecté fréquemment, plus la répétition d'une absence de détection signifiera une probabilité de présence faible.

Une autre difficulté de la communication sans fil à courte portée concerne le risque qu'un terminal qui s'était éloigné revienne à portée d'un terminal local et qu'une partie des communications et transferts de données déjà effectués se reproduisent en pure perte. De plus, au cas où plusieurs tentatives d'entrée en communication ont été infructueuses, il serait néfaste, pour la disponibilité du terminal utilisateur, de poursuivre, en permanence, les tentatives d'entrée en communication.

Le quatrième aspect de la présente invention vise à remédier à ces difficultés. Selon ce quatrième aspect, la présente invention vise un procédé de mise en relation automatique d'un terminal utilisateur avec des terminaux proches, caractérisé en ce qu'il comporte: - une étape de mémorisation d'identifiants de terminaux avec lesquels une communication a été établie et - une étape de mémorisation de la date et de l'heure à laquelle une communication a été établie, pour chaque terminal dont un identifiant a été mémorisé.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, en outre, une étape de mémorisation d'un nombre de tentatives d'accès effectuées auprès de chaque terminal dont un identifiant a été mémorisé, au cours d'un cycle ou d'un intervalle de temps prédéterminé.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, en outre, une étape de mémorisation d'identifiants de terminaux avec lequel l'utilisateur ne souhaite pas communiquer.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, en outre, une étape de mémorisation de la date de mise à jour des données déjà transmises à chaque terminal dont un identifiant a été mémorisé.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de détermination d'un mode de communication entre au moins: - un mode de communication dans lequel une application mise en oeuvre par ledit terminal communique avec tout autre terminal, à l'exception de terminaux avec lequel l'utilisateur ne souhaite pas communiquer et - un mode de communication dans lequel une application mise en oeuvre par ledit terminal ne communique qu'avec des terminaux explicitement identifiés en mémoire dudit terminal.

Selon des caractéristiques particulières, dans un mode de communication, l'application ne communique avec aucun autre terminal.

Selon des caractéristiques particulières, dans au moins un mode communication, une partie des informations n'est transmise qu'à des terminaux explicitement identifiés en mémoire dudit terminal.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape d'alerte de détection d'un autre terminal lorsque au moins une durée prédéterminée s'est écoulée depuis sa dernière détection.

Dans l'art antérieur, une fois qu'un terminal a été détecté, la liaison est considérée comme permanente jusqu'à une demande explicite de déconnexion de la part de l'utilisateur.

L'art antérieur s'intéresse en effet, à des applications de la communication à courte portée dans lesquelles les terminaux sont fixes.

Or, il peut être intéressant de prévoir des applications dans lesquelles les terminaux sont mobiles et l'art antérieur ne résout pas le problème de la déconnexion d'un terminal trop éloigné pour communiquer.

Le cinquième aspect de la présente invention vise à remédier à ces inconvénients. A cet effet, le cinquième aspect de la présente invention vise un procédé de mise en relation automatique de terminaux proches, caractérisé en ce qu'il comporte: - une étape de détection d'au moins un autre terminal et - une étape d'estimation de probabilité de présence de chaque dit autre terminal. Selon des caractéristiques particulières, au cours de l'étape d'estimation de probabilité de présence, à chaque fois qu'un autre terminal est détecté, sa probabilité de présence est maximale et cette probabilité décroît ensuite progressivement.

Selon des caractéristiques particulières, au cours de l'étape d'estimation de probabilité de présence, la probabilité de présence décroît en fonction du nombre de fois où un autre terminal n'est pas détecté.

D'autres avantages, buts et caractéristiques de la présente invention 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 des tâches effectuées par chaque terminal, dans un mode de réalisation particulier du procédé objet de la présente invention, et leurs relations; - la figure 2 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'initialisation illustrée en figure 1; - la figure 3 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche de recherche de terminaux illustrée en figure 1; - la figure 4 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche de balayage de liste de terminaux illustrée en figure 1; - la figure 5 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'attente de connexion illustrée en figure 1; - la figure 6 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche de tentative de connexion illustrée en figure 1; - la figure 7 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'envoi illustrée en figure 1; - la figure 8 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 1; - la figure 9 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 1; - la figure 10 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 8; - la figure 11 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 8; - la figure 12 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 8 et - la figure 13 représente des échanges de données entre deux terminaux dans la mise en oeuvre du mode particulier de réalisation illustré dans les figures 1 à 12.

Dans toute la description, on appelle "l'application", une application logicielle fonctionnant sur un terminal portable et qui implémente chacun des aspects de la présente invention dans un mode de réalisation particulier du procédé objet de la présente invention.

Le statut de l'application peut prendre une valeur "active", lorsque l'application est lancée et une valeur "inactive", lorsque l'application est arrêtée.

On observe, en figure 1, une tâche 100 d'initialisation, d'activation de l'application et de changement de nom détectable du terminal (voir détails en regard de la figure 2). A la suite de la tâche 100, la tâche 200 concerne la recherche d'autres terminaux susceptibles de communiquer avec le terminal en question, de détection d'autres terminaux, de mise à jour de liste et d'alerte en cas de détection (voir détails en regard de la figure 3). Lorsque la tâche 200 se termine sur une détection de dépassement de durée maximale prédéterminée (en anglais "timeout"), une tâche 300 de balayage de liste des terminaux est lancée (voir détails en regard de la figure 4). Après la fin de la tâche 300, une tâche 400 d'attente de connexion est lancée (voir détails en regard de la figure 5). Lorsque la tâche 400 se termine sur une détection de dépassement de durée maximale prédéterminée (en anglais "timeout"), une tâche 500 de tentative de connexion est lancée (voir détails en regard de la figure 6). Lorsque la tâche 500 se termine sans qu'aucune connexion n'ait été acceptée par un autre terminal, la tâche 200 est relancée.

Lorsque l'une des tâches 200, 400 ou 500 est interrompue par une demande d'arrêt de la part de l'utilisateur, une tâche d'arrêt et de restauration 800 est lancée.

Lorsque l'une des tâches 200, 400 ou 500 est interrompue par une demande d'envoi de message de la part de l'utilisateur, une tâche de reconnaissance de service, de recherche de port disponible et d'envoi de message 600 est lancée (voir détails en regard de la figure 7).

Lorsque la tâche 400 se termine par une connexion reçue et acceptée ou lorsque la tâche 500 se termine par une connexion émise et acceptée, une tâche 700 de vérification d'acceptation de connexion, d'échange de données, de comparaison de données et d'alerte est lancée (voir détails en regard des figures 8 à 12).

La tâche d'arrêt 800 comporte une étape (non représentée) de restauration du nom détectable du terminal, pour en éliminer l'indication que l'application implémentant les différents aspects de la présente invention est active, tout en maintenant l'indication que le terminal est équipé de cette application. Puis on arrête l'application.

Pour faciliter la compréhension des figures 3 et 5, les tâches de détection de dépassement de durée maximale prédéterminée (en anglais "timeout"), qui déterminent si une durée prédéterminée a été atteinte pour la réalisation de la tâche 200 (respectivement 400), n'ont pas été représentées.

Selon une variante, on intervertit les tâches 400 et 500, cette dernière étant alors effectuée avant la tâche 400 lorsque la tâche 200 a atteint sa durée maximale prédéterminée.

Avant de décrire les figures 2 à 13, on observe que la tâche de paramétrage du dispositif et de l'application, tâche indépendante des tâches décrites en figure 1, n'est pas détaillée dans la description. Elle met en oeuvre des interfaces utilisateurs spécifiques, éventuellement contextuelles, en fonction de la tâche et/ou de l'étape en cours de réalisation, selon des techniques connues.

On observe, en figure 2 que la tâche 100 comporte d'abord une étape 105 d'initialisation du terminal. Puis, au cours d'une étape 110, on active les moyens de communication à courte portée, ici selon le standard Bluetooth. Au cours d'une étape optionnelle 115, on reçoit un message de la part d'un autre terminal comportant une offre de parrainage.

Au cours de l'étape 120, on télécharge les fichiers d'installation de l'application (depuis un ordinateur personnel, depuis un autre terminal mobile (parrainage), depuis un site accessible en ligne, depuis une mémoire amovible). On observe que ces fichiers d'installation peuvent aussi être mis en mémoire du terminal mobile avant la mise à disposition de ce terminal auprès d'un utilisateur. Puis, on installe l'application, on copie les fichiers d'installation pour permettre le parrainage d'un autre utilisateur, c'est à dire la transmission automatique d'une invitation à un autre terminal qui ne met pas encore en oeuvre l'application, à télécharger le programme d'installation de cette application (voir étape 115 pour cet autre terminal). Au cours de l'étape 120, on copie les fichiers d'installation pour pouvoir les transmettre à un autre terminal (parrainage) et on initialise une base de données conservée par le terminal mobile.

Puis, au cours d'une étape 125, on lance l'application, on détecte la marque et le modèle du terminal mobile, l'adresse de ce terminal sur le support de communication à courte portée, par exemple l'adresse Bluetooth, et la langue utilisée par ce terminal mobile et on installe des libellés correspondant à cette langue dans la base de données et on mémorise lamarque, le modèle et l'adresse du terminal ainsi que la date d'installation de l'application.

Puis, et à chaque nouveau lancement de l'application, au cours d'une étape 130, on met à jour le nom détectable du terminal local pour ses communications selon le standard de communication (nom appelé nom "Bluetooth" lorsque ce standard est mis en oeuvre) pour qu'il comporte un signe de reconnaissance de l'application implémentant la présente invention et de son état actif ou inactif.

Grâce à cette caractéristique, dès la détection d'un autre terminal ("terminal distant"), le terminal local peut déterminer si son application implémentant la présente invention pourra communiquer avec une application homologue fonctionnant sur ce terminal distant ou, dans le cas où le terminal distant ne dispose pas de cette application, si une offre de parrainage peut être mise en oeuvre.

Préférentiellement, le signe de reconnaissance est un caractère muet, c'est-à-dire qui ne se prononce pas, par exemple r ) },I ]", C ,,, (j H Ç "2', Hu E,,, Préférentiellement, le signe de reconnaissance est le deuxième signe d'un couple de signes qui s'utilisent traditionnellement par paire ordonnée, par exemple ")", "}" ou "]", le premier étant préféré, lorsque le terminal distant possède l'application et qu'elle est active car il suggère aussi une onde radio. Le signe de reconnaissance "}" peut, en complément, être utilisé dans le cas où le terminal distant possède l'application mais qu'elle est inactive.

En variante, au cours de l'étape de modification du nom détectable du terminal local, on y incorpore plusieurs informations organisées selon un format prédéterminé. Préférentiellement, dans cette variante, les informations incorporées dans le nom détectable comportent: - une identification de leur format et - des informations organisées selon ledit format.

Par exemple, selon un premier format, destiné à être sélectionné par l'utilisateur lors de ses périodes d'activité ou de rencontres professionnelles, l'information incorporée dans le nom détectable est organisée et compressée pour représenter successivement le nom, le prénom, l'entreprise et le secteur d'activité de l'utilisateur et, dans un deuxième format, destiné à être sélectionné par l'utilisateur lors de ses périodes d'inactivité professionnelles, l'information incorporée dans le nom détectable est organisée et compressée pour représenter le pseudonyme, l'âge, le sexe et des sujets d'intérêt de l'utilisateur. Selon un troisième format, l'information incorporée dans le nom détectable est organisée et compressée pour décrire une recherche (offre, demande ou identité, comme expliquer plus loin).

De plus, au cours de l'étape 130 on lance un chronomètre de la durée d'activité de l'application destiné à fournir des éléments statistiques.

Au cours d'une étape 135, l'utilisateur personnalise l'application et saisit un profil personnel qui peut comporter une identité en vue de reconnaissance d'autres utilisateurs de terminaux qui possèdent la même identité (par exemple l'établissement où on travaille, le club de sport dont on est supporter, les établissement où on a fait ses études, ...), une ou plusieurs offres définies par leurs attributs et une ou plusieurs demandes définies par des critères et les fichiers que l'on souhaite partager avec d'autres utilisateurs de l'application.

Les rubriques avec lesquelles l'utilisateur définit ses recherches sont choisies dans une hiérarchie ou arborescence prédéfinie, chaque choix que l'utilisateur peut faire en un noeud de l'arborescence étant mémorisé en plusieurs langues dans la base de données de son terminal. Par exemple, le premier niveau de l'arborescence peut comporter les rubriques "rencontres", "emploi", immobilier", "auto/moto", "achat/vente", "services", "informations" et "autre". En fin d'arborescence, les feuilles correspondent à des codes qui sont libres, l'utilisateur, ou un groupe d'utilisateur pouvant ainsi se choisir un code commun pour définir une recherche.

Les offres (recherche d'un type particulier) sont définies par des attributs et des valeurs d'attributs prédéfinies (par exemple voiture berline - trois portes - années > 2002). Les demandes (recherche d'un autre type particulier) sont définies par des critères qui sont des attributs, des opérateurs agissant entre les valeurs de ces attributs (par exemple ET et OU) et des valeurs de ces attributs prédéfinies (par exemple moto - 750 cm3 - année > 2001 ET année < 2003 ET kilométrage < 40.000). Les demandes peuvent aussi être définies par mots clés (par exemple "décapotable").

Puis, on mémorise la date de dernière modification des données à échanger.

Au cours d'une étape 145, l'utilisateur choisit, pour chaque ensemble de données (identité, profil, recherches, par exemple), le mode de communication à d'autres terminaux: - visible par tous (sauf liste noire), - "filtré" ou visible que par ses "amis" (liste blanche) ou -invisible par tous.

Ces données sont mises en mémoire dans la base de données.

On observe que les étapes 135 et 145 peuvent être répétées à tout moment par l'utilisateur.

La tâche 100 est alors terminée et on lance la tâche 200 (figure 3) .

On observe, en figure 3, que la tâche 200 comporte d'abord une étape 205 de détection d'autres terminaux.

Pour certains terminaux téléphoniques qui ne peuvent accepter une demande de détection lorsqu'ils sont eux-mêmes en détection, on inhibe la réponse aux demandes de détection au début de la tâche 200 et on la désinhibe à la fin de cette tâche.

Tant qu'aucun autre terminal n'a été détecté et qu'aucune interruption de tâche n'a lieu (par détection de dépassement de durée maximale prédéterminée, demande d'arrêt de la part de l'utilisateur ou demande d'envoi de la part de l'utilisateur), l'étape 205 se poursuit.

On observe que le terminal local est détectable tant qu'il n'utilise pas ses fonctions de communication.

On observe aussi que la récupération du nom est coûteuse en temps. Pour limiter ce coût, on met en oeuvre une mémoire cache interne des terminaux détectés récemment. Cependant, afin de vérifier périodiquement que le nom détectable d'un terminal n'a pas changé, au cours d'une étape de détection sur dix, on récupère le nom de chaque terminal détecté ou re- détecté au cours de cette étape, et on rafraîchit ainsi le contenu de la mémoire cache et la base de données.

Dès qu'un nouveau terminal a été détecté, on reçoit de lui: - un nom dit "définitif', ou adresse sur le support de communication à courte portée, par exemple Bluetooth, non qui est unique, c'est-à-dire qu'aucun autre terminal ne peut posséder le même nom définitif et - un nom détectable (nom "Bluetooth" lorsque ce standard est utilisé) choisi par son utilisateur et modifié par la tâche 100 de l'application implémentant le procédé objet de la présente invention comme expliqué en regard de la figure 2. Les données extraites du nom détectables sont mises en mémoire dans un profil du terminal distant détecté.

Au cours d'une étape 210, on recherche la liste des terminaux déjà récemment détectés et, au cours d'une étape 215, on détermine si le nom définitif de l'autre terminal, qui vient d'être détecté, est présent dans cette liste.

Si le résultat de l'étape 215 est négatif, au cours d'une étape 220, on ajoute, dans la liste des terminaux récemment détectés, au moins les informations suivantes concernant le nouveau terminal détecté : - la date de la détection, en tant que date de dernière détection, - la probabilité de présence la plus élevée, en tant que probabilité de présence du terminal détecté, - l'adresse et le nom détectable du terminal détecté ; le statut de l'application implémentant le procédé objet de la présente invention dans le terminal qui vient d'être détecté, statut qui peut prendre deux valeurs "actif' ou "passif" représentative de l'activité de l'application implémentant la présente invention, - le nombre de tentatives de connexion à effectuer est initialisé à 6 si le statut de l'application est actif et - les informations extraites du nom détectable du terminal distant.

Si le résultat de l'étape 215 est positif, au cours d'une étape 225, on met à jour, dans la liste des terminaux récemment détectés, au moins les informations suivantes concernant le terminal qui vient d'être, de nouveau, détecté : - la nouvelle date de la détection, en tant que date de dernière détection, tout en conservant l'ancienne date de dernière détection, - la probabilité de présence la plus élevée, en tant que probabilité de présence du terminal détecté, - l'adresse et le nom détectable du terminal détecté et - le statut de l'application implémentant le procédé objet de la présente invention pour le terminal détecté, statut qui peut prendre deux valeurs "actif" ou "passif', selon que le nom détectable comporte, ou non, le signe de reconnaissance ")" qui indique que ce terminal est susceptible d'échanger des données.

A la suite de l'une ou l'autre des étapes 220 et 225, au cours d'une étape 230, on déclenche une alerte (par exemple une sonnerie ou une vibration du terminal mobile constituant le dispositif objet de la présente invention) si, à la fois: - le terminal qui vient d'être détecté n'est pas filtré (sont filtrés, par exemple, les terminaux dont le statut est "passif", les terminaux qui ne sont pas destinés à transmettre des messages de la part de leur utilisateur, par exemple les imprimantes et les terminaux en liste noire) et - la différence entre la dernière date de détection et l'ancienne dernière date de détection est supérieure à une durée prédéterminée, par exemple une heure.

Cette alerte comporte l'affichage, sur l'écran du terminal local, des données extraites du nom détectable du terminal qui a été détecté et d'autres données mémorisées concernant ce terminal distant.

Après l'étape 230, l'étape 205 est réitérée, sans réinitialisation de la durée maximale prédéterminée (en anglais "timeout").

On observe, en figure 4, que la tâche 300 comporte d'abord une étape 305 de détermination s'il n'y a plus, dans la liste des terminaux récemment détectés, de terminaux possédant une probabilité de présence supérieure à 0. Si le résultat de l'étape 305 est positif, la tâche 300 est achevée et on lance la tâche 400.

Sinon, on effectue une étape 310 de positionnement sur le premier terminal de la liste des terminaux récemment détectés qui possède une probabilité de présence supérieure à la plus faible probabilité de présence possible.

Puis, au cours d'une étape 315, on décrémente la probabilité de présence du terminal considéré, d'une valeur qui dépend du statut du terminal, "actif' ou "passif". Par exemple, lorsque le terminal distant est passif, la probabilité la plus élevée est de "3" et est décrémentée de "1" à chaque cycle sans nouvelle détection de ce terminal distant alors que si le terminal distant est actif, la probabilité la plus élevée est de "6". Enfin, pour certains modèles difficilement détectables, la probabilité maximale est de "7" ou "8". Au cours de l'étape 315, on rafraîchit l'écran du terminal qui implémente le procédé objet de la présente invention pour représenter, sur cet écran, le niveau de probabilité de chaque terminal de la liste des terminaux récemment détectés.

Au cours de cette étape d'estimation ou de détermination de probabilité de présence, on peut calculer la probabilité de présence d'un terminal en fonction - du nombre d'étapes de détection successives pour lesquelles ledit terminal n'a pas été détecté depuis sa dernière détection, comme indiqué ci-dessus; - du fonctionnement d'une application sur ledit terminal et rendant ledit terminal plus difficile à détecter, auquel cas la probabilité de présence décroît plus lentement (en particulier l'application implémentant la présente invention dont le fonctionnement est signalé dans le nom détectable du terminal distant) ; -du type dudit autre terminal (plus le terminal distant a une détectabilité faible, moins vite sa probabilité de présence décroît) et/ou - de l'historique des détections dudit terminal (par exemple si un terminal distant a été détecté, en moyenne, trois fois pour quatre phases de détection et qu'il n'est plus détecté trois fois de suite, sa probabilité de présence est plus rapidement réduite que s'il a été détecté, en moyenne fois pour deux phases de détection).

Au cours d'une étape 320, on détermine si le terminal considéré remplit simultanément les conditions suivantes: - le statut d'application de ce terminal est "actif' ; - le terminal présente une probabilité de présence supérieure à la probabilité de présence la plus faible, ici "0", - les données auquel le terminal à droit (voir modes de communication visible, filtré ou invisible) qui ont été transmises à ce terminal ne sont pas à jour, c'est-à-dire que la date du dernière échange de données est plus ancienne que la date de dernière mise à jour des données à échanger et la durée depuis la date de la dernière tentative de connexion (voir tâche 500) avec le terminal considéré est supérieure à une durée prédéterminée, par exemple cinq minutes.

Si oui, on initialise à une valeur prédéterminée (par exemple 6), le nombre de tentatives de connexion à effectuer pour le terminal considéré. Puis on réitère l'étape 305.

Pour éliminer un terminal distant de la liste des terminaux détectés, on prévoit un filtre paramétrable: on exclut des terminaux en fonction de critères (exclure les présents, partis, ignorés liste noire, amis, téléphones, PDA, PC, imprimantes, les passifs, les sans-profils, les avec profils...). Mais on les garde dans le cache un certain temps. Une fonction "autodelete" activable supprime les terminaux exclus ou "masqués" qui ne sont pas détectés pendant une durée prédéterminée.

On observe, en figure 5, que la tâche 400 comporte d'abord une étape 405 de lecture, en mémoire de la durée "D" de détection choisie (par paramétrage par défaut), par exemple de quatre secondes. Puis, au cours d'une étape 410, on détermine s'il existe encore des terminaux à traiter, c'est-à-dire des terminaux dont la nombre de tentatives de connexion à effectuer est strictement supérieur à "0". Si oui, on affecte la valeur "0" à la variable "T" au cours d'une étape 415. Sinon, au cours d'une étape 420, on effectue un tirage aléatoire équiprobable entre trois valeurs: 2, 3 ou 4, le résultat du tirage étant affecté à la variable "T".

Puis, au cours d'une étape 425, on calcule la durée d'attente à observer comme étant égale au produit de la durée de détection choisie "D" par la variable "T", produit auquel on ajoute une durée prédéterminée, par exemple deux secondes. Ainsi, la durée d'attente peut prendre, de manière équiprobable, l'une des valeurs 10, 14 ou 18 secondes lorsque "D" vaut quatre secondes et que la durée prédéterminée ajoutée vaut deux secondes.

Puis, au cours d'une étape 430, on attend de recevoir une connexion pendant la durée d'attente calculée. La tâche 400 est alors achevée et on lance la tâche 500.

Ce tirage aléatoire permet de désynchroniser deux terminaux qui ne pourraient se détecter parce qu'ils sont synchronisés, c'est-à-dire détectable au même moment et en recherche de détection au même moment. Le tirage à trois valeurs permet d'obtenir deux chances sur trois que deux terminaux synchronisés au cours d'un cycle soient suffisamment désynchronisés au cycle suivant pour que l'un d'entre eux détecte l'autre.

On observe, en figure 6, que la tâche 500 comporte d'abord une étape 505 de sélection du terminal de la liste des terminaux récemment détectés pour lequel la durée passées depuis la date de la dernière tentative de connexion est la plus élevée, en éliminant les terminaux dont le nombre de tentatives de connexion à effectuer est nul. Puis, au cours d'une étape 510, on effectue une étape de tentative de connexion avec le terminal considéré, selon des techniques connues, notamment conformément au standard Bluetooth.

Si le résultat de la tentative de connexion de l'étape 510 est un succès, la connexion étant acceptée par le terminal cible, on lance la tâche 700 (voir figures 8 à 12), étape 515.

Si le résultat de la tentative de connexion de l'étape 510 est un échec, c'est-à-dire qu'une durée prédéterminée maximale est dépassée pour l'étape 510 (en anglais "timeout"), au cours d'une étape 520, on décrémente le nombre de tentatives de connexion à effectuer pour le terminal considéré et on met à jour la date de la dernière tentative de connexion du terminal considéré.

Puis, au cours d'une étape 525, on détermine si on a effectué, depuis le dernier lancement de la tâche 500, trois tentatives de connexion ou si une durée prédéterminée pour le déroulement de l'étape 500 est dépassé. Si oui, la tâche 500 est achevée et on lance la tâche 200 (voir figure 3). Sinon, on réitère l'étape 505. Bien entendu, la durée prédéterminée mise en oeuvre au cours de l'étape 525 est supérieure à la durée prédéterminée mise en oeuvre au cours des étapes 510 et 515.

On observe, en figure 7, que la tâche d'envoi 600 comporte d'abord une étape 605 d'initialisation d'un compteur de tentatives de connexion.

Puis, au cours d'une étape 610, on détermine si la valeur du compteur de tentatives est égal à un nombre prédéterminé, par exemple trois. Si oui, la tâche 600 est terminée et on lance la tâche 200. Sinon, au cours d'une étape 615, une effectue une tentative de connexion qui met en oeuvre un protocole de découverte de service, connu sous le nom anglais de SDP pour "service discovery protocol", et on initialise un chronomètre (en anglais "timer") et on lance une détection de dépassement de durée maximale prédéterminée (en anglais "timeout").

Si, au moment de cette détection de dépassement de durée, la connexion n'a pas été 5 acceptée, ce qui est déterminé au cours d'une étape 620, au cours d'une étape 625, on incrémente le compteur de tentative de connexion et on retourne à l'étape 610.

Sinon, c'est-à-dire si la connexion est acceptée avant la fin de la durée prédéterminée, au cours d'une étape 630, on récupère le port OBEX disponible, c'est-à-dire disponible pour une connexion conformément au standard Bluetooth. Puis, au cours d'une étape 635, on effectue une tentative de connexion OBEX et, dès que la connexion est acceptée, au cours d'une étape 640, on envoie le message à transmettre (message, carte de visite ou fichier, par exemple).

Puis, au cours d'une étape 645, on met fin à la connexion et la tâche 600 étant achevée, on lance la tâche 200.

Par exemple, l'offre de parrainage d'un autre utilisateur de terminal mobile est une demande d'envoi manuelle.

On observe, en figure 8, que l'entrée de la tâche 700, lorsqu'elle est lancée par la tâche 400, c'est-à-dire qu'une connexion reçue de la part d'un autre terminal a été acceptée, commence par une étape 705 de première réception (réception d'un envoi référencé "1" dans la suite de la description et détaillée en figure 11) et d'enregistrement de premières données. Puis, au cours d'une étape 710, on détermine si le terminal avec lequel la connexion a été établie est déjà référencé dans la base de données, en y cherchant son adresse définitive. Si le terminal est déjà référencé, au cours d'une étape 715, on effectue une mise à jour des données concernant ce terminal, dans la base de données. Si le terminal n'est pas déjà référencé, au cours d'une étape 720, on ajoute le terminal et les données reçues dans la base de données.

A la suite de l'une ou l'autre des étapes 715 ou 720, au cours d'une étape 725, on effectue une comparaison des recherches reçues de la part de l'autre terminal et des recherches conservées dans la base de données locale. Cette comparaison est détaillée en figure 10. Au cas où la comparaison montre une correspondance d'au moins une recherche par terminal, on mémorise le numéro de l'offre et le numéro de la demande, dans une mémoire de correspondances et on émet une alerte à l'utilisateur du terminal, sous forme sonore, visuelle ou par déclenchement de vibreur, par exemple. Cette alerte n'est effectuée que si la correspondance n'a pas déjà été signalée, ce qui peut être déterminé en recherchant le couple numéro d'offre et numéro de demande dans la mémoire de correspondances.

Puis, au cours d'une étape 730, on effectue un premier envoi de données au terminal avec lequel la connexion est établie. Ce premier envoi est détaillé en figure 11. Puis, au cours d'une étape 735, on effectue une deuxième réception (réception d'un envoi référencé "2" dans la suite de la description et détaillé en figure 12) et enregistrement de deuxièmes données. Puis, au cours d'une étape 740, on détermine si au moins un filtre a montré une correspondance avec une recherche filtrée transmise dans les deuxièmes données par l'autre terminal (voir détail en figure 10) .

Si oui, on mémorise le numéro de l'offre et le numéro de la demande dans la mémoire de correspondances et on émet une alerte à l'utilisateur du terminal, sous forme sonore, visuelle ou par déclenchement de vibreur, par exemple, si la correspondance n'a pas déjà été signalée. Sinon, ou après le déclenchement de l'alerte, la tâche 700 est achevée et on relance la tâche 200.

On observe en figure 9, que l'entrée dans la tâche 700, lorsqu'elle est lancée par la tâche 500, c'est-à-dire qu'une connexion a été émise à destination d'un autre terminal et acceptée par lui, comporte d'abord une étape 745 de premier envoi de premières données (voir détail de l'envoi "1" en figure 11). A la suite de ce premier envoi, on met à jour la base de données locale en ce qui concerne l'autre terminal. Puis, au cours d'une étape 750, on effectue une étape de réception de premières données (réception d'envoi "1" de l'autre terminal), on enregistre ces premières données en provenance de l'autre terminal et on met à jour les données concernant l'autre terminal dans la base de données locale.

Au cours d'une étape 755, on effectue une étape de comparaison des recherches reçues et des recherches conservées en base de données (voir détail en figure 10). Au cas où la comparaison montre une correspondance d'au moins une recherche par terminal, on mémorise le numéro de l'offre et le numéro de la demande, dans la mémoire de correspondance et on émet une alerte à l'utilisateur du terminal, sous forme sonore, visuelle ou par déclenchement de vibreur, par exemple, si la correspondance n'a pas déjà été signalée.

Puis, au cours d'une étape 760, on effectue une deuxième étape d'envoi de deuxièmes données (envoi "2", voir détail en figure 12) qui concernent les recherches filtrées pour lesquelles une correspondance a été détectée au cours de l'étape 755 (voir figure 10).

Les recherches filtrées sont les recherches pour lesquelles le mode de communication est "filtré", c'est-à-dire que ces recherches sont réservées aux amis, et que l'autre terminal est identifié comme ami.

On observe, en figure 10, que la comparaison de recherches comporte d'abord une étape 905 de mise en correspondance de recherches reçues et de recherches stockées en base de données, selon leur type. Ainsi, les recherches liées à l'identité ne sont mises en correspondance qu'entre elles. Les demandes ne sont mises en correspondance qu'avec des offres et les échanges ne sont mis en correspondance qu'entre eux.

S'il n'y a aucune telle correspondance entre les recherches reçues et les recherches conservées dans la base de données locale, la comparaison est terminée.

Sinon, au cours d'une étape 910, on effectue une comparaison par rubrique. Dans le cas des recherches de correspondance d'identités, celles-ci ne correspondent que si leurs rubriques sont exactement identiques. On rappelle que le terme de rubrique couvre ici l'ensemble des noeuds et feuilles d'une arborescence de choix. Par exemple une rubrique d'identité peut signifier les deux sélections suivantes prédéterminées "communauté / Ecole" pour indiquer que l'identité est celle d'une communauté constitué des élèves sortis d'une même école.

Pour qu'une offre corresponde à une demande, au cours de l'étape 910, il faut que tous les attributs de l'offre soient inclus dans tous les critères de la demande.

S'il n'y a aucune telle correspondance entre les recherches reçues et les recherches conservées dans la base de données locale, la comparaison est terminée.

Sinon, au cours d'une étape 915, pour les recherches identitaires, on met en correspondance les codes. Par exemple un code HEC86 représente les anciens élèves de la promotion 1986 de l'école HEC.

S'il ne reste aucune correspondance à traiter après l'étape 915, la comparaison est terminée.

Sinon, au cours d'une étape 920, pour les offres et demandes à mettre en correspondance, on considère comme en correspondance les offres dont tous les attributs répondent à tous les critères de la demande.

Au cours d'une étape 925, dans le cas des échanges, qui sont la combinaison d'au moins une offre et d'au moins une demande, si au moins une correspondance offre reçue/demande stockée a été établie au cours de l'étape 920, et que l'offre fait partie d'une recherche d'échange, on recherche si au moins une correspondance peut être établie entre une offre stockée en base de données locale et une demande reçue faisant partie de la même recherche d'échange. Si oui, il y a correspondance de recherche d'échange.

Dans tous les cas où une correspondance entre une recherche reçue et une recherche stockée a été établie, au cours d'une étape 930, on émet une alerte à destination de l'utilisateur du terminal et la comparaison est achevée et on poursuit le déroulement de la tâche 700.

On observe, en figure 11, que l'envoi "1" comporte d'abord une étape 1005 de recherche si, avec le terminal avec lequel une connexion est acceptée, la base de données locale conserve une indication relation "ami", "neutre" ou "ignoré", ce dernier cas correspondant à la liste "noire" des terminaux avec lequel on refuse de communiquer.

Puis, au cours d'une étape 1010, on recherche les données visibles par le terminal avec lequel la connexion est acceptée, en fonction de l'indication de relation retrouvée en base de données locale. Ces données (informations du profil et recherches) sont les données visibles par tous, sauf si cette relation est "ignoré", les informations du profil filtrées si l'indication de relation est "ami" et les recherches visibles par tous, sauf si cette relation est "ignoré". Ainsi, si la relation est "ignorée", on n'envoie aucune donnée, si la relation est "neutre", on envoie uniquement les données visibles par tous, si la relation est "ami", on envoie les données visibles par tous et les informations de profil visibles par les amis.

Puis, au cours d'une étape 1015, on recherche les informations techniques à transmettre, en particulier, le nom détectable sur le support de communication à courte portée, par exemple Bluetooth, la classe de dispositif (en anglais "class of device").

Au cours d'une étape 1020, on recherche, parmi les données transmissibles, celles qui ont été modifiées depuis le dernier envoi fait au terminal avec lequel la connexion a été acceptée.

Au cours d'une étape 1025, on formate les informations à transmettre, mêmes'il n'y a aucune information modifiée, auquel cas le formatage concerne une trame d'information vide. Au cours d'une étape 1030, on effectue la transmission de l'information à transmettre formatée. Puis, au cours d'une étape 1035, on met à jour la date des données envoyées au terminal avec lequel la connexion est acceptée.

On observe, en figure 12, que l'envoi "2" comporte d'abord une étape 1105 de recherche des données filtrées en correspondance avec des recherches reçues de la part de 20 l'autre terminal (voir détail en figure 10).

Au cours d'une étape 1110, on formate les informations à transmettre, même s'il n'y a aucune information modifiée, auquel cas le formatage concerne une trame d'information vide. Au cours d'une étape 1115, on effectue la transmission de l'information à transmettre formatée. Puis, au cours d'une étape 1120, on met à jour la date des données envoyées à l'autre terminal.

La figure 13 récapitule les échanges effectués entre deux terminaux, "A" et "B", "A" étant le terminal qui détecte l'autre terminal, ici "B", communication 1205. Puis, le terminal "A" tente de se connecter au terminal "B", communication 1210. Si la tentative de connexion est un succès, le terminal "B" ouvre la connexion, communication 1215. Puis, le terminal "A" envoie les informations visibles par tous, les informations filtrées si le terminal "B" est référencé comme "amis" dans la base de données du terminal "A" et les recherches visibles par tous, communication 1220.

En réponse, le terminal "B" envoie au terminal "A" les informations visibles par tous, les informations filtrées si le terminal "A" est référencé comme "ami" dans la base de données du terminal "B", ses recherches visibles par tous et les recherches filtrées si des correspondances ont été détectées entre les recherches transmises par le terminal "A" et les recherches conservées dans la base de données du terminal "B", communication 1225.

Enfin, le terminal "A" envoie au terminal "B" les recherches filtrées dont la correspondance a été détectée par le terminal "A", communication 1230.

On observe que les recherches sont transmises par description de branches d'arborescence et de la partie libre. Ceci permet une communication multilingue car affiché la description de branches d'arborescence peut ensuite être affichée dans la langue du terminal choisie par son utilisateur. Ainsi, sont multilingues, l'interface utilisateur et les libellés des rubriques, des champs et des valeurs.

Dans le cas des recherches "invisibles", s'il y a correspondance avec une recherche reçue, on alerte l'utilisateur et on lui affiche le profil de l'utilisateur distant. L'utilisateur décide ensuite de répondre, ce qui rend la recherche visible pour l'autre terminal, ou non.

On observe que, pour le passage d'un terminal distant en liste noire, après connexion à ce terminal distant et envoi de profil, si l'utilisateur du terminal local prend la décision de passer le terminal distant en liste noire, le terminal local effectue une nouvelle connexion avec le terminal distant et lui envoie un profil vide, ce qui provoque l'écrasement du premier profil en mémoire de l'autre terminal, comme toute mise à jour de profil.

On observe que la détection mutuelle des terminaux s'effectue en tâche de fond. Plusieurs applications utilisant l'application de communication implémentant la présente invention peuvent fonctionner simultanément en partageant le canal de communication à courte portée. Dans ce cas, dans l'étape de recherche de données à échanger, on recherche les données de plusieurs applications. L'application implémentant la présente invention transmet toutes ces données ensembles, elles sont multiplexées comme si plusieurs canaux de communication étaient simultanément utilisés, et démultiplexées par l'application mettant en oeuvre la présente invention, sur le terminal distant, qui comporte un filtre multiapplications à cet effet.

En variante, au cours de l'exécution de la tâche 200, on insert le numéro de téléphone dans le nom détectable Bluetooth, ce numéro de téléphone est automatiquement récupérée par l'application mettant en oeuvre la présente invention et elle fait une proposition d'appel immédiat ou d'envoi de minimessage immédiat et, éventuellement effectue la mémorisation du numéro de téléphone dans le répertoire du terminal et dans le profil associé au terminal distant.

En variante, si un terminal distant est en liste noire, on le lui indique.

Concernant l'offre de parrainage, dans la version Symbian (marque déposée) , le logiciel est envoyé par Bluetooth alors que dans la version Java (marque déposée) ou windows mobile (marque déposée), on envoie une carte de visite au format "V-card" avec, dans le nom, un message de ce qu'il faut faire pour installer l'application implémentant la présente invention et un lien sur un site WAP où on peut trouver l'application (ouverture de navigateur web automatique par sélection du lien).

Dans la suite de la description, on décrit, pour un mode de réalisation particulier de la présente invention, des concepts, des interfaces utilisateur, des traitements effectués et des données gérées dans un mode de réalisation particulier de la présente invention. On ne décrit ici que les caractéristiques communes à toutes les versions de ce mode de réalisation, indépendamment du système d'exploitation mis en oeuvre (par exemple des marques déposées Symbian, UIQ, Pocket PC, etc...).

Le logiciel implémentant la présente invention, dans ce mode de réalisation, est un logiciel de communication entre terminaux Bluetooth. La mise en oeuvre de la présente invention apporte sur un téléphone mobile ou un assistant personnel ("PDA") des fonctionnalités de communication similaires à des pages personnelles, une messagerie, des communautés, des petites annonces, de la publicité, des communications et transferts entre pairs ("peer to peer"), etc...

Le logiciel est composé de 3 modules fonctionnels: - un module interface utilisateur, - un module de communication et - un module de gestion de données.

Le module interface utilisateur regroupe et gère tous les écrans du logiciel: écrans de paramétrage et écrans d'information.

Le module de communication gère la détection des terminaux, les échanges d'informations et de recherches entre les terminaux et la comparaison des recherches reçues avec les recherches locales.

Le module de gestion de données prend en charge la lecture et l'écriture, dans la mémoire du terminal, des données qui doivent être conservées lorsque le logiciel est arrêté : recherches, réponses, paramètres, statistiques, ...

Les deux premiers modules font appel au module de gestion des données de façon ponctuelle pour utiliser ses fonctionnalités de lecture et de sauvegarde des données.

Le terminal (en anglais "device") est l'appareil supportant le standard Bluetooth sur lequel est exécutée l'application implémentant la présente invention (dans la suite "l'application").

On rappelle que "Bluetooth" distingue plusieurs classes de terminal (en anglais "class of device" dont l'acronyme est "COD"), par exemple: - les téléphones, - les assistants personnels ("PDA"), - les ordinateurs.

Chaque terminal est identifiable par son adresse Bluetooth (en anglais "Bluetooth address") unique. Il a aussi un nom Bluetooth (en anglais "Bluetooth name") qui est en général modifiable.

On appelle terminal local (en anglais "local device"), le terminal du point de vue duquel on se place, et terminal distant (en anglais "remote device") chaque terminal avec lequel le terminal local interagit.

Chaque terminal possède un statut pour l'application implémentant la présente invention (en anglais "status") : "visible" : le terminal a l'application installée et lancée en mode visible.

- "arrêté" : le terminal a l'application installée et lancée dans un autre mode.

"parrainable" : le terminal n'a pas l'application installée mais semble compatible (on peut le parrainer, c'est-à-dire lui envoyer l'application pour qu'elle l'installe).

- "passif" : le terminal ne peut pas faire tourner l'application mais son nom Bluetooth contient un message de l'application implémentant la présente invention.

"Bluetooth" : le terminal est un terminal Bluetooth qui n'est pas compatible avec l'application.

L'utilisateur peut définir sa relation (en anglais "relationship") avec chacun des autres terminaux, parmi les relations suivantes: "neutre", "ami" ou "indésirable".

Ces relations permettent de créer deux listes: - la liste des "amis" (en anglais "friend list"), liste contenant tous les terminaux amis et la liste noire (en anglais "black list"), liste contenant tous les terminaux indésirables. Il existe une troisième liste appelée liste des terminaux (en anglais "device list") qui contient tous les terminaux Bluetooth présents sur le moment autour du terminal local. L'utilisateur possède un profil (en anglais "profile") qui contient des informations regroupées en blocs d'information.

L'utilisateur peut définir une visibilité élémentaire (en anglais "item visibility") pour chaque bloc, qui définit quels terminaux distants pourront lire les informations contenues dans ce bloc. Il existe 3 niveaux de visibilité : "visible" : les informations contenues dans le bloc seront visibles par tous les terminaux sauf les terminaux indésirables.

- "filtre" : les informations contenues dans le bloc ne seront visibles que par les terminaux amis.

- "invisible" : les informations contenues dans le bloc ne seront visibles par personne.

L'application possède également une visibilité générale (en anglais "global visibility") qui 35 permet de définir d'un coup la visibilité maximale des informations. La visibilité appliquée est la plus restrictive, entre la visibilité élémentaire et la visibilité globale.

Il y a quatre niveaux de visibilités générale: "visible", "filtre", "invisible" et "arrêté".

Lorsqu'elle est "arrêtée", l'application n'envoie aucune information aux autres terminaux et ne répond pas aux demandes. Toutes les communications sont désactivées, mais l'utilisateur a accès aux écrans.

Si nécessaire, les paramètres Bluetooth du terminal sont mis à jour automatiquement en fonction du mode sélectionné : si Bluetooth était désactivé et que l'application passe à un mode autre que "inactif", alors Bluetooth est activé. Bluetooth est toujours remis dans l'état où il se trouvait avant de démarrer l'application, lorsque l'on repasse au mode "inactif".

Dès que l'on passe au mode "inactif", l'application arrête le module de communication et dès que l'on passe à un autre mode elle relance ce module.

Grâce à l'application, l'utilisateur peut créer des recherches (en anglais "searches") qui lui permettent de trouver des informations, des produits, des personnes ou des services situés à proximité (portée Bluetooth).

Une recherche peut être: - permanente: elle est stockée dans le terminal, et prévient l'utilisateur dès qu'il est à proximité de ce qu'il recherche. Elle possède un nom.

immédiate: elle est exécutée immédiatement pendant un court laps de temps, et n'est pas conservée dans le terminal, donc elle n'est pas nommée. A la fin du laps de temps elle peut être oubliée ou sauvegardée en tant que recherche permanente. II faudra alors la nommer.

Une recherche possède une visibilité élémentaire. Une recherche en visibilité "filtre" n'est visible que par les terminaux sur lesquels une recherche correspondante a été détectée. Chaque terminal publie ses recherches et reçoit les recherches des autres terminaux, en fonction des visibilités choisies. Le logiciel compare les recherches et détecte les correspondances (en anglais "matchings"). S'il y a correspondance, l'utilisateur est prévenu par une alerte et peut consulter la réponse (en anglais "result") à sa recherche, c'est-à-dire la recherche distante (sur le terminal distant) qui correspond à sa recherche locale (sur le terminal local).

Une recherche est définie tout d'abord par une rubrique (en anglais "class") qui indique l'objet de la recherche au sein d'une classification arborescente. Une rubrique peut contenir des sous-rubriques, qui sont appelées ses rubriques "filles", elle est alors leur rubrique mère.

Par exemple:

véhicule o auto 2882875 25 o moto objet o CD o Meuble communauté o école o association "auto" est une rubrique fille de "véhicule" et "véhicule" est la rubrique mère de "auto".

Pour apporter un degré de précision supplémentaire, l'utilisateur peut définir un code rubrique (en anglais "class code"). Cette information offre souplesse et extensibilité à la classification des rubriques.

Par exemple, pour rechercher les élèves et anciens élèves de l'école "EPITA", on pourra créer une recherche avec la rubrique "école" et le code rubrique "EPITA" (identifiant convenu).

De plus une recherche peut contenir: des mots clés - un texte descriptif II existe 4 types de recherches (en anglais "search type") : "offre" : recherche qui décrit une offre (par exemple dont la signification est "je vends une moto").

- "demande" : recherche qui décrit une demande ("j'achète une moto").

"identité" : recherche qui décrit à la fois une offre et une demande ("je suis passionné de voile et je voudrais rencontrer d'autres passionnés de voile").

"échange" : recherche qui combine une offre et une demande ("je suis un homme et je cherche une femme").

Une recherche, quel que soit son type, contient donc une offre (en anglais "offer") et I ou une demande (en anglais "request").

une offre possède une liste d'informations décrivant ce qu'on propose; une demande possède une liste de critères décrivant ce qu'on recherche.

Chaque recherche est créée grâce à un modèle de recherche (en anglais "search template") qui définit les informations à rentrer pour créer cette recherche. Il peut exister plusieurs recherches différentes basées sur le même modèle de recherche.

Les modèles de recherche sont classés dans les rubriques (en anglais "class") ou les sous-rubriques.

Le chemin dans les rubriques vers le modèle de recherche définit la classification des recherches créées par ce modèle de recherche.

II existe trois modes de correspondance (en anglais "matching mode") : "identité" : une recherche de type "identité" correspond à une recherche de type "identité", "offre/demande" : une "offre" correspond à une "demande", "échange" : l'offre et la demande de la recherche correspondent à la demande et à l'offre, respectivement, d'une recherche d'un terminal distant.

Le mode de correspondance du modèle de recherche définit le type des recherches qui pourront être créées à partir de ce modèle. Ainsi, un modèle de recherche de type "identité" crée des recherches de type "identité", - un modèle de recherche de type "offre/demande" crée des recherches de type "offre" ou "demande" et un modèle de recherche de type "échange" crée des recherches de type "échange".

Un modèle de recherche contient un modèle d'offre et/ou un modèle de demande, selon son mode de correspondance, qui permettent de créer les offres et les demandes des recherches.

- identité : un modèle d'offre offre/demande: un modèle d'offre et un modèle de demande - échange: un modèle d'offre et un modèle de demande.

Un modèle d'offre est une liste de champs disponibles pour définir les informations d'une offre. Un modèle de demande est une liste de définitions de critère disponibles pour définir les critères d'une demande.

Pour pouvoir comparer deux recherches, elles doivent avoir été créées à partir du même modèle de recherche.

Les modèles de recherche sont définis par des "assistants" (en anglais "wizards"). L'utilisateur peut ajouter ou supprimer des assistants dans le logiciel.

Lorsqu'un assistant est installé, il peut ajouter dans le logiciel: de nouvelles rubriques et des modèles de recherche dans celles-ci et de nouvelles informations dans le profil, ajoutées dans des blocs existants ou dans de nouveaux blocs.

L'assistant ne définit pas comment les informations seront affichées: il ne décrit que les modèles de recherche et leur classification (les rubriques).

Chaque assistant possède un identifiant unique (en anglais "id") constitué de trois lettres (majuscules ou minuscules) ou chiffre (autrement dit: [a-zA-ZO-9] [a-zA-ZO-9] [a-zA-ZO-9] ). Ceci offre la possibilité de créer 238328 assistants différents.

Un champ est défini par un label, un ensemble des valeurs possibles, et éventuellement une liste des unités acceptées.

Par exemple:

- "âge", valeur numérique comprise entre 0 et 200, "couleur", à choisir entre { rouge, vert, bleu} et - "taille" en cm (de 0 à 300) ou en inch (de 0 à 120).

Une information est une valeur qui correspond à un champ, en précisant une unité si plusieurs sont possibles.

Par exemple: âge = 10 ans - couleur = bleu prix = 10 euros Un critère est un triplet (champ, opérateur, valeur). Le champ correspond à une valeur dans une offre. La comparaison des deux valeurs grâce à l'opérateur permet de déterminer si le critère est vérifié ou non.

Par exemple: "10" > âge et "texte" contient "Mobiluck".

Un modèle de critère appartient à un modèle de demande. II contient un label, une référence vers un champ du modèle d'offre associé et un opérateur.

Un modèle de critère permet de créer des critères.

Par exemple: age_min, age, < - artiste, artiste, = Une valeur peut se voir associer une unité, lorsqu'elle est de type numérique.

Par exemple: 10 ans

174 euros Un ensemble de valeurs possibles peut préciser des unités possibles.

On décrit ci-après les contraintes et normes d'ergonomie de l'interface utilisateur: L'interface utilisateur de l'application est adaptée à de nombreux systèmes d'exploitation (Symbian Series 60, UIQ, Palm OS, Pocket PC, Windows, WEB, etc, marques déposées...) dont les normes d'ergonomie et les contraintes techniques sont différentes.

L'interface utilisateur est composée d'écrans et de boîtes de dialogue. Les écrans permettent d'afficher simultanément six lignes de texte d'une vingtaine de caractères. Une ligne peut être sélectionnée à l'aide des touches haut et bas. Il est possible d'afficher plus de six lignes dans un écran grâce à un défilement.

On peut aussi utiliser une autre présentation d'écran, elle aussi basé sur six lignes affichées, cependant les lignes sont groupées deux par deux ce qui permet d'associer le descriptif et le contenu d'un champs.

Dans les écrans, les touches dynamiques de gauche et de droite du clavier sont réservées aux fonctions "Options" et "Retour". La fonction "Retour" revient à l'écran affiché précédemment. La fonction "Options" affiche le menu "Options" qui présente les commandes disponibles, déterminées dynamiquement en fonction de la ligne sélectionnée.

Pour certaines options, un sous-menu proposant plusieurs choix est affiché. Le sous- menu est ouvert à l'aide de la flèche vers la droite ou de la touche de sélection du pavé directionnel. Un choix peut être sélectionné à l'aide des touches haut et bas, puis validé avec la touche sélection.

Des touches de raccourci facilitent l'exécution de certaines options. Ces touches sont la flèche vers la gauche (G), la flèche vers la droite (D) et la sélection (S) du pavé directionnel.

De plus, le logiciel utilise la touche "modifier" afin de faire apparaître l'aide correspondante au champs ou à l'écran sélectionné.

Pour la saisie des textes longs (texte des annonces, textes des messages, etc), l'exemple retenu est celui du paramètre "Mon nom Bluetooth".

Le titre de l'écran initial est "MobiLuck" (marque déposée). Il s'agit d'un menu qui propose les actions les plus courantes. Pour les autres versions, l'écran initial pourrait être "Qui est là ?" ou "Mes Recherches".

L'écran "qui est là ?" affiche la liste des terminaux Bluetooth détectés à proximité. Cet écran exploite les informations stockées en mémoire dans la liste des terminaux par le module de communication. II est rafraîchit dynamiquement dès qu'un nouveau terminal est détecté. A l'ouverture de cet écran, le module de communication lance une " inquiry " (s'il est en mode écoute).

Pour les terminaux passifs le nom Bluetooth n'apparaîtra pas en entier, seul le pseudo est affiché dans cet écran.

On remarques que: le statut peut être utilisée comme un critère de filtrage dans l'écran " Qui est là ? " ou pour déclencher des alertes. Chaque statut est représenté par un logo distinctif à rechercher, - la relation peut être utilisée comme un critère de filtrage dans l'écran " Qui est là ? " ou pour déclencher des alertes. Les terminaux en liste noire sont systématiquement ignorés et - dans ce mode de réalisation, le principe de paiement retenu est de faire payer à l'utilisateur une seule unité par contact, c'est-à-dire soit lors de la consultation ou utilisation des informations personnelles, soit lors de l'affichage du détail d'une réponse.

Des actions payantes (actions nécessitant que le terminal ai été payé : ouvrir terminal, ouvrir réponse, envoyer message, téléphoner, ajouter contact, montrer et lancer) peuvent être activées à partir des écrans "qui est là ?", "terminal X", "Mes Réponses" et "Réponse X".

Les écrans "Terminal X" et "Réponses X" ne sont accessibles qu'après paiement d'une unité et peuvent donc proposer toutes ces actions. Par contre, les écrans "Qui est là ?" et "Mes réponses" peuvent contenir des terminaux/réponses payés et d'autres non payés. Trois solutions sont donc possibles: - actions payantes non affichées, - actions payantes affichées uniquement pour les terminaux payés ou affichées mais grisés pour les terminaux non payés.

- actions payantes affichées pour tous les terminaux payés et non-payés avec paiement automatique lors de la première action payante.

L'écran "Terminal X" peut être affiché à partir des écrans suivants: "Qui est là ?" (le titre de cet écran est alors le nom Bluetooth du terminal sélectionné).

- "Réponse X" (Le titre de cet écran est alors le nom Bluetooth du terminal émetteur de la réponse).

Cet écran affiche les blocs d'information visibles du terminal sélectionné ainsi que les blocs d'information avec la visibilité filtre si le terminal local est enregistré dans "Mes amis" du terminal sélectionné. Les informations des blocs d'informations ne possédant qu'un ou deux champs renseignés sont affichées directement. Les noms des blocs d'informations possédant trois champs renseignés ou plus, sont affichés et servent de liens. On note un cas particulier, pour les blocs d'information contenant des listes d'objet (ex: "fichiers partagés"), le nombre d'objets est précisé.

Les actions proposées varient selon le terminal sélectionné. Des conditions spécifiques doivent être réunies pour qu'une action soit proposée.

L'écran "Messages prédéfinis" permet de choisir un message prédéfini à envoyer ou de créer un nouveau message.

L'écran "Message X" permet de modifier un message prédéfini ou de créer un nouveau message. Le titre de cet écran est le nom du message.

Les actions proposées varient selon le terminal sélectionné. Des conditions spécifiques doivent être réunies pour qu'une action soit proposée.

L'écran "Message alerte" affiche un simple message d'alerte (comme pour la notification d'un SMS) à l'utilisateur dès qu'une alerte choisie dans l'option de menu "paramètres/alertes" se produit. Ce message s'affiche même si l'interface utilisateur n'est pas active. S'il s'agit d'une alerte réponse dans ce cas l'écran propose de voir l'écran "Mes Réponses" en affichant que les réponses correspondant à la (aux) recherche(s) concluante(s). Le message s'efface automatiquement au bout d'une durée paramétrable (voir "Réglages").

Exemples de message affichés: - " 1 nouvelle réponse provenant d'une application distante ", - " 1 nouveau terminal parrainable. ", - " 1 nouveau terminal implémentant l'application ", - " 1 nouveau terminal Bluetooth. " ou - " 1 nouveau terminal Ami. " L'écran "Filtrage" permet de filtrer la liste des terminaux affichés par l'écran "Qui est là ?". Il est accessible par le " menu paramètres " (version assistant personnel) soit dans l'écran "Qui est là" (version Symbian).

Plusieurs critères sont proposés pour définir les terminaux à afficher: la classe principale Bluetooth du terminal (Class Of Device) : téléphone, PDA, ordinateur, imprimante, fax, oreillette, autres, - le statut d'application: "Bluetooth", "Parrainable", "Passif", "arrêté", -la relation avec le terminal: "Ami", "Neutre", "Liste noire".

- la présence: "présent", "parti" (s'il a été payé).

Cet écran permet également d'activer/désactiver l'alerte déclenchée lorsqu'un nouveau terminal apparaît dans l'écran "Qui est là ?".

L'écran "Recherche X" a pour titre le nom de la recherche. Il ne permet pas directement de modifier le contenu de la recherche. Cet écran affiche l'ensemble des champs renseignés lors de la définition de la recherche L'écran "Mes réponses" est affiché différemment selon l'interface depuis laquelle il est ouvert. Les réponses non lues figurent en tête de liste et sont triées par date.

Le titre de l'écran "Réponse X" est le nom de la recherche distante. Cet écran est très similaire à l'écran " Recherche x " mais pour une recherche distante, sachant qu'il y a quelques informations supplémentaires à afficher et quelques actions différentes.

L'écran "Mon profil" permet à l'utilisateur de saisir toutes les informations le concernant afin de les publier et/ou de les utiliser comme valeurs par défaut pour la création de recherches.

L'écran "Bloc d'information X" a pour titre le nom du bloc d'information ouvert. Dans cet écran sont affichés toutes les informations du bloc d'information.

Il y a quatre écrans du type "Fichiers partagés" : Photos, Vidéos, Sons et Autres. On remarque que les fichiers de l'application (installation et modules supplémentaires) sont automatiquement mis dans "Autres Fichiers" et n'y apparaissent pas. Dans ces écrans sont affichés les différents fichiers partagés du type correspondant à l'écran.

L'écran "Paramètres" est un menu permettant de consulter et de modifier les divers paramètres du logiciel. Dans cet écran sont affichés les différentes catégories de paramètres: alertes, messages prédéfinis, modules, Mes amis, liste noire, langues, réglages, rechargement et statistiques.

L'écran "Alertes" permet de choisir les événements qui déclenchent l'affichage d'un message d'alerte et de préciser le son utilisé pour signaler chaque évènement. Des cases à cocher sont proposées à l'utilisateur pour faire une sélection parmi les évènements suivants: détection d'un nouveau terminal Bluetooth, - détection d'un nouveau terminal parrainable, - détection d'un nouveau terminal implémentant l'application, - détection d'un nouveau terminal ami, - détection d'une nouvelle correspondance et - réception d'un message d'une application distante.

Des listes déroulantes permettent de choisir les sons correspondants. Le logiciel tient compte du mode de fonctionnement sélectionné avant d'émettre une alerte. Les alertes sonores sont remplacées par une vibration en mode " Invisible ".

L'écran "Modules" sert à gérer les différents modules. Il permet notamment de supprimer des modules et de modifier le classement des modules pour quel'ordre dans l'assistant de définition de recherches corresponde aux préférences de l'utilisateur. Certains modules " masqués " n'apparaissent pas dans cet écran et ne peuvent pas être supprimés. Dans cet écran sont affichés les noms des différents modules visibles installés, classés dans l'ordre des indices de classement.

L'écran "Mes amis" affiche les noms des terminaux inscrits dans la liste des amis de la même manière que l'écran " Qui est là ? ", sans le symbole ami.

L'écran "Liste noire" affiche les noms des terminaux inscrits dans la liste noire de la même manière que l'écran " Qui est là ? " sans le symbole liste noire.

L'écran "Langues" permet à l'utilisateur d'indiquer les langues que le logiciel aura à gérer. On remarque que si, parmi toutes les langues de l'assistant, aucune ne figure dans ces quatre langues alors l'assistant sera affiché dans sa première langue.

L'écran "Réglages" permet de définir des paramètres techniques du logiciel: - durée "Inquiry" (un nombre entier de seconde) qui définit la durée d'une étape de détection, - ratio "Inquiry"l"écoute" (un pourcentage) qui définit le ratio des durées des étapes de détection et de détectabilité, - durée de vie des terminaux de la liste de terminaux "deviceList" (un nombre entier de minutes) qui définit une durée avant de renouveler une alerte après une absence de détection lorsque le terminal est détecté de nouveau, - le nombre de tentatives de connexion.

La stratégie de détection (sous la forme d'une liste) peut être modifiée par l'utilisateur pour modifier ces réglages, sans en connaître le détail, l'utilisateur privilégiant la rapidité de détection des autres terminaux ou du sien et/ou l'autonomie de son terminal.

L'écran "Statistiques" affiche les différentes statistiques relatives à l'utilisation de l'application implémentant la présente invention.

Les principaux besoins de gestion de données sont les suivants: sauvegarder et charger certaines informations dans la mémoire permanente du terminal.

o Mémoriser des informations de types divers (nombres, chaînes de caractères,...) regroupées par blocs d'informations, et gérer la visibilité de chaque bloc.

o Charger des assistants complémentaires pour créer des recherches envoyer certaines informations à d'autres terminaux, et pouvoir en recevoir.

o Gérer une liste de fichiers disponibles pour les autres terminaux, et les envoyer.

o Gérer une liste de terminaux amis et une liste de terminaux indésirables o Gérer les unités (compteur d'unités, décompte, rechargement, ...) manipuler en mémoire des données nécessaires au fonctionnement du logiciel.

Les contraintes techniques qui s'appliquent comportent: le logiciel doit supporter plusieurs langues, la langue utilisée est définie par un paramètre, la plupart des chaînes de caractères affichées sont différentes selon la langue choisie; il faut que toutes les versions du logiciel (symbian, palm, pocket pc, marques déposées) soient compatibles entre elles (puissent communiquer et utiliser les mêmes modules de recherche).

sécurité : o ne pas pouvoir imiter le comportement du logiciel (i. e.: créer un logiciel compatible, capable de communiquer avec l'application implémentant la présente invention) o ne pas pouvoir modifier le compteur d'unités pour s'en rajouter o ne pas pouvoir créer de modules qui mettent à mal le bon fonctionnement de l'application -respect des standards, afin d'obtenir des certifications (par exemple Nokia OK, marque déposée).

Pour la réalisation du prototype, les inventeurs ont effectué les choix techniques suivants: les données sont codées de la manière la plus portable possible. Ainsi on crée des classes "tampon" qui permettent d'abstraire une partie de la plate-forme. Par exemple, les chaînes de caractères ne sont pas gérées de la même façon sous Symbian, Palm OS et Pocket PC (marques déposées). On crée donc une classe chaîne (en anglais "string") qu'on utilisera pour gérer les données, qui présentera la même interface dans toutes les versions, mais qui sera implémentée de manière différente, - le volume de données géré étant faible, on n'utilisera pas de base de données, - le stockage et l'échange des données se fait via des fichiers XML, les fichiers XML sont décrits par des fichiers XML schéma, Les plates-formes visées ne nous permettent pas d'utiliser le format WBXML qui aurait permis d'économiser de la place (aucune librairie n'a été trouvée sous Symbian).

Certaines données sont: sauvegardées sur le terminal local afin de pouvoir les conserver entre deux lancements de l'application et/ou - transférées entre le terminal local et un terminal distant.

Du point de vue du stockage, l'application et les fichiers sont stockés dans un répertoire " mobiluck " organisé de la façon suivante. Le répertoire " assist " contient toutes les définitions d'assistants. Le répertoire " Profiles " contient un répertoire par profil, le nom de chaque répertoire étant le pseudo choisi pour ce profil. Chacun de ces répertoires contient toutes les informations concernant ce profil: recherches, listes d'amis, informations personnelles, correspondances.

Le transfert et le stockage des données se fait sous le même format: XML. Le format de ces fichiers XML est décrit par des fichiers XML schémas. Certains attributs sont présents dans le document XML généré seulement lorsqu'on transfère ou seulement lorsqu'on stocke. Par exemple, les informations de visibilité des blocs d'information sont présents lorsqu'on stocke le profil sur le terminal local pour le sauvegarder, mais pas lorsqu'on transfère son profil à un terminal distant. Ceci est documenté dans les schémas XML.

Le chapitre suivant décrit les traitements effectués par le logiciel implémentant la présente invention sur le réseau Bluetooth, les terminaux, et les recherches: - communications, - gestion des terminaux, -gestion et comparaison des annonces, - sauvegarde et chargement des données, traitements de sécurité, - actions effectuées par l'utilisateur et traitements divers.

Dans tout ce qui suis, le terme "client" définit le terminal qui établit la connexion. Le terme serveur définit le terminal qui accepte la connexion. On note que les transactions bornes / bornes ne sont pas envisagées. Le fichier échangé contient toutes les recherches et informations visibles de petite taille. Le terminal qui reçoit les recherches compare les recherches reçues avec ses recherches et renvois toute ses recherches visibles ainsi que les recherches filtres qui ont correspondu. Les informations de grosse taille (photos par exemple) seront envoyées en utilisant le transfert de fichier sur demande explicite de l'utilisateur.

Le terminal serveur traite les recherches reçues à partir du terminal client avant d'envoyer les siennes au terminal client de manière a pouvoir aussi envoyer les recherches filtres qui ont correspondu avec des recherches en provenance du terminal client. Ceci évite d'avoir à faire un traitement particulier pour les bornes, toutes les recherches des bornes sont en mode "filtre".

La transaction d'envoi de mises à jour des recherches et des informations a lieu quand le contenu d'une recherche change ou que des recherches ou informations changent de visibilité. Les événements susceptibles d'entraîner une mise à jours sont: - l'ajout d'une recherche ou d'une information, - le changement de visibilité élémentaire d'une recherche ou d'une information et - la modification d'une recherche ou d'une information.

Dés qu'il y a un changement, on renvoie toute les recherches et les informations comme dans la transaction (annulation et remplacement) afin d'éviter des traitements de mise à jour des informations dans le terminal distant.

La transaction de transfert de fichiers a lieu entre deux terminaux implémentant la présente invention. Elle permet de demander un fichier d'un terminal à un autre (comme par exemple la photo de l'utilisateur, de la musique, des documents, etc.).

Le transfert a lieu à la demande de l'utilisateur du terminal de destination. La liste des fichiers est disponible dans les informations de l'utilisateur du terminal source. Cette solution a l'avantage d'éviter une requête supplémentaire au terminal source pour obtenir cette liste des fichiers disponibles.

Cet échange de messages ne peut avoir lieux que si l'échange de message initial a eu lieu (pour récupérer la liste des fichiers disponibles).

La transaction de parrainage a lieu entre un terminal local implémentant l'application et un terminal parrainable. Le terminal implémentant l'application envoie un message ObEx contenant l'application pour le système d'exploitation du terminal distant. Un fois le message reçu, le terminal nouvellement parrainé ObEx propose automatiquement d'installer le logiciel.

La base SDP permet de récupérer la Class Of Device (COD) d'un terminal donné. Le COD d'un terminal contient le type de terminal (souris, oreillette, ...).

Un terminal passif est un terminal Bluetooth n'exécutant pas l'application implémentant la présente invention mais dont le nom détectable contient une recherche ou des éléments de profil de l'utilisateur (voir figures 2 et 3).

Cette transaction se passe entre un terminal passif et un terminal dont l'application est active ou une borne. Le terminal actif récupère la recherche dans le nom Bluetooth du terminal passif et la compare avec ses recherches locales.

Quand un terminal local enregistre dans sa liste d'amis un terminal distant, le terminal local envoie au terminal distant un message contenant la confirmation qu'il est inscrit dans la liste d'amis de du terminal local.

Dans un message qui contient les informations et recherches à envoyer au terminal distant, les recherches peuvent être indifféremment visible ou filtre et les informations peuvent être indifféremment filtre ou visible. Il se peut que la partie information et/ou la partie recherche soit vide.

Avec un message qui contient la demande de fichier à télécharger à partir du terminal distant, le terminal local peut retrouver les fichiers disponibles dans les informations de l'utilisateur du terminal distant.

Le module de communication utilise les fonctions élémentaires décrites cidessous.

- la détection des terminaux se fait via des "inquiries" Bluetooth. On obtient ainsi les adresses Bluetooth et le nom Bluetooth. La phase d'inquiry a une durée variable, - un terminal est détectable lorsqu'il n'est pas connecté à un autre terminal et qu'il n'est pas en train de faire d'inquiry, - le terminal peut publier des informations de service en utilisant SDP ("Service Discovery Protocol"). II est donc possible aux terminaux de savoir si l'application implémentant la présente invention est installée sur un terminal et si oui, quelle est sa version, l'état du logiciel (Actif, ...), les modules installés. Si SDP ne fonctionne pas, il est toujours possible d'utiliser le nom Bluetooth du terminal, - le terminal local obtient les informations de service en interrogeant la base SDP du terminal distant. Si on utilise le nom Bluetooth du terminal pour stocker les informations de service, le terminal local les récupère en demandant son nom au terminal distant lors de l'inquiry, - pour l'envoi et la réception des données, trois techniques sont envisageables: les connexions RFCOMM, les connexions OBEX (OBject EXchange) mise en oeuvre dans les modes de réalisation décrits ci-dessus et transmission de données via SDP (Le terminal émetteur met à jours ces données SDP, le terminal récepteur interroge la base SDP de l'émetteur).

Pour détecter certains terminaux, le texte de la recherche commence par un caractère spécifique qui a peu de chance de débuter par hasard le nom d'un terminal, par exemple)'.

Lorsque ce caractère est détecté, le nom Bluetooth sera considéré comme une recherche et interprété. Si le nom du terminal commence par le caractère ')' par hasard, mais qu'il ne s'agit pas d'une recherche, le logiciel ne détectera jamais de correspondance ou bien ne sera pas capable de répondre. Le logiciel se comportera correctement en cas d'erreur de formatage de la recherche.

Le traitement des terminaux détectés comportent les fonctions suivantes: lors de la découverte d'un terminal, on recherche dans la liste noire l'adresse Bluetooth du terminal détecté. Si le terminal n'est pas dans la liste noire et que le terminal n'est pas dans la liste des terminaux "DeviceList", on traite le terminal et on l'ajoute dans la liste des terminaux "DeviceList" ; - la liste des terminaux "DeviceList" doit être mise à jour à intervalle de temps régulier de manière à retirer les terminaux qui n'ont pas été détectés depuis un certain temps.

- le traitement d'un terminal distant: si une recherche passive est contenue dans le nom Bluetooth du terminal distant, on traite la recherche. Si c'est un terminal dont l'application implémentant la présente invention est active, on échange et on traite les recherches.

- le fichier envoyé au terminal distant contient les recherches visibles stockées sur le terminal et les informations visibles stockées sur le terminal. Si le terminal distant est dans la liste des terminaux amis, on envoie les informations filtres disponibles sur le terminal. Si le fichier est envoyé après la réception des recherches distantes sur le terminal local, on y rajoute les recherches filtres qui ont matchées avec les recherches fraîchement reçues. Si le terminal local possède des réponses à des recherches " bouche à oreille ", le terminal local rajoute aux recherches existante des offres contenant les données à propager et matchant avec des demande " bouche à oreille ".

- le logiciel découpe la recherche et crée les structures de données internes correspondant à la recherche. Ensuite une comparaison avec toutes les recherches locales disponibles est faite. En cas de correspondance (en anglais "matching"), on notifie l'utilisateur. On prévient éventuellement le terminal passif par un appel téléphonique ou un SMS.

- pour chaque recherche reçue, si la recherche n'est pas déjà enregistrée dans la liste des réponses (Match List), pour chaque recherche stockée, s'il y a correspondance entre la recherche reçue et la recherche stockée, enregistrer la réponse et la signaler à l'interface utilisateur. On compare le type de la recherche distante et le type de la recherche locale. Si les types correspondent on poursuit la comparaison en comparant les offres et les demandes. S'il y a correspondance entre l'offre de la recherche 1 et la demande de la recherche 2 et qu'il y a correspondance entre la demande de la recherche 1 et l'offre de la recherche 2, alors, il y a correspondance entre les deux recherches. On vérifie tout d'abord la correspondance des classes des recherches. Puis on compare les codes des deux recherches. Ensuite on compare les conditions de la recherche locale avec les caractéristiques de la recherche distante. Enfin on compare les mots clefs de la recherche locale avec le texte de la recherche distante. On note que les classifications sont des codes de 5 caractères, que pour qu'il y ait correspondance, il faut que la classification de la demande corresponde aux premiers caractères de la classification de l'offre et que l'offre peut être plus précise que la demande mais elle doit être incluse dans la demande. En cas d'écart de précision, seule la recherche du moins précis est satisfaite. Une recherche moins précise peut ne pas potentiellement intéresser l'utilisateur (Logique d'inclusion et non d'égalité). Pour que les recherches correspondent, la classe locale de la recherche doit être inclue dans la classe distance, le code rubrique de la recherche locale doit correspondre avec celui de la recherche distante, les mots clés de la recherche locale doivent correspondre avec ceux de la recherche distante. On compare les conditions de l'offre avec les caractéristiques de la demande distante. Si une condition de l'offre n'est pas dans la demande, il n'y a pas correspondance. Une condition locale correspond à une condition distante s'il existe un attribut dans la recherche distante nommée comme la condition locale, et que la valeur de l'attribut distant est en accord avec la condition locale. Il y a correspondance si toutes les conditions locales sont en accords avec les attributs distants. La chaîne de recherche contenant les mots clés est analysée et découpée. Elle peut contenir plusieurs mots clés séparés par des espaces. Si tous les mots clefs spécifiés dans la recherche sont dans le texte de l'offre, il y a correspondance.

- les traitements d'entrée-sortie sont ceux gérant la sauvegarde et la récupération des informations. Pour l'écriture (et aussi pour l'envoi sur le réseau) on passera par une phase de formatage des données. Pour la lecture des données (et pour la réception sur le réseau) on passera par une phase de parsing (que l'on pourrait traduire par "découpage/interprétation") des données. L'application implémentant la présente invention n'utilise pas de base de données, les données sont sauvegardées dans un fichier XML. Les traitements de sauvegarde consistent à formater les données et à les écrire dans ce fichier. Les traitements de chargement consistent à lire ce fichier, à l'analyser et à créer les objets interne à l'application. Ces traitements classiques ne sont pas décris dans ce document.

- comme le format de stockage choisi pour les données est (WB)XML, le formatage des données consiste à générer du code XML conforme aux "XML Schémas" définis dans la partie donnée à partir des objets en mémoire.

- de manière à préserver la confidentialité des échanges entre les utilisateurs et à éviter le "reverse engineering" (ingéniérie inversée) du protocole utilisé pour communiquer entre les périphériques, toutes les communications passant sur le réseau Bluetooth seront cryptées en utilisant les possibilités de cryptage automatique proposées par Bluetooth.

- pour recharger les unités d'un terminal, on génère aléatoirement un identifiant de quatre chiffres (en se basant sur l'heure en cours, l'adresse Bluetooth du terminal, ...). L'utilisateur envoie cet identifiant à un serveur qui renvoie la réponse contenant cet identifiant et le nombre d'unités achetées crypté avec la clé privée de l'application. Le téléphone décrypte le message reçu, compare l'identifiant reçu avec l'identifiant généré, et en cas de similitude, incrémente le compteur d'unités du nombre d'unités achetées.

- au lancement de l'application, le profil utilisé est le profil par défaut non protégé.

L'utilisateur peu créer des profils secrets protégés par mot de passe. Il saisit le mot de passe choisis et le nouveau profil est crée. Pour passer d'un profil à un autre, il lui suffit de taper le mot de passe désiré. Lorsque l'utilisateur change de profil, son nom Bluetooth est mis à jours. Un fois ce profil activé il peut le supprimer.

- lors de l'initialisation de l'application implémentant la présente invention, celle-ci charge le profile, s'enregistre dans la base SDP, fourni à cette base toutes les informations nécessaires, lance le module de communication et affiche le menu principal.

- lors du passage en mode inactif, l'application implémentant la présente invention sauvegarde le profile courant, restaure les paramètres Bluetooth qu'elle aurait éventuellement modifié et mets son statut à "inactif' dans la base SDP. Lors de la fermeture de l'interface graphique, le module de communication continue à tourner en tache de fond.

- l'identifiant unique associé à chaque recherche est calculé de la manière suivante: id = addrBT + systemTime systemTime étant le nombre de millisecondes écoulées depuis le temps " zéro " sur le terminal (généralement depuis le 11eI janvier 1970) à la création de la recherche ou lors de sa modification.

- les notifications de correspondance sont reportées à l'utilisateur sous forme de sonnerie quand le terminal est en mode "visible" ou "filtre", via le vibreur si le terminal en est équipé et que le mode du terminal est "invisible". Si le terminal ne possède pas de vibreur, aucun son ne sera émis.

Parmi les applications de la présente invention, on peut citer les petites annonces, le partage de jeux, les communautés, les informations locales, par exemple état du trafic, les informations de gares, par exemple la voie et l'heure d'un train, les informations de guichet bancaire, les audio-guides de musées, les offres de tous les magasins d'un centre commercial.

Claims (31)

REVENDICATIONS

1 - Procédé de mise en relation automatique de terminaux proches, caractérisé en ce qu'il comporte une procédure de détection mutuelle en tâche de fond comportant en alternance: . une étape de détection des terminaux détectables (200) et une étape au cours de laquelle le terminal est lui-même détectable (400).

2 - Procédé selon la revendication 1, caractérisé en ce qu'il comporte, pour au moins un cycle, une étape de tirage aléatoire (420) et, en fonction du résultat dudit tirage, une étape de définition (425), pour ce cycle, de la durée d'au moins une des étapes de détection ou de détectabilité.

3 - Procédé selon la revendication 2, caractérisé en ce que le tirage aléatoire (420) est équiprobable et l'étape de définition (425) définit la durée de l'étape de détectabilité en fonction d'un multiple de la durée de l'étape de détection et du résultat du tirage aléatoire.

4 - Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, une fois qu'un terminal a détecté un autre terminal susceptible de communiquer, il effectue au moins une tentative de connexion à cet autre terminal (500).

5 - Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que au cours de chaque cycle, le nombre de tentatives de connexion est inférieur à une valeur prédéterminée (320, 610).

6 - Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le nombre de tentatives de connexion successives au même terminal est inférieur à une valeur prédéterminée (525, 610).

7 - Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que si des tentatives de connexions avec plusieurs terminaux sont à effectuer, on ne tente pas plusieurs fois de suite de se connecter au même terminal (500).

8 - Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'un nombre limite de tentatives de connexion par terminal est défini (320), lorsque ce nombre de tentatives est atteint sans qu'une connexion puisse être établie, on attend pendant au moins une durée prédéterminée, avant d'effectuer de nouveau au moins une tentative de connexion avec ce terminal.

9 - Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comporte: - une étape de modification du nom détectable du terminal (130) pour y incorporer au moins un signe de reconnaissance d'une application prédéterminée en fonctionnement et susceptible d'échanger des données avec d'autres terminaux et - pendant une étape de détectabilité, en cas de détection par un autre terminal, une étape de transmission dudit nom détectable.

- pendant une étape de détection, en cas de détection d'un autre terminal, une étape d'analyse du nom du terminal détecté afin d'y rechercher ledit signe de reconnaissance (220, 225).

- Procédé selon la revendication 9, caractérisé en ce que, au cours de ladite étape de modification du nom détectable (130), on ajoute au moins un caractère reconnaissable en début du nom détectable.

11 - Procédé selon l'une quelconque des revendications 9 ou 10, caractérisé en ce que, au cours de l'étape de modification de nom détectable (130), on ajoute le caractère ")" au nom détectable.

12 - Procédé selon l'une quelconque des revendications 9 à Il, caractérisé en ce que, au cours de l'étape de modification du nom détectable (130), on modifie le nom détectable pour y incorporer soit un premier signe de reconnaissance indiquant l'installation sur ledit terminal d'une application prédéterminée, ladite application étant arrêtée, soit un deuxième signe de reconnaissance indiquant l'installation sur ledit terminal de l'application prédéterminée, ladite application étant en fonctionnement.

13 - Procédé selon l'une quelconque des revendications 9 à 12, caractérisé en ce qu'il comporte une étape de recherche de détection (200) d'au moins un terminal possédant un nom détectable possédant ledit signe de reconnaissance et, lorsqu'un tel terminal a été détecté, une étape d'arrêt momentané de recherche d'autres terminaux.

14 - Procédé selon l'une quelconque des revendications 9 à 13, caractérisé en ce que, au cours de l'étape de modification du nom détectable du terminal (130), on y incorpore plusieurs informations organisées selon un format prédéterminé.

- Procédé selon la revendication 14, caractérisé en ce que lesdites informations comportent: - une identification de leur format et -des informations organisées selon ledit format.

16 - Procédé selon l'une quelconque des revendications 14 ou 15, caractérisé en ce que, en cas de détection d'un autre terminal, on effectue une étape d'analyse du nom du terminal détecté afin d'y rechercher lesdites informations.

17 - Procédé selon l'une quelconque des revendications 1 à 16, caractérisé en ce que qu'il comporte: - une étape de détection d'un autre terminal (200, 205) et - une étape de mémorisation (220, 225) d'au moins: un identifiant dudit autre terminal et 35. la date de la dernière de ces tentatives.

18 - Procédé selon la revendication 17, caractérisé en ce que, au cours de l'étape de mémorisation (220, 225), on mémorise, en outre, un nombre de tentatives d'établissement de connexion avec ledit autre terminal déjà effectuées (520).

19 - Procédé selon l'une quelconque des revendications 17 ou 18, caractérisé en ce que, après un nombre prédéterminé de tentatives infructueuses concernant un autre terminal, on arrête les tentatives d'établissement de liaison avec ledit autre terminal (610).

20 - Procédé selon l'une quelconque des revendications 17 à 19, caractérisé en ce que, au cours de l'étape de mémorisation (220, 225), on mémorise, en outre, si une application prédéterminée fonctionne sur ledit autre terminal.

21 - Procédé selon l'une quelconque des revendications 17 à 20, caractérisé en ce qu'il comporte une étape de détermination de probabilité de présence (315) et une étape de tentative de connexion (300, 305) au cours de laquelle on tient compte d'une probabilité de présence dudit autre terminal pour déterminer si une tentative de connexion doit être effectuée.

22 - Procédé selon la revendication 21, caractérisé en ce que, au cours de l'étape de détermination de probabilité de présence (315), on calcule la probabilité de présence d'un terminal en fonction du nombre d'étapes de détection successives pour lesquelles ledit terminal n'a pas été détecté depuis sa dernière détection.

23 - Procédé selon l'une quelconque des revendications 21 ou 22, caractérisé en ce que, au cours de l'étape de détermination de probabilité de présence (315), on calcule la probabilité de présence d'un terminal en fonction du fonctionnement d'une application sur ledit terminal et rendant ledit terminal plus difficile à détecter.

24 - Procédé selon l'une quelconque des revendications 21 à 23, caractérisé en ce que, au cours de l'étape de détermination de probabilité de présence (315), on calcule la probabilité de présence d'un terminal en fonction du type dudit autre terminal.

- Procédé selon l'une quelconque des revendications 21 à 24, caractérisé en ce que, au cours de l'étape de détermination de probabilité de présence (315), on calcule la probabilité de présence d'un terminal en fonction de l'historique des détections dudit terminal.

26 - Procédé selon l'une quelconque des revendications 1 à 25, caractérisé en ce qu'il comporte: - une étape de mémorisation d'identifiants de terminaux avec lesquels une communication a été établie (220, 225, 715, 720) et - une étape de mémorisation (220, 225, 715, 720) de la date et de l'heure à laquelle une communication a été établie, pour chaque terminal dont un identifiant a été mémorisé.

27 - Procédé selon la revendication 26, caractérisé en ce qu'il comporte, en outre, une étape de mémorisation d'un nombre de tentatives d'accès effectuées auprès de chaque terminal dont un identifiant a été mémorisé, au cours d'un cycle ou d'un intervalle de temps prédéterminé.

28 - Procédé selon l'une quelconque des revendications 26 ou 27, caractérisé en ce qu'il comporte, en outre, une étape de mémorisation d'idéntifiants de terminaux avec lequel l'utilisateur ne souhaite pas communiquer (145).

29 - Procédé selon l'une quelconque des revendications 26 à 28, caractérisé en ce qu'il comporte, en outre, une étape de mémorisation (715, 720) de la date de mise à jour des données déjà transmises à chaque terminal dont un identifiant a été mémorisé.

- Procédé selon l'une quelconque des revendications 1 à 29, caractérisé en ce qu'il comporte une étape d'alerte de détection d'un autre terminal (230) lorsque au moins une durée prédéterminée s'est écoulée depuis sa dernière détection.

31 - Procédé selon l'une quelconque des revendications 1 à 30, caractérisé en ce qu'il comporte une étape de détermination d'un mode de communication (145) entre au moins: - un mode de communication dans lequel une application mise en oeuvre par ledit terminal communique avec tout autre terminal, à l'exception de terminaux avec lequel l'utilisateur ne souhaite pas communiquer et - un mode de communication dans lequel une application mise en oeuvre par ledit 15 terminal ne communique qu'avec des terminaux explicitement identifiés en mémoire dudit terminal.

32 - Procédé selon la revendication 31, caractérisé en ce que, au cours de l'étape de détermination d'un mode de communication (145), dans un mode de communication, l'application ne communique avec aucun autre terminal.

33 - Procédé selon l'une quelconque des revendications 31 ou 32, caractérisé en ce que, au cours de l'étape de détermination d'un mode de communication (145), dans au moins un mode communication, une partie des informations n'est transmise qu'à des terminaux explicitement identifiés en mémoire dudit terminal.

34 - Procédé selon l'une quelconque des revendications 1 à 33, caractérisé en ce qu'il 25 comporte: - une étape de détection d'au moins un autre terminal (205) et - une étape d'estimation de probabilité de présence (220, 225, 315) de chaque dit autre terminal.

- Procédé selon la revendication 34, caractérisé en ce que, au cours de l'étape d'estimation de probabilité de présence (220, 225, 315), à chaque fois qu'un autre terminal est détecté (205, 220, 225), sa probabilité de présence est maximale et cette probabilité décroît ensuite progressivement (315).

36 - Procédé selon l'une quelconque des revendications 34 ou 35, caractérisé en ce que, au cours de l'étape d'estimation de probabilité de présence (220, 225, 315), la probabilité de présence d'un terminal décroît en fonction du nombre de fois où ledit terminal n'est pas détecté.