Brevet FR2882876A1 — publié le 20060908

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 peut créer une liaison Bluetooth entre deux appareils. 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 mobiles proches, qui comporte: -une étape de description d'au moins une recherche sur chacun d'au moins deux terminaux, par leurs utilisateurs respectifs, - une étape de communication sans fil, entre un desdits terminaux, dit terminal émetteur et un autre desdits terminaux, dit terminal destinataire , au cours de laquelle, le terminal émetteur transmet au terminal destinataire une information représentative d'au moins une recherche, - une étape de traitement de chaque recherche reçue, par le terminal destinataire, pour déterminer une éventuelle correspondance entre la recherche reçue du terminal émetteur avec au moins une recherche conservée par ledit terminal destinataire et - en cas de correspondance, une étape d'affichage, sur le terminal destinataire, d'une information représentative de ladite correspondance. Grâce à ces dispositions, les utilisateurs des terminaux mobiles peuvent réaliser une description de leurs recherches, par exemple offres ou demandes de produits ou services ou proposition de rencontres, et l'utilisateur du terminal destinataire peut entrer en relation avec l'utilisateur du terminal émetteur lorsque leurs recherches se correspondent, éventuellement automatiquement. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, en cas de correspondance, une étape de communication d'une information représentative de ladite correspondance, depuis le terminal destinataire au terminal émetteur. Grâce à ces dispositions, l'utilisateur du terminal émetteur peut aussi entrer en communication avec l'utilisateur du terminal destinataire lorsque leurs recherches se correspondent, éventuellement automatiquement. Selon des caractéristiques particulières, au cours de l'étape de description d'une recherche, on sélectionne, dans une arborescence, une rubrique descriptive de la recherche. Grâce à ces dispositions, l'étape de traitement permet de comparer les recherches de façon automatique, rapide et sûre, par simple comparaison des rubriques des recherches à comparer. Selon des caractéristiques particulières, au cours de l'étape de communication sans fil, entre le terminal émetteur et le terminal destinataire, on communique un identifiant de chaque rubrique sélectionnée. Grâce à ces dispositions, on réduit la bande-passante utilisée pour la communication d'une recherche, les identifiants nécessitant moins d'information que les noms des rubriques. Selon des caractéristiques particulières, au cours de l'étape d'affichage, on affiche les rubriques dans une langue sélectionnée pour le terminal destinataire, à partir des identifiants des rubriques sélectionnées. Grâce à ces dispositions, des utilisateurs de langues différentes peuvent entrer en relation sur la base de recherches exprimées dans leurs langues respectives. Selon des caractéristiques particulières, au cours de l'étape de description d'au moins une recherche, on précise la rubrique choisie dans l'arborescence des rubriques et sous-rubriques, par la saisie d'un texte libre. Par exemple, on peut préciser la rubrique Communauté / Ecole par le texte HEC . Selon des caractéristiques particulières, au cours de l'étape de description d'une recherche, on décrit une offre en affectant au moins une valeur à un attribut caractéristique de cette offre. Par exemple, on peut affecter la valeur 5 000 Euros à l'attribut prix ou choisir la valeur Renault dans une liste pour l'attribut Marque . Selon des caractéristiques particulières, au cours de l'étape de description d'une offre, on saisit un texte libre. Selon des caractéristiques particulières, au cours de l'étape de description d'au moins une recherche, on décrit une demande en affectant au moins une condition portant sur un attribut. Selon des caractéristiques particulières, ladite condition comporte un opérateur de comparaison et une valeur saisie librement ou choisie dans une liste de valeurs possibles. Par exemple, on peut ainsi fixer un prix maximum de 100 Euros en sélectionnant l'attribut Prix , l'opérateur Selon des caractéristiques particulières, chaque valeur prédéfinie pouvant être affectée à un attribut possède un identifiant et des libellés dans une ou plusieurs langues. Selon des caractéristiques particulières, Selon des caractéristiques particulières, au cours de l'étape de traitement, on détermine une correspondance entre une offre et une demande seulement si les rubriques se correspondent et si toutes les conditions de la demande sont remplies par les attributs de l'offre. Selon des caractéristiques particulières, caractérisé en ce que, au cours de l'étape de description d'une demande, on saisit un ou plusieurs mots clés. Selon des caractéristiques particulières, caractérisé en ce que, au cours de l'étape de traitement, on détermine une correspondance entre une offre et une demande si les mots clés de la demande se retrouvent tous dans le texte libre décrivant l'offre ou dans les libellés des rubriques et des valeurs décrivant l'offre, dans la langue utilisée pour exprimer la demande. Selon des caractéristiques particulières, au cours de l'étape de description d'au moins une recherche, on décrit un échange proposé, constitué d'au moins une offre et d'au moins une demande liées entre elles. Selon des caractéristiques particulières, caractérisé en ce qu'il comporte une étape de définition d'au moins un profil décrivant l'utilisateur du terminal, ce profil étant composé 20 d'informations définies en affectant des valeurs à des attributs. Selon des caractéristiques particulières, au cours de l'étape de description d'au moins une recherche, on décrit une offre de rencontre, constituée d'une offre correspondant à un profil de l'utilisateur du terminal émetteur et d'une demande décrivant des conditions à remplir par un profil de l'utilisateur du terminal destinataire. Selon des caractéristiques particulières, l'étape de description d'une recherche comporte une étape d'affectation d'un niveau de visibilité qui définit les appareils qui pourront recevoir cette recherche lors de l'étape de communication. Selon des caractéristiques particulières, les niveaux de visibilité comportent un niveau de visibilité dit visible par tous , chaque recherche possédant ce niveau de 30 visibilité pouvant être diffusée à tous les appareils rencontrés. Selon des caractéristiques particulières, les niveaux de visibilité comportent un niveau de visibilité dit filtré , chaque recherche possédant ce niveau de visibilité n'étant divulguée à l'utilisateur du terminal destinataire qu'en cas de correspondance avec une de ses recherches. Selon des caractéristiques particulières, les niveaux de visibilité comportent un niveau de visibilité dit invisible , chaque recherche possédant ce niveau de visibilité n'étant jamais communiquée automatiquement à d'autres terminaux. Selon des caractéristiques particulières, la visibilité de chaque recherche peut être précisée par une liste de terminaux individuellement exclus , auxquels cette recherche n'est jamais communiquée automatiquement et par une liste de terminaux individuellement autorisés qui peuvent automatiquement recevoir cette recherche. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape d'identification de terminaux d'une liste dite noire , aucune information n'étant communiquée aux dits terminaux de la liste noire. Selon des caractéristiques particulières, au cours de l'étape de communication avec un terminal destinataire, on effectue un horodatage de la communication dans le terminal émetteur. Selon des caractéristiques particulières, au cours de l'étape de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche. Selon des caractéristiques particulières, au cours de l'étape de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche pour chaque niveau de visibilité, afin de conserver la date et l'heure de la dernière modification affectant les informations visibles audit niveau. Selon des caractéristiques particulières, au cours de l'étape de communication, on détermine si un terminal destinataire a reçu l'ensemble des recherches qu'il peut recevoir en comparant l'horodatage de la précédente communication avec ledit terminal destinataire à l'horodatage de la dernière édition de chaque recherche ayant affecté les informations visibles par ledit terminal. Selon des caractéristiques particulières, au cours de l'étape de communication, on communique au terminal destinataire seulement les recherches dont la dernière version ne lui a pas encore été communiquée. Selon un deuxième aspect, la présente invention vise un procédé de mise en correspondance de terminaux se trouvant à proximité, caractérisé en ce qu'il comporte: - une étape de définition, sur un terminal utilisateur local, d'au moins un profil décrivant l'utilisateur du terminal, composé d'informations à transmettre à d'autres terminaux, éventuellement regroupées en groupes d'informations - une étape d'attribution à au moins un profil, un groupe d'informations ou une information d'un niveau de visibilité choisi entre différents niveaux de visibilité définissant des sous-ensembles d'informations et des groupes de terminaux destinataires autorisés à les recevoir; - une étape de détection de terminaux situés à proximité ; - une étape de détermination d'appartenance d'un terminal détecté à l'un des groupes de terminaux destinataires et - si le terminal détecté fait partie d'un groupe de terminaux autorisés à recevoir des informations, une étape de communication audit terminal du sous-ensemble d'informations correspondant. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte un niveau de visibilité dit visible par tous qui autorise les profils, groupes d'informations et informations possédant ce niveau de visibilité à être communiqués automatiquement à un groupe d'autre terminaux englobant tous les terminaux détectés. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte un niveau de visibilité dit invisible qui interdit les profils, groupes d'informations et informations possédant ce niveau de visibilité à être communiqués automatiquement à d'autre terminaux. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte un niveau de visibilité dit filtré et une étape de définition d'une liste de terminaux dits amis , lesdits terminaux constituant un groupe de terminaux autorisés à recevoir les profils, groupes d'informations ou informations possédant les niveaux de visibilité visible par tous ou filtré . Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de définition d'une liste de terminaux bloqués dite liste noire , constituant un groupe de terminaux qui ne sont autorisés à recevoir aucune information. Selon des caractéristiques particulières, la visibilité d'un profil, d'un groupe d'informations ou d'une information peut être précisée par une liste de terminaux individuellement exclus auxquels ce profil, ce groupe d'informations ou cette information n'est jamais communiqué automatiquement et par une liste de terminaux individuellement autorisés qui peuvent recevoir automatiquement ce profil, ce groupe d'informations ou cette information. Selon des caractéristiques particulières, au cours de chaque étape de communication entre le terminal local et un autre terminal, un horodatage de ladite communication est mémorisée par le terminal local. Selon des caractéristiques particulières, au cours de l'étape d'édition d'une information, un horodatage est affecté au profil modifié. Selon des caractéristiques particulières, au cours de l'étape d'affectation d'un niveau de visibilité, un horodatage est affecté au profil modifié. Selon des caractéristiques particulières, au cours de l'étape d'édition d'une information et au cours de l'étape d'affectation d'un niveau de visibilité, un horodatage est affecté au profil modifié pour chaque niveau de visibilité dont les informations sont modifiées. Selon des caractéristiques particulières, au cours de chaque étape de communication entre le terminal local et un autre terminal, l'horodatage de la précédente communication entre lesdits terminaux est comparé à l'horodatage de chaque groupe d'information défini avec le terminal local et, seulement pour les groupes pour lesquels le deuxième horodatage est postérieur au premier horodatage, l'étape de communication dudit groupe d'information est effectuée. Selon un troisième aspect, la présente invention vise un procédé de mise en correspondance de terminaux se trouvant à proximité, caractérisé en ce qu'il comporte: une étape de définition de rubriques, sous-rubriques et valeurs possibles d'attributs ou de critères dans au moins deux langues différentes; - une étape de sélection d'une langue par au moins deux utilisateurs de deux 10 terminaux; une étape de définition d'une recherche, sur un premier terminal, par sélection dans des listes de valeurs possibles d'attributs ou de critères dans des rubriques et sousrubriques, lesdites valeurs, rubriques et sous-rubriques étant exprimées dans la langue choisie par l'utilisateur du premier terminal; une étape de communication, depuis le premier terminal à un deuxième terminal se trouvant à proximité du premier terminal, d'une information représentative de chaque rubrique ou sous-rubrique et chaque valeur d'attribut ou de critère sélectionnée par le premier utilisateur et - en cas d'affichage, sur le deuxième terminal, d'éléments de la recherche définie sur le premier terminal, ledit affichage est effectué avec des valeurs, rubriques et sous-rubriques exprimées dans la langue choisie par l'utilisateur du deuxième terminal. Grâce à ces dispositions, l'information représentative d'une recherche peut être très compacte, sa communication étant donc très rapide. De plus, deux utilisateurs peuvent se communiquer des recherches même s'ils ne pratiquent aucune langue commune. Selon un quatrième aspect, la présente invention vise un procédé de mise en correspondance de terminaux se trouvant à proximité, caractérisé en ce qu'il comporte, dans un terminal utilisateur: - une étape de réception d'un message depuis un premier terminal se trouvant à 30 proximité et une étape de retransmission automatique dudit message à un autre terminal se trouvant à proximité. Selon des caractéristiques, le procédé tel que succinctement exposé cidessus comporte une étape d'autorisation, par l'utilisateur dudit terminal utilisateur, de 35 retransmission de messages et, seulement si l'autorisation est donné, l'étape de retransmission automatique est effectuée. Selon des caractéristiques particulières, au cours de l'étape de retransmission automatique, un numéro incorporé dans ledit message est incrémenté ou décrémenté. Selon des caractéristiques particulières, ledit numéro est extrait du message reçu et comparé à une valeur limite et, seulement si ledit numéro est inférieur à la valeur seuil limite, il est retransmis au cours de l'étape de retransmission automatique. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape d'extraction du message reçu d'un indicateur de retransmission et seulement si l'indicateur de retransmission est présente, ledit message est retransmis au cours de l'étape de retransmission automatique. Selon un cinquième aspect, la présente invention vise un procédé de fonctionnement d'une borne de communication sans fil à courte portée avec des terminaux mobiles, caractérisé en ce qu'il comporte: - une étape de réception, par ladite borne, d'une information provenant d'un premier terminal se trouvant à portée de ladite borne; - une étape de conservation, pendant une durée prédéterminée, de ladite information et en cas de connexion avec un deuxième terminal différent du premier terminal, une étape de transmission, par ladite borne, de ladite information au deuxième terminal. 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; - la figure 13 représente des échanges de données entre deux terminaux dans la 10 mise en oeuvre du mode particulier de réalisation illustré dans les figures 1 à 12 et - la figure 14 représente des successions d'étapes mise en oeuvre par deux terminaux pour la mise en correspondance de recherches. 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 la marque, 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 "(" 1", ")" "}" "] " 101 "#" "-" "&" ""' "-" "_" "Et" 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 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 20 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é 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 25 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ême s'il n'y a aucune information modifiée, auquel cas le formatage concerneune 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 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 afficher la description de branches d'arborescence peut ensuite être effectué 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). La figure 14 représente des successions d'étapes mise en oeuvre par deux terminaux pour la mise en correspondance de recherches, dans un mode particulier de réalisation. Les étapes mises en oeuvre par l'un des terminaux sont représentées sur la gauche de la figure 14, tandis que les étapes mises en oeuvre par l'autre terminal sont représentées sur la droite de la figure 14. Au cours d'étapes 1405 et 1455, chacun des utilisateurs des terminaux définit son profil, décrivant l'utilisateur du terminal, ce profil est composé d'informations définies en affectant des valeurs à des attributs et, éventuellement, en donnant des mots-clés dans des champs libres. Puis, au cours d'étapes 1410 et 1460, chacun des utilisateurs des terminaux décrit au moins une recherche, sur chacun d'au moins deux terminaux. A cet effet, l'utilisateur sélectionne, dans une arborescence, une rubrique descriptive de la recherche puis des sous- rubriques descriptives et précisant la recherche. Enfin, l'utilisateur on précise la rubrique choisie dans l'arborescence des rubriques et sous-rubriques, par la saisie d'un texte libre. En ce qui concerne une recherche de type offre , l'utilisateur décrit une offre en affectant au moins une valeur à un attribut caractéristique de cette offre et on saisit un texte libre. En ce qui concerne une recherche de type demande l'utilisateur décrit une demande en affectant au moins une condition portant sur un attribut, cette condition comportant un opérateur de comparaison et une valeur saisie librement ou choisie dans une liste de valeurs possibles. En complément, l'utilisateur saisit un ou plusieurs mots clés. En ce qui concerne une recherche de type échange , l'utilisateur décrit une recherche de type offre et une recherche de type demande , ces deux recherches étant liées entre elles de manière sous-jacente. En ce qui concerne une recherche de type rencontre , l'utilisateur décrit une offre correspondant à son profil d'utilisateur et une demande décrivant des conditions à remplir par un profil de l'utilisateur du terminal destinataire. Pour chaque type de demande, au cours d'une étape 1415 et 1465, chacun des utilisateurs affecte un niveau de visibilité qui définit les appareils qui pourront recevoir la recherche lors de l'étape de communication. Ce niveau de visibilité peut ensuite être modifié à tout moment par l'utilisateur concerné, par l'utilisation de menus appropriés. A cet effet, l'utilisateur choisit entre différents niveaux de visibilité qui lui sont présentés dans un menu. Ces niveaux de visibilité comportent un niveau de visibilité dit visible par tous qui a pour conséquence que chaque recherche possédant ce niveau de visibilité peut être diffusée à tous les appareils rencontrés. Les niveaux de visibilité comportent un niveau de visibilité dit filtré , chaque recherche possédant ce niveau de visibilité n'étant divulguée à l'utilisateur du terminal destinataire qu'en cas de correspondance avec une des recherches du terminal destinataire. Les niveaux de visibilité comportent un niveau de visibilité dit invisible , chaque recherche possédant ce niveau de visibilité n'étant jamais communiquée automatiquement à d'autres terminaux et n'étant donc communiquée qu'après une action manuelle de la part de l'utilisateur. La visibilité de chaque recherche peut être précisée par une liste de terminaux individuellement exclus , auxquels cette recherche n'est jamais communiquée automatiquement et par une liste de terminaux individuellement autorisés qui peuvent automatiquement recevoir cette recherche. Enfin, l'utilisateur peut identifie des terminaux d'une liste dite noire , aucune information n'étant communiquée aux dits terminaux de la liste noire. Cette identification peut se faire au moment de l'entrée en communication avec un autre terminal, par sélection, dans un menu, d'une fonction d'entrée en liste noire. Comme on le verra ci-dessous, dans ce cas, la recherche déjà transmise au terminal destinataire est immédiatement réactualisée comme une recherche vide dans le terminal destinataire, qui ne peut donc l'afficher à son utilisateur. Au cours de chaque étape de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche. Préférentiellement, au cours de l'étape de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche pour chaque niveau de visibilité, afin de conserver la date et l'heure de la dernière modification affectant les informations visibles audit niveau. Techniquement, chaque valeur prédéfinie pouvant être affectée à un attribut possède un identifiant et des libellés dans une ou plusieurs langues. Au cours d'étapes 1420 et 1470 de communication sans fil, entre un desdits terminaux, dit terminal émetteur , à gauche, et un autre desdits terminaux, dit terminal destinataire , à droite, le terminal émetteur transmet au terminal destinataire une information représentative d'au moins une recherche. Au cours de l'étape 1420 de communication sans fil, entre le terminal émetteur et le terminal destinataire, on communique un identifiant de chaque rubrique sélectionnée, ce qui permet de réduire considérablement la quantité d'information à transférer, d'une part, et d'afficher les rubriques et sous-rubriques dans la langue du destinataire, d'autre part (à cet effet, la liste des rubriques, associée à leurs identifiants, est traduite dans chaque langue dans laquelle le logiciel fonctionne). Les textes libres, mots-clés, valeurs, attributs et conditions sont aussi transmises au cours de cette étape 1420. Au cours de l'étape 1420 de communication avec un terminal destinataire, on effectue un horodatage de la communication dans le terminal émetteur. Le terminal émetteur détermine si un terminal destinataire a reçu l'ensemble des recherches qu'il peut recevoir en comparant l'horodatage de la précédente communication avec ledit terminal destinataire à l'horodatage de la dernière édition de chaque recherche ayant affecté les informations visibles par ledit terminal. Et on communique au terminal destinataire seulement les recherches dont la dernière version ne lui a pas encore été communiquée. Au cours d'une étape 1475, le terminal destinataire effectue le traitement de chaque recherche reçue pour déterminer une éventuelle correspondance entre la recherche reçue du terminal émetteur avec au moins une recherche conservée par le terminal destinataire. Le terminal destinataire détermine une correspondance entre une offre et une demande seulement si les rubriques se correspondent et si toutes les conditions de la demande sont remplies par les attributs de l'offre. De plus, dans des modes de réalisation, il détermine une correspondance entre une offre et une demande si les mots clés de la demande se retrouvent tous dans le texte libre décrivant l'offre ou dans les libellés des rubriques et des valeurs décrivant l'offre, dans la langue utilisée pour exprimer la demande. En cas de correspondance, on effectue une étape d'affichage 1480, sur le terminal destinataire, d'une information représentative de cette correspondance. Préférentiellement, au cours de l'étape d'affichage, on affiche les rubriques dans une langue sélectionnée pour le terminal destinataire, à partir des identifiants des rubriques sélectionnées. Dans des modes de réalisation, en cas de correspondance, le terminal destinataire effectue une étape de communication au terminal émetteur, respectivement étapes 1485 et 1425, d'une information représentative de la correspondance trouvée et, au cours d'une étape 1430, on affiche, sur le terminal émetteur, les éléments de la recherche décrite sur le terminal destinataire, par son utilisateur. 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. II 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 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 35 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. Il 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 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 5 convenu). De plus une recherche peut contenir: des mots clés - un texte descriptif Il 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 / 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 25 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. Il existe trois modes de correspondance (en anglais "matching mode") : "identité" : une recherche de type "identité" correspond à une recherche de type 30 "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 35 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 10 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"). 15 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-Z0-9] [a-zA-Z0-9] [a-zA-Z0-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">âgeet - "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, 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). II s'agitd'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. Il 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 15 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 35 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. II 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. II permet notamment de supprimer des modules et de modifier le classement des modules pour que l'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 10 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 15 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"/"écoute" (un pourcentage) qui définit le ratio des durées des étapes 20 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 35 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 renvoie 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 local traite les recherches reçues à partir du terminal distant avant d'envoyer les siennes au terminal distant de manière a pouvoir aussi envoyer les recherches filtres qui correspondent à des recherches en provenance du terminal distant. 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. II 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 correspondant 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 libre 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. II 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 l' 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. REVENDICATIONS 1 - Procédé de mise en relation automatique de terminaux mobiles proches, caractérisé en ce qu'il comporte: - une étape (1410, 1460) de description d'au moins une recherche sur chacun d'au moins deux terminaux, par leurs utilisateurs respectifs, - une étape (1420, 1470) de communication sans fil, entre un desdits terminaux, dit terminal émetteur et un autre desdits terminaux, dit terminal destinataire , au cours de laquelle, le terminal émetteur transmet au terminal destinataire une information représentative d'au moins une recherche, -une étape (1475) de traitement de chaque recherche reçue, par le terminal destinataire, pour déterminer une éventuelle correspondance entre la recherche reçue du terminal émetteur avec au moins une recherche conservée par ledit terminal destinataire et - en cas de correspondance, une étape (1480) d'affichage, sur le terminal destinataire, d'une information représentative de ladite correspondance. 2 Procédé selon la revendication 1, caractérisé en ce qu'il comporte, en cas de correspondance, une étape (1425, 1485) de communication d'une information représentative de ladite correspondance, depuis le terminal destinataire au terminal émetteur. 3 Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'une recherche, on sélectionne, dans une arborescence, une rubrique descriptive de la recherche. 4 Procédé selon la revendication 3, caractérisé en ce que, au cours de l'étape (1420, 1470) de communication sans fil entre le terminal émetteur et le terminal destinataire, on communique un identifiant de chaque rubrique sélectionnée. Procédé selon l'une quelconque des revendications 3 ou 4, caractérisé en ce que, au cours de l'étape (1480) d'affichage sur le terminal destinataire, on affiche les rubriques dans une langue sélectionnée pour le terminal destinataire, à partir des identifiants des rubriques sélectionnées. 6 Procédé selon l'une quelconque des revendications 3 à 5, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'au moins une recherche, on précise la rubrique choisie dans l'arborescence des rubriques et sous-rubriques, par la saisie d'un texte libre. 7 Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'une recherche, on décrit une offre en affectant au moins une valeur à un attribut caractéristique de cette offre. 8 Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'une offre, on saisit un texte libre. 9 Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'au moins une recherche, on décrit une demande en affectant au moins une condition portant sur un attribut. Procédé selon la revendication 9, caractérisé en ce que ladite condition comporte un opérateur de comparaison et une valeur saisie librement ou choisie dans une liste de valeurs possibles. 11 Procédé selon l'une quelconque des revendications 9 ou 10, caractérisé en ce que chaque valeur prédéfinie pouvant être affectée à un attribut possède un identifiant et des libellés dans une ou plusieurs langues. 12 Procédé selon l'une quelconque des revendications 3 à 6 en combinaison avec la revendication 7 et avec l'une quelconque des revendications 9 à 11, caractérisé en ce que, au cours de l'étape (1475) de traitement, on détermine une correspondance entre une offre et une demande seulement si les rubriques se correspondent et si toutes les conditions de la demande sont remplies par les attributs de l'offre. 13 Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'une demande, on saisit un ou plusieurs mots clés. 14 Procédé selon la revendication 8 en combinaison avec la revendication 13, caractérisé en ce que, au cours de l'étape (1475) de traitement, on détermine une correspondance entre une offre et une demande si les mots clés de la demande se retrouvent tous dans le texte libre décrivant l'offre ou dans les libellés des rubriques et des valeurs décrivant l'offre, dans la langue utilisée pour exprimer la demande. Procédé selon l'une quelconque des revendications 1 à 14, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'au moins une recherche, on décrit un échange proposé, constitué d'au moins une offre et d'au moins une demande liées entre elles. 16 Procédé selon l'une quelconque des revendications 1 à 15, caractérisé en ce qu'il comporte une étape (1405, 1455) de définition d'au moins un profil décrivant l'utilisateur du terminal, ce profil est composé d'informations définies en affectant des valeurs à des attributs. 17 Procédé selon la revendication 16, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'au moins une recherche, on décrit une offre de rencontre, constituée d'une offre correspondant à un profil de l'utilisateur du terminal émetteur et d'une demande décrivant des conditions à remplir par un profil de l'utilisateur du terminal destinataire. 18 Procédé selon l'une quelconque des revendications 1 à 17, caractérisé en ce que l'étape (1410, 1460) de description d'une demande comporte une étape (1415, 1465) d'affectation d'un niveau de visibilité qui définit les appareils qui pourront recevoir cette recherche lors de l'étape de communication. 19 Procédé selon la revendication 18, caractérisé en ce que les niveaux de visibilité comportent un niveau de visibilité dit visible par tous , chaque recherche possédant ce niveau de visibilité pouvant être diffusée à tous les appareils rencontrés. Procédé selon l'une quelconque des revendications 18 ou 19, caractérisé en ce que les niveaux de visibilité comportent un niveau de visibilité dit filtré , chaque recherche possédant ce niveau de visibilité n'étant divulguée à l'utilisateur du terminal destinataire qu'en cas de correspondance avec une de ses recherches. 21 Procédé selon l'une quelconque des revendications 18 à 20, caractérisé en ce que les niveaux de visibilité comportent un niveau de visibilité dit invisible , chaque recherche possédant ce niveau de visibilité n'étant jamais communiquée automatiquement à d'autres terminaux. 22 Procédé selon l'une quelconque des revendications 18 à 21, caractérisé en ce que la visibilité de chaque recherche peut être précisée par une liste de terminaux individuellement exclus , auxquels cette recherche n'est jamais communiquée automatiquement et par une liste de terminaux individuellement autorisés qui peuvent automatiquement recevoir cette recherche. 23 Procédé selon l'une quelconque des revendications 1 à 22, caractérisé en ce qu'il comporte une étape (1415, 1465) d'identification de terminaux d'une liste dite noire , aucune information n'étant communiquée aux dits terminaux de la liste noire. 24 Procédé selon l'une quelconque des revendications 1 à 23, caractérisé en ce que, au cours de l'étape (1420, 1470) de communication depuis la terminal émetteur à destination du terminal destinataire, on effectue un horodatage de la communication dans le terminal émetteur. Procédé selon l'une quelconque des revendications 1 à 24, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche. 26 Procédé selon l'une quelconque des revendications 1 à 25, caractérisé en ce que, au cours de l'étape (1410, 1460) de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche pour chaque niveau de visibilité, afin de conserver la date et l'heure de la dernière modification affectant les informations visibles audit niveau. 27 Procédé selon la revendication 24 en combinaison avec l'une quelconque des revendications 25 ou 26, caractérisé en ce que, au cours de l'étape de communication (1420, 1470) depuis la terminal émetteur à destination du terminal destinataire, on détermine si un terminal destinataire a reçu l'ensemble des recherches qu'il peut recevoir en comparant l'horodatage de la précédente communication avec ledit terminal destinataire à l'horodatage de la dernière édition de chaque recherche ayant affecté les informations visibles par ledit terminal. 28 Procédé selon la revendication 27, caractérisé en ce que, au cours de l'étape de communication (1420, 1470) depuis le terminal émetteur à destination du terminal destinataire, on communique au terminal destinataire seulement les recherches dont la dernière version ne lui a pas encore été communiquée.