FR2928799A1 - Service d'adresse indirecte de connexion sur reseau etendu - Google Patents

Abstract

Serveur d''adresse réseau indirecte comprenant un stockage (144) de correspondances entre des appels d'adresse et des adresses réseau, un service de fourniture d'adresse (142) , agencé pour répondre à la présentation d'un appel d'adresse en restituant une adresse réseau qui lui correspond, et une gestion de comptes d'utilisateurs (112), le stockage (144) de correspondances entre des appels d'adresse et des adresses réseau comprenant des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur muni d'un compte selon une règle de nommage prédéterminée, tandis que les adresses réseau sont des adresses indirectes, le service de fourniture d'adresse (142) étant agencé pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse indirecte réseau qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée.

Description

yoogetl.frd.doc 1 Service d'adresse indirecte de connexion sur réseau étendu

L'invention concerne le domaine de l'informatique sur réseaux étendus.

Les postes informatiques actuels possèdent en interne une capacité de stockage de données considérable, typiquement la centaine de giga-octets, ou plus. Il est déjà difficile de s'y retrouver, même avec une structure bien choisie de répertoires. Lorsqu'il est relié à un réseau étendu, comme Internet, un tel poste a potentiellement accès à une quantité d'informations augmentée presque à l'infini, et dont l'organisation lui échappe.

Différentes solutions sont mises en oeuvre pour tenter de faciliter la vie à l'usager. Mais elles ne donnent pas entière satisfaction.

La présente invention vient améliorer la situation.

Elle propose d'abord un serveur d'adresse réseau, qui comprend un stockage de correspondances entre des appels d'adresse et des adresses réseau, et un service de fourniture d'adresse, agencé pour répondre à la présentation d'un appel d'adresse en restituant l'adresse réseau qui lui correspond.

Selon un aspect de l'invention, le serveur d'adresse réseau comprend une gestion de comptes utilisateurs. Le stockage de correspondances entre des appels d'adresse et des adresses réseau comprend des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur selon une règle de nommage prédéterminée. De leur côté, les adresses réseau sont des adresses indirectes réseau (nom de domaine, ou plus généralement URL). Et le service de fourniture d'adresse est agencé pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse indirecte réseau qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée.

Selon un autre aspect de l'invention, il est proposé un poste informatique utilisateur, comprenant un navigateur, et qui comprend en outre un mécanisme capable d'établir une connexion vers un serveur d'adresse indirecte réseau, tel que défini ci-dessus. La connexion. peut comporter un paramètre comprenant un appel d'adresse sous forme d'un multiplet ci'un format prédéterminé. Sur retour confirmé, ledit mécanisme actionne le navigateur avec une partie au moins des données de retour en tant qu'adresse réseau. Par exemple, les données de retour peuvent comporter plusieurs adresses réseau, dont l'une sera choisie par l'usager.

Selon d'autres aspects de l'invention, celle-ci s'exprime sous forme de procédé.

Dans l'une des formes de procédé, il est proposé notamment un procédé d'aide à la navigation informatique, dans lequel on prévoit un serveur muni d'un stockage de correspondances entre des appels d'adresse et des adresses réseau, et d'un service de fourniture d'adresse, agencé pour répondre à la présentation d'un appel d'adresse en restituant une adresse réseau qui lui correspond. Et ce serveur est interrogé afin d'atteindre un emplacement réseau.

Ce procédé est remarquable en ce qu'il comprend les étapes suivantes : a. maintenir sur le serveur une gestion de comptes utilisateurs, b. stocker sur le serveur des correspondances entre des appels d'adresse et des adresses indirectes réseau, comprenant des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur selon une règle de nommage prédéterminée, c. agencer le service de fourniture d'adresse pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse indirecte réseau qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée, et d. munir au moins un poste utilisateur d'un mécanisme capable d'établir une connexion vers ledit serveur, la connexion permettant un appel d'adresse sous forme d'un multiplet au format prédéterminé, et, sur retour confirmé, d'actionner

3 le navigateur avec les données de retour en tant qu'adresse indirecte réseau.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit, et des dessins annexés, sur lesquels: la figure 1 est le schéma par blocs de la structure informatique de base à laquelle peut s'appliquer l'invention, la figure 2 est le schéma par blocs détaillé d'un mode de réalisation de l'invention, la figure 3 est un diagramme de flux illustrant de façon générale la création de comptes et de données d'adressage stockées dans un serveur selon la figure 2, la figure 4 est un diagramme de flux illustrant de façon générale l'utilisation des données d'adressage stockées dans un poste utilisateur selon la figure 2, la figure 5 est un diagramme de flux illustrant de façon plus détaillée la création/modification de données d'adressage, la figure 6 est un schéma illustrant l'offre à un utilisateur de différents modes d'appel des données d'adressage, et les figures 7 à 9 sont des diagrammes de flux illustrant ces différents modes d'appel des données d'adressage.

Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère 20 certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.

En outre, la description détaillée est augmentée des annexes suivantes: -L'annexe A comprend des tables définissant un exemple de structures de données selon la 25 présente invention.

Ces Annexes sont mises à part dans un but de clarification, et pour faciliter les renvois. Elles sont parties intégrante de la description, et pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. Ceci 30 s'applique également en tous points aux dessins. Il est maintenant fait référence à la figure 1, qui décrit la structure générale d'un système 4 où les dispositifs et le procédé selon la présente invention peuvent s'appliquer.

Dans la présente description, l'acronyme SMUB (pour Smart Multi-Usage Bookmark) désigne une chaîne de caractères obéissant à un format prédéterminé choisi, qui, dans le 5 mode de réalisation préférentiel, est du type <motl>/<mot2>.

On sait que sur un réseau étendu tel qu'Internet, il existe des adresses physiques, ou adresses IP, qui sont peu parlantes, donc rarement utilisées directement. On préfère utiliser les URL ("Uniform Resource Locator"), qui peuvent être vues comme une adresse 10 indirecte, permettant de retrouver l'adresse physique, à travers ce que l'on appelle un serveur de nom de domaine (DNS). De même, dans un poste informatique, on utilise peu ou pas l'adressage direct d'un disque ou autre support de mémoire ; on utilise plutôt des répertoires, qui sont aussi une forme d'adressage indirect. Il en est encore de même dans un réseau local. La présente demande concerne ce type d'adressage indirect, qui, quoique 15 plus parlant que les adresses directes, devient très vite hermétique et/ou difficile à gérer lui aussi.

Parmi les outils disponibles, on connaît les "favoris" ou "raccourcis". Ils sont simples d'utilisation. Mais le problème se reporte alors sur la gestion et l'organisation des raccourcis. 20 De plus, un utilisateur d'informatique nomade devra recopier ses raccourcis sur les différents postes qu'il utilise. L'usage des "favoris" ou "raccourcis" n'est donc pas véritablement satisfaisant.

D'où le succès des moteurs de recherche, dont les versions récentes opèrent aussi bien à 25 l'intérieur du poste local que sur le réseau étendu. Ils ont également des inconvénients. Tout d'abord, l'indexation intégrale des données stockées sur le poste local consomme des ressources considérables, tant en stockage qu'en capacité de traitement. De plus, une fois que l'on a trouvé l'emplacement des données recherchées, il faut recourir à un raccourci ou favori, si l'on ne veut pas recommencer la même recherche la prochaine fois. On retrouve 30 alors les inconvénients d'organisation des raccourcis, et aussi celui de leur caractère local. WO2008/006999 propose un moyen d'organiser l'indexation en fonction des contenus de documents. Mais cela, non plus, n'est pas entièrement satisfaisant dans tous les cas. On verra ci-après différentes propositions pour améliorer les choses.

Dans la suite, par "adresse indirecte sur le réseau étendu" ou plus brièvement "adresse 5 indirecte", on entend a priori une adresse de type URL. Mais l'invention peut s'appliquer aussi à une adresse dans un poste informatique ou dans un réseau local accessible à un poste informatique.

A droite de la figure 1, un poste serveur 100 est constitué d'une interface web 102, qui permet des échanges de données sur un réseau étendu (web) avec un module de création des SMUBs par compte (référencé 120) et un module d'utilisation des SMUBs référencé 140.

Au niveau d'un poste utilisateur 200, il est posé également une interface web 202, qui permet au module de création de SMUBs côté utilisateur, référencé 210, d'interagir par l'intermédiaire du réseau étendu avec le module 120 du serveur 100. De même, un module d'appel de SMUBs 220 peut interagir avec le module 140 du serveur 100. Enfin, on peut prévoir un poste tiers 300, également muni d'une interface réseau 302, qui permet à un module d'appel de SMUBs 350 de coopérer avec le module 140 du serveur 100. On verra que cette coopération est un peu différente de celle du module d'appel 220 d'un poste utilisateur.

La même structure se retrouve sur la figure 2, mais de manière plus détaillée, correspondant à un mode de réalisation particulier de l'invention. Le module de création 120 de la figure 1 peut être considéré comme comprenant les modules 112 à 126 de la figure 2.

Le module 140 de la figure 1 peut être considéré comme comprenant les modules 142 et 30 152 de la figure 2.

Si l'on se tourne maintenant vers le poste utilisateur 200, la figure 2 fait apparaître un

6 navigateur. 212, ou autre fonction de communication, capable de coopérer avec le module 112 du serveur, pour exécuter la création d'un compte, dont les données de gestion sont dans une mémoire 114.

Cette création de compte peut se faire de manière classique, adaptée comme on le verra plus loin.

Le navigateur peut également interagir avec une fonction de création d'un SMUB dit "internet", par opposition à la création d'un SMUB "local" qui est la fonction 222 du 10 poste utilisateur.

La fonction 122 du serveur 100 va d'abord interagir avec une fonction de contrôle de l'existence d'un compte au profit de l'utilisateur qui demande la création. Cette fonction est référencée 124. C'est seulement après ce contrôle que l'on pourra procéder à la 15 création des données du SMUB proprement dites, dans le bloc 126.

Les données du SMUB sont stockées dans une mémoire 134, qui coopère avec une gestion de mots clés 136, optionnelle.

20 Si l'on revient maintenant au poste utilisateur 200, il est également possible d'y créer des SMUBs locaux, par une fonction de création 222 qui est semblable à la fonction 126 du serveur, mais se trouve confinée à la désignation d'emplacements ou répertoires situés à l'intérieur du poste utilisateur.

25 Ces données locales sont stockées dans la mémoire 244, et pourront faire l'objet d'un appel de SMUB local en 242.

Lorsqu'un poste utilisateur a créé des données SMUB internet, il peut les répliquer par la fonction 132 dans la mémoire des données locales 244. Ceci évite d'appeler le serveur 30 pour avoir les fonctions en question. Les données qui sont ainsi répliquées sur le poste utilisateur 200 sont celles qui sont propres à un ou des comptes attribués aux postes utilisateurs 200.

Le poste utilisateur 200 peut également chercher à accéder à d'autres SMUBs créés par d'autres postes utilisateurs. Dans ce cas, le module d'appel 242, après avoir vérifié qu'il ne s'agit pas d'un SMUB local, interrogera l'utilisation au niveau du serveur SMUB internet 142. S'agissant d'un poste utilisateur ayant un ou des comptes ouverts, le serveur 142 peut lui faire accéder à tous les SMUBs, sous réserve de conditions que l'on verra plus loin.

Un SMUB peut être défini par son créateur comme public. Dans ce cas, n'importe quel poste tiers 300 pourra, à partir de son navigateur 312, procéder à un appel de SMUBs par la fonction 352, qui accède alors au serveur de SMUBs publics 152, lequel interroge le sous-ensemble des données SMUB stockées en 144 qui correspond à des SMUBs publics.

Les Tables 1 à 4 de l'annexe A donnent un exemple particulier de réalisation de l'invention. Dans ces tables, les données à caractère personnel sont fantaisistes, et ne visent pas à correspondre à des données réelles. C'est le cas notamment pour les adresses courriel, et les URL.

La Table 1 définit 3 utilisateurs ou acteurs différents, distingués par des adresses courriel différentes dans la colonne U email. Un même acteur, par exemple a@b.com peut avoir trois alias distincts (également nommés nom courts, ou pseudo), par exemple "Jean", "Mickey" et "Jdupont", comme indiqué dans la colonne U shortName. Certains au moins de ces alias peuvent avoir un nom long, comme indiqué dans la colonne U longName. Un mot de passe de gestion du compte et des SMUBS est stocké dans la colonne U PW. Enfin, chaque ligne possède un identifiant interne dans la colonne Int id.

Suivant un choix de configuration du serveur, on peut prévoir : - soit que le mot de passe est associé à un compte utilisateur, et reste le même pour les différents alias de celui-ci, - soit que chaque alias est associé à un mot de passe qui lui est propre, et qu'il n'y a pas de mot de passe associé au compte utilisateur, - soit encore qu'il existe à la fois un mot de passe compte associé à un compte

8 utilisateur, et, en plus, un autre mot de passe pour chaque alias, avec des privilèges différents. Par exemple, le mot de passe alias permet de gérer des SMUBS associés à l'alias, mais pas ceux des autres alias. Ceci peut convenir par exemple, lorsque des personnes d'une même famille partagent la même adresse courriel.

La Table 2 est maintenant considérée. Chaque ligne possède un identifiant interne dans la colonne O _id. Cette table 2 définit la correspondance entre un SMUB, déterminé par les colonnes L! shortName et suffix, et une adresse sur le réseau étendu, ou bien sur un lecteur interne (voire externe) du poste de l'utilisateur, définie dans la colonne URL, laquelle est assortie d'une colonne d'identifiants URLid. On prévoit très avantageusement une colonne, notée Uj,riv, pour une indication de niveau, et/ou une colonne d'intitulé, notée Tite.

On voit par exemple que, sous ses trois alias différents de la Table 1, l'utilisateur dont l'adresse courriel est a(a,b.com dans la Table 1 possède en tout 6 lignes de SMUBs dans la table 2. La seconde Oid2 permet de pointer sur son disque dur interne (C:). La dernière Oid6 permet de pointer sur une adresse courriel. Les autres visent des emplacements ou adresses indirectes sur le réseau étendu, ici Internet. L'homme du métier comprendra pour le reste la structure de la Table 2, dont le fait que le premier chiffre de l'identifiant d'URL URLid est spécifique de l'alias concerné U ShortName.

Comme l'illustre aussi la table 2, le même SMUB ( Jean/Paris ) peut viser plusieurs URL différentes. L'appel de ce SMUB se produira alors par l'affichage des différentes URL pour choix, par exemple en liste ou tableau.

La Table 3 est maintenant considérée. Chaque ligne possède un identifiant interne dans la colonne KW id. La colonne KW contient des mots-clés tirés ici de la colonne d'intitulé Title de la Table 2. La colonne Oid contient, ici sous forme de liste, les identifiants des lignes de la table 2 dont l'intitulé contient le mot-clé de la ligne. Pour simplifier, la Table 3 ne comprend que quelques uns des mots clés de la Table 2. Les mots non discriminants, comme "My" ou "to" dans "My trip to Paris", peuvent être ignorés. Par ailleurs, certains mots peuvent être interprétés, comme "Yellow pages", converti en "Directory".

9 Réciproquement, une conversion en "Directory", pourra être faite sur présentation de "Yellow Pages" comme mot-clé pluri-terme (si un mot-clé pluri-terme est admis), ou encore sur présentation de "Yellow" et "pages" comme deux mots-clés uni-termes (un seul mot à la fois). Les motsûclés ne sont pas nécessairement stockés dans le titre. Ils peuvent être stockés directement au niveau de la Table 3, en correspondance de l'Oid du SMUB en cours.

De préférence, on laisse l'utilisateur saisir ses propres mots clés, notamment au vu du titre. 10 Cela fournit une indexation humaine des contenus des URL, qui est beaucoup plus précise et fiable qu'un système d'indexation automatique, statistiquement du moins. Si l'utilisateur ne saisit pas spontanément de mot-clé, on peut prévoir que le système propose un titre tiré de l'URL, et des mots clés tirés de ce titre, que l'utilisateur valide, après les avoir éventuellement modifiés. 15 Il est maintenant fait référence à la Table 4. Les colonnes Int id owner et Int id links désignent des alias, par leur identifiant Int id dans la table 1. Bien entendu, la présentation de la Table 4 n'est qu'un exemple, et l'on pourrait concevoir le contenu des cases Int id links comme une liste de valeurs Uid. 20 Dans la Table 5, la colonne Int id links a le même sens que dans la Table 4, mais ici sous la forme d'une liste, et la colonne Oid désigne un SMUB auquel l'utilisateur de la colonne lnt id links peut accéder. Ici : - les Oid de la Table 5 doivent correspondre à des SMUBs de niveau 1 (sphère privée) dans 25 la Table 2, et - un utilisateur présent dans la colonne Int id links de la Table 5 en regard d'un Oid doit être également présent dans la table 4 en regard du propriétaire (créateur) du SMUB qui correspond à cette Oid.

30 Il est maintenant fait référence au diagramme de flux de la figure 3. Celui-ci représente la fonction ouvrir un compte , notée 410. Pour cela, il convient d'abord d'aller sur le site du serveur, comme indiqué par l'opération 412. Le serveur est noté ici http://smub.com.5 L'opération suivante 414 consiste à ouvrir un compte personnel. Il est actuellement préféré que l'identifiant personnel soit l'adresse courriel (e-mail) de l'utilisateur, selon la table 1.

L'utilisateur peut alors créer un ou plusieurs alias, sur la base de ce compte personnel, comme indiqué pour l'opération 415. On pourra désigner dans la suite un alias (et par conséquent un utilisateur), par son identifiant dans la table 1, par exemple Uidl .

L'opération 416 permet alors au créateur d'un alias de saisir les alias de tiers qui font partie de sa sphère privée. L'utilisateur créateur doit saisir un alias de tiers. Le système en vérifie l'existenceä puis crée une ligne dans la table 4 (par exemple la première) avec en Int id owner l'identifiant Uidl de l'alias concerné de l'utilisateur créateur, et en colonne Int id links l'identifiant Uid4 de l'alias du tiers. Ainsi, un autre utilisateur qui s'est donné l'alias Uid4 se trouve inclus dans la sphère privée de l'utilisateur qui s'est donné l'alias Uidl.

Cela suppose que l'autre utilisateur Uid4 a communiqué son alias à l'utilisateur Uidl. Cela se fait en principe par communication personnelle directe ou indirecte. Toutefois, on peut aussi prévoir dans le système un mécanisme d'extension de la sphère privée, par exemple sur la base du principe "un ami d'un ami peut devenir un ami". On suppose qu'un alias utilisateur Uid9 (non représenté dans la table 1) fait partie de la sphère privée de l'alias utilisateur Uid4. Comme Uid4 fait lui-même partie de la sphère privée de Uidl, Uid9 peut s'en prévaloir pour demander à Uidl de faire partie de sa propre sphère privée. Pour cela, on peut communiquer à Uid9 l'adresse courriel de Uidl (exclusivement) ; de préférence, la requête de Uid9 est enregistrée par le système, qui se charge lui-même de poser la question à Uidl, et d'inclure Uid9 dans la sphère privée de Uidl en cas de réponse positive. Cette fonction de mise en relation, connue, n'est pas représentée.

Pour chaque alias, l'utilisateur créateur pourra créer également un ou plusieurs jeux de données SMUB (voir Table 2). Cela se fait de préférence à partir des favoris du poste, comme indiqué à l'opération 417. On peut par exemple rapatrier tous les favoris, et proposer, pour un ou des alias U ShortName, d'utiliser l'URL du favori comme champ URL, une proposition (modifiable) tirée du nom du favori comme champ Suffix, et le nom du favori (modifiable) comme champ Tite. Les champs identifiants Oid et URLid sont créés comme à l'accoutumée, par incrémentation automatique par exemple.

Avant la fin 420, optionnellement, l'opération 418 consiste à dupliquer les données SMUB distantes, présentes sur le serveur, vers le poste local.

La figure 4 illustre la fonction utilisation d'un SMUB. On se place dans le cas de la figure 2, où il existe une réplication locale des données SMUB. À l'opération 452, la fonction 242 interroge la mémoire SMUB locale 244, et celle-ci retourne une adresse indirecte réseau (ou URL) cible, si les conditions du SMUB sont vérifiées. Si tel est le cas, l'URL cible est retournée au navigateur par l'opération 454, et c'est terminé en 460. S'il y a plusieurs URL pour le même SMUB (voir Jean/Paris dans la Table 2), alors un choix est proposé à l'utilisateur.

Si l'opération 452 a été un échec, il y a alors appel du site distant 456 avec une requête relative au SMUB désiré. (C'est en principe un SMUB créé par un autre utilisateur.). Là aussi, en 458, on peut recevoir une URL cible, auquel cas, on continue en 454 comme précédemment. Sinon, on procède en 462 un traitement d'erreur approprié.

La figure 5 est le diagramme de flux de la création/modification d'un SMUB. L'opération d'entrée 510 rappelle qu'il s'agit de créer/modifier un SMUB. Ensuite, l'opération 512 consiste à aller sur le site du serveur, noté par convenance http://smub.com. L'opération 514 consiste à se connecter au compte personnel sur le site, si ce n'est pas déjà fait. Ensuite, l'opération 520 permet de choisir l'un des alias du compte personnel auquel l'utilisateur s'est connecté. 30 Le test 530 permet de choisir entre la création d'un nouveau SMUB ou la modification d'un SMUB existant.25 S'il s'agit de créer un nouveau SMUB, l'opération 532 consiste en la désignation par l'utilisateur d'une URL vraie, c'est-à-dire d'une adresse indirecte étendue existant (ou présumée exister) sur le réseau étendu, ou bien d'une adresse sur son poste de travail.

Par contre, ici, la modification d'un SMUB ne permettra que de modifier son URL à l'opération 533, et/ou son suffixe à l'opération 536 décrite ci-après.

Par défaut, et dans un mode de réalisation particulier, la structure du SMUB créé répond à un format prédéterminé qui comprend deux mots, notés génériquement <motl> et <mot2>, respectivement, avec un séparatif prédéfmi (ici "/") entre ces deux mots. Ce format peut donc s'écrire : <motl>/<mot2> On note génériquement <U_alias> un alias d'utilisateur. Un appel d'adresse est valide s'il est de la forme < U alias >/<mot2>

Dans la suite du diagramme de la Figure 5, on prévoit de préférence une opération 534 par laquelle le système propose, pour <mot2>, un suffixe par défaut pour compléter l'alias qui forme la première partie du SMUB, et vérifiant la condition d'unicité du SMUB. En 536, l'utilisateur peut décider d'ajuster le suffixe, auquel cas le test 538 vérifie que l'ensemble <U alias> et <suffixe> est unique. Si cela n'est pas, l'ajustement de suffixe est poursuivi en 539 jusqu'à satisfaction de la condition d'unicité.

25 Le SMUB en lui-même est alors complètement défmi.

Ensuite sont prévues des opérations optionnelles (individuellement) : -Opération 540, ce qui permet de définir un titre pour le couple alias + suffixe formant le SMUB, 30 - l'opération 545 permet de définir des mots-clés descriptifs associés à l'URL réel visé par le SMUB, ou bien à l'idée qu'en a l'utilisateur, - l'opération 550 permet de définir un niveau. Dans le mode de réalisation décrit sont prévus20 trois niveaux : personnel, privé et public.

Ensuite, l'opération 555 consiste à construire l'URL SMUB = <alias>/<suffixe>, de sorte qu'elle soit directement accessible sur le site par une phrase d'interrogation qui pourrait 5 être du genre : http://SMUB.com /<U_alias>/<suffixe>

Dans une variante intéressante, il est ajouté une ou des fonctions additionnelles aux fonctions naturelles du navigateur. Un exemple de fonction additionnelle consiste à créer 10 un SMUB à partir d'une URL en cours dans le navigateur. Cette fonction est activée (ou visible), par exemple sous la forme d'un bouton poussoir à l'écran, si l'utilisateur est déjà connecté à son compte personnel sur le site SMUB, avec l'un des alias de ce compte personnel. Dans ce cas, par rapport à la figure 5, l'actionnement du bouton poussoir permet de sauter directement à l'opération 534 de définition du SMUB. On peut concevoir d'autres 15 fonctions, ou des variantes, comme inscrire l'URL en cours du navigateur comme SMUB sur un ou plusieurs des alias du compte encours, après choix dans une liste d'alias.

En bref, dans l'exemple décrit, le format générique d'un SMUB est <motl>/<mot2> 20 On note génériquement <U alias> un alias existant d'utilisateur, et <suffixe> un suffixe existant pour cet alias. Un appel d'adresse est valide s'il est de la forme < U alias >/<suffixe> tandis que U_alias > est contenu dans les colonnes U ShortName des tables 1 et 2, et <suffixe> est contenu dans la colonne Suffix de la table 2 en regard de < U alias > dans la 25 colonne U ShortName.

Ainsi, l'appel d'adresse par SMUB est accepté après vérification d'une première condition, qui implique l'une au moins des sous-conditions suivantes : a. le respect de la règle de nommage, ici la forme <motl>/<mot2>, 30 b. le fait que <mot1> soit un alias d'utilisateur enregistré < U alias >, figurant en colonne U ShortName dans la table 1 et/ou la table 2, et c. le fait que <mot2> soit un <suffixe> figurant en colonne Suffix en regard de 13 <U alias> dans la colonne U ShortName dans la table 2.

La première condition peut s'arrêter là pour les SMUBs classés publics (dans l'exemple, de niveau 0 dans la table 3). Elle est plus sévère pour les autres niveaux, puisqu'il s'y ajoute une ou des sous-conditions supplémentaires liées au niveau. On peut utiliser par exemple le fait que l'utilisateur qui appelle le SMUB ait ouvert une "session SMUB" sur le serveur, ce qui l'identifie. Dans ce cas : - dans l'exemple décrit, un SMUB privé (niveau 1) n'est accessible que si l'alias appelant possède un Uid qui figure dans la table 4 en regard de l'Uid du créateur du SMUB, et si, dans la Table 5, l'Uid de ce même appelant figure en regard de l'Oid du SMUB considéré.

- un SMUB personnel (niveau 2) n'est accessible que si l'appelant est celui qui a créé le SMUB. Le fonctionnement dépend ici du mode d'utilisation des mots de passe dans la table 1. S'il n'y a qu'un seul mot de passe pour un utilisateur donné, quel que soit son alias, alors le SMUB personnel est accessible à l'utilisateur, quel que soit son alias. Si au contraire on prévoit un mot de passe différent pour chaque alias d'un même utilisateur, et que ce mot de passe d'alias est demandé à l'ouverture de la "session SMUB", alors on peut prévoir qu'un SMUB personnel n'est accessible qu'à un seul alias d'utilisateur.

On notera que l'ouverture de session n'est pas nécessaire lors d'un appel de SMUB 242 en mode local, puisque l'utilisateur est généralement connu par le système d'exploitation du poste local.

Il est maintenant fait référence à la figure 6, qui illustre sur un exemple les possibilités offertes à un utilisateur accédant au serveur http://SMUB.com.

À l'accès au serveur 600, l'utilisateur entrant peut ouvrir une session en 602, s'il dispose d'un compte. Si aucune session n'est ouverte (604), l'utilisateur entrant n'a qu'un accès restreint aux SMUBS publics (base de données 152 sur la figure 2). Si une session est ouverte (608), l'utilisateur entrant a potentiellement accès à tous les SMUBs (base de données 142 sur la figure 2), sous réserve des conditions applicables aux SMUBs privés et personnels.

15 Ensuite, un écran lui est offert avec trois possibilités : en 612, désigner directement un SMUB, en tant que requête dans la base de données concernée, en 622, faire une recherche par mots clés, dans la base de données concernée, en 642, faire une recherche par alias (par exemple), dans la base de données concernée.

En pratique, l'ouverture de session pourra être incluse comme une option dans l'écran qui vient d'être défini, le mode par défaut (sans session ouverte) étant l'accès aux seuls SMUBs publics. On peut aussi inclure dans cet écran d'autres fonctions, notamment des fonctions déjà décrites, comme l'ouverture d'un compte, et/ou la gestion des SMUBs d'un compte déjà ouvert, ou d'autres fonction de requête ou de recherche que celles ici décrites.

Il est maintenant fait référence à la figure 7 qui illustre le diagramme de flux de l'utilisation directe 612 d'un SMUB. L'opération 614 consiste à vérifier la forme du SMUB, pour le découper afin d'interroger correctement la Table 2. Cette vérification de forme peut être directement associée à la zone de saisie du SMUB dans la requête 612 de la figure 6.

Ensuite, il est procédé en 616 à une recherche dans la table 2, pour déterminer s'il existe le couple <motl>, <mot2> avec une URL en correspondance. Si oui, alors on retourne l'URL cible ainsi trouvée à l'opération 664. Sinon, c'est un échec 618, sur lequel on peut par exemple offrir à nouveau l'écran de saisie de la figure 6. On notera ici que l'opération 614 n'est pas absolument impérative, puisqu'une requête SMUB incorrecte se traduira en principe par un échec.

Sur la figure 6, l'appel 600 peut être accompagné d'un SMUB comme paramètre, auquel cas on passe directement à l'exécution de la requête correspondante de la Figure 7. Il est maintenant fait référence à la figure 8 qui illustre le diagramme de flux de la recherche par mots clés 622.30 L'opération 624 recherche dans la table 3 selon le ou les mots- clés choisis par l'utilisateur. Par exemple, le seul mot-clé "Paris" donne la liste "Oidl, Oid2, Oid3" dans la Table 3. Mais si l'on prend (par exemple avec un séparatif, ou une zone de saisie multiple) les deux mots-clés "Paris" et "Hotel", il ne reste alors, par croisement, que "Oidl".

On admet qu'en 625, il est trouvé un ou plusieurs identifiants de SMUB ( Oid ) dans la table 3. Alors, l'opération 626 va chercher dans la table 2 la ou les URL correspondant à ce ou ces Oid , et propose cette ou ces URL comme choix à l'utilisateur. Cela peut se faire par un tableau, dont chaque ligne indique l'URL trouvée. Le tableau peut comporter une ou des colonnes supplémentaires, pour donner des informations additionnelles, comme ceux des mots-clés qui correspondent à l'Oid de l'URL de la ligne, ou encore le SMUB et/ou le titre correspondant à cet Oid dans la table 2, ou le nom long correspondant à la partie alias du SMUB dans la table 1.

Si, en 627, l'utilisateur accepte l'une des URL proposées, alors on retourne l'URL cible sélectionnée à l'opération 664.

Si l'utilisateur refuse en 627, on va en échec 628. On va de même en échec (au besoin avec 20 un message approprié) si rien n'a été trouvé à l'opération 625. Sur un échec, on peut par exemple off ir à nouveau l'écran de saisie de la figure 6, comme précédemment.

Il est maintenant fait référence à la figure 9 qui illustre le diagramme de flux de la recherche 642 par alias. 25 L'opération 644 recherche s'il existe un ou des alias vérifiant la condition de recherche (par exemple le début de l'alias) dans la table 1. Si oui, l'opération 646 proposer le ou les SMUB déjà défmis et correspondant à cet/ces alias dans la table 2. Si, en 647, l'utilisateur accepte le SMUB proposé (l'un des SMUBs proposés s'il y en a plusieurs), alors on retourne l'URL 30 cible correspondante à l'opération 664. S'il y a plusieurs SMUBs proposés, il peuvent être présentés en tableau, avec une ou plusieurs colonnes supplémentaires pour présenter des informations additionnelles, par exemple, s'il existe, le nom long correspondant à chaque alias dans la table 1.

Le même genre de recherche peut être fait sur d'autres éléments contenus dans les tables, par exemple le nom long. Dans ce cas, l'opération 644 recherche s'il existe un ou des alias vérifiant une condition de recherche sur un élément, par exemple un fragment, d'un nom long d'utilisateur. A cet égard, on notera dans la Table 1 que le nom long "Jean Dupont" permet d'accéder à l'alias "Jean", lequel permet (optionnellement) d'accéder à l'alias "Mickey", bien que ce dernier ne soit pas associé au nom long "Jean Dupont". On peut choisir par construction de ne proposer que les alias qui ont effectivement associés au nom long, ou au contraire de proposer tous les alias, qu'ils soient ou non associés au nom long recherché (cette dernière option peut être réservée aux usagers demandeurs qui ont accès à la sphère privée de l'utilisateur ayant le nom long).

Si l'utilisateur refuse en 647, on va en échec 648. On va de même en échec (au besoin avec 15 un message approprié) si rien n'a été trouvé à l'opération 644. Sur un échec, on peut par exemple offrir à nouveau l'écran de saisie de la figure 6, comme précédemment.

Comme le comprendra l'homme du métier, l'écran défini à propos de la figure 6 peut être conçu comme un formulaire événementiel, qui présente trois zones de saisie pour les 20 opérations 612, 622 et 642, respectivement, et éventuellement d'autres zone ou boutons pour les autres fonctions mentionnées. L'usager remplit celle des zones pour laquelle il entend rechercher un SMUB, et cette saisie déclenche l'opération correspondante. Cependant, si un SMUB arrive au départ comme paramètre, on peut lancer directement la recherche en 612.

25 Bien entendu, on peut aussi croiser des conditions de recherche, par exemple croiser une recherche par alias avec une recherche par mots-clés.

L'invention n'est pas limitée aux modes de réalisation ci-dessus décrits mais en embrasse toutes les variantes contenues dans le cadre des revendications ci-après, notamment les 30 suivantes : a. le format générique d'un SMUB étant du genre <motl>/<mot2>, ou semblable, on peut aussi ajouter des contraintes sur la longueur de <mot 1> et/ou <mot2> ; 17 b. on pourrait se passer du séparatif (la barre oblique) dans certains cas, par exemple si <mot1> est de longueur fixe, ou bien si <mot2> commence par une majuscule, tout le reste étant en minuscules. c. Les exemples de tables donnés sont illustratifs ; il est possible de découper certaines au moins des tables, par exemple en stockant à part les URL, associées à leur identifiant URL id. Il est également possible de les regrouper au moins partiellement, quitte à créer une certaine redondance. d. La condition d'unicité des SMUBs n'est pas absolument impérative. On pourrait admettre des doublons, dès lors que ceux-ci sont signalés, et/ou que le créateur de doublons puisse lever cette ambiguïté.

Des règles particulières peuvent être définies. Par exemple, on peut prévoir que <mot2> est nécessairement une chaîne de caractères ne comprenant pas le séparatif prédéfini ("/"), ou même ne comprenant que des lettres et des chiffres, tandis que <mot1> peut être une chaîne de caractères quelconque, qui peut même comprendre le séparatif prédéfmi (ici la barre oblique "/"). Dans ce cas, on peut distinguer <mot1> et <mot2>, et les séparer l'un de l'autre, en faisant une recherche de / à partir de la droite dans la chaîne de caractères complète du SMUB qui est de la forme <motl>/<mot2>.

Ceci peut permettre notamment de faciliter la création d'alias aux nombreux utilisateurs potentiels prénommés "Jean", en incorporant une partie de leur nom de famille dans l'alias. On peut alors distinguer par exemple les alias "Dup/jean" et "Pla/jean".

Les exemples donnés pour la première condition , ses sous-conditions, ainsi que les conditions additionnelles liées aux niveaux sont illustratifs et non limitatifs. On pourra naturellement construire différemment des conditions équivalentes, et en éliminer les éventuelles redondances.

De même, le nombre de niveaux, et les sous-conditions associées à chacun des niveaux (autres que public ) ne sont pas limitatives. On pourrait, dans certains cas du moins, définir la sphère privée (au moins partiellement) non pas par ceux qui y sont inclus, mais par ceux qui en sont exclus. La même remarque s'applique aux SMUBs de la sphère privée.

Dans ce qui précède, un "alias" est supposé non modifiable. On peut seulement le détruire, le cas échéant. Une variante consisterait à autoriser la modification d'un alias. Cela impliquerait soit de modifier en conséquence tous les SMUBs qui découlent de l'alias modifié (au besoin en conservant temporairement les SMUBs composés avec l'ancien alias), ou encore de supprimer tous les SMUBs qui découlent de l'alias, en forçant ainsi leur recréation à volonté.

Par ailleurs, d'autres formes de procédés selon l'invention peuvent être tirées de la 10 description qui précède, notamment en liaison avec les dessins.

Bien entendu, certains des moyens décrits ci-dessus peuvent être omis dans les variantes où ils ne servent pas.

20 Table 1 rU Email U_shortName U_longName Int_id U PW a@b.com Jean Jean Dupont Uidl I Pwl e,b.com Mickey Uid2 Pwl ib.com Jdupont Jean Dupont Uid3 Pwl c n,d.com Eva Eva Durand Uid4 Pw2 c(a d.com Evita Uid5 Pw2 p@y.com Kit Pierre Martin Uid6 Pw3 Table 2 Oid U ShortName Suffix Title URLid URL U priv Oid1 Jean Paris My trip to Paris URL11 http://paristourisme.fr/info/hotels/3etoiles/hotelconfort/images/ 1 Oid2 Jean Paris My trip to Paris URL12 C:\Documents\Perso\Paris\map.pdf 2 Oid3 Jean Paris My trip to Paris URL13 http://www.parisinfo.com/musees-monuments-paris/ 0 Oid4 Mickey Myspace My page URL21 http://www.mvspace.fr/mickey 1 Oid5 Mickey Yp Yellow pages New York URL22 htt•://www. ellow•a•es.com/New-York-NY 0 Oid6 Jdupont Bob Bob email URL31 mailto:robertdurandemailbox.com 2 Oid7 Eva Fashion Elle fashion URL41 http://www.elle.com/archive.asp?section_id=4&article_id=0 0 Oid8 Evita Bank My bank account URL51 https://www.ibpl.loirelyonnais.banquepopulaire.fr/htmlcerius/ccomptes2. asp 2 Oid9 Kid Pict My hotels URL61 D:\Documents\myhotels\myhotels.doc 2 5 21 5 Table 3 KW_id KW Oid Kwidl Hotel Oidl, Oid9 Kwid2 Paris Oidl, Oid2, Oid3 Kwid3 Directory Oid5 Kwid4 New York Oid5 Table 4 lnt id owner Int id links Uidl Uid4 Uid2 Uid3 Uidl Uid6 Table 5 Oid /nt id Iinks Oidl Uid4, Uid6 Oid4 Uid310

Claims (20)

Revendications

1. Serveur d'adresse réseau indirecte, du genre comprenant : un stockage (144) de correspondances entre des appels d'adresse et des adresses réseau, et un service de fourniture d'adresse (142) , agencé pour répondre à la présentation d'un appel d'adresse en restituant une adresse réseau qui lui correspond, caractérisé en ce qu'il comprend une gestion de comptes d'utilisateurs (112), en ce que le stockage (144) de correspondances entre des appels d'adresse et des adresses réseau comprend des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur muni d'un compte selon une règle de nommage prédéterminée, tandis que les adresses réseau sont des adresses indirectes, et - en ce que le service de fourniture d'adresse (142) est agencé pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse indirecte réseau qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée.

2. Serveur d'adresse réseau selon la revendication 1, caractérisé en ce que le stockage d'un appel d'adresse (144) comprend en outre une indication de niveau, définie par l'utilisateur, et en ce que ladite première condition fait intervenir aussi l'indication de niveau.

3. Serveur d'adresse sur réseau selon l'une des revendications 1 et 2, caractérisé en ce que la gestion de comptes utilisateurs (114) est agencée de sorte que chaque compte utilisateur soit associé à au moins un alias d'utilisateur, et en ce que la règle de nommage comprend l'insertion d'un alias utilisateur en position prédéfinie dans ledit format prédéterminé.

4. Serveur d'adresse réseau selon la revendication 3, caractérisé en ce que le format prédéterminé comprend l'alias utilisateur, suivi d'un séparatif, puis d'un suffixe. 22

5. Serveur d'adresse réseau selon l'une des revendications 3 et 4, caractérisé en ce qu'il comprend un outil d'ouverture de session utilisateur, et en ce que ladite première condition fait intervenir aussi le fait que l'appel d'adresse provient d'un utilisateur qui possède une session ouverte avec habilitation au niveau voulu pour cet appel d'adresse.

6. Serveur d'adresse réseau selon l'une des revendications 3 à 5, caractérisé en ce que le stockage d'un appel d'adresse (144) comprend en outre un intitulé, défini par l'utilisateur, en ce que le serveur comprend en outre un outil de recherche par mots-clés tirés des intitulés (1:36), capable de pointer sur un ou des appels d'adresse dont l'intitulé comporte le ou les mots-clés présentés, sous réserve de vérification de la première condition, et en ce que le service de fourniture d'adresse (142 ; 152) est également agencé pour permettre la recherche par mots-clés, afin d'obtenir une adresse indirecte sur le réseau étendu.

7. Serveur d'adresse réseau selon l'une des revendications 3 à 6, caractérisé en ce que la gestion de comptes utilisateurs (114) comprend une première table comportant, pour chaque ligne, un identifiant d'utilisateur, un alias d'utilisateur, ainsi qu'une donnée de contrôle, et - ledit stockage de correspondances (144) comprend une seconde table comportant, pour chaque ligne, un alias d'utilisateur, une représentation de l'adresse d'une connexion sur le réseau étendu, ainsi qu'une indication de niveau.

8. Serveur d'adresse réseau selon la revendication 7, caractérisé en ce que le service de fourniture d'adresse (142 ; 152) est également agencé pour permettre la recherche par alias, afin d'obtenir une adresse indirecte sur le réseau étendu.

9. Poste informatique utilisateur, comprenant un navigateur (212 ; 312), caractérisé en ce qu'il comprend un mécanisme (242;352) capable d'établir une connexion vers un serveur d'adresse indirecte réseau selon l'une des revendications précédentes, la connexion comportant un paramètre comprenant un appel d'adresse sous forme d'unmultiplet d'un format prédéterminé, et, sur retour confirmé, d'actionner le navigateur (212 ; 312) avec une partie au moins des données de retour en tant qu'adresse réseau.

10. Poste informatique utilisateur selon la revendication 9, caractérisé en ce qu'il comprend une réplication locale (244) du service de fourniture d'adresses, pour les multiplets correspondant à un utilisateur du poste, cette réplication locale interrogeant le serveur d'adresse (142) pour les multiplets ne correspondant pas à un utilisateur en cours du poste.

11. Procédé d'aide à la navigation informatique, dans lequel on prévoit un serveur muni d'un stockage de correspondances entre des appels d'adresse et des adresses réseau, et d'un service de fourniture d'adresse, agencé pour répondre à la présentation d'un appel d'adresse en restituant une adresse réseau qui lui correspond, ce serveur étant interrogé afin d'atteindre un emplacement réseau, caractérisé en ce qu'il comprend les étapes suivantes : a. maintenir sur le serveur une gestion de comptes utilisateurs (114), b. stocker sur le serveur des correspondances (144) entre des appels d'adresse et des adresses indirectes réseau, comprenant des appels d'adresse stockés comme des multiplets d'un format prédéterminé, ce format comprenant un élément lié à un utilisateur selon une règle de nommage prédéterminée, c. agencer le service de fourniture d'adresse (142 ; 152) pour répondre à un appel d'adresse sous la forme d'un multiplet possédant ledit format prédéterminé en restituant l'adresse sur le réseau étendu qui correspond à ce multiplet, sous réserve de vérification d'une première condition, qui implique le lien à un utilisateur selon ladite règle de nommage prédéterminée, et d. munir au moins un poste utilisateur (200 ; 300) d'un mécanisme capable d'établir une connexion vers ledit serveur, la connexion permettant un appel d'adresse sous forme d'un multiplet au format prédéterminé, et, sur retour confirmé, d'actionner le navigateur avec les données de retour en tant qu'adresse indirecte réseau.

12.Procédé selon la revendication 11, caractérisé en ce qu'il comprend en outre l'étapesuivante : e. munir au moins un poste utilisateur d'un mécanisme (210) d'accès à un compte, capable d'interagir avec la gestion de compte utilisateurs (114) de l'étape a.

13.Procédé selon la revendication 12, caractérisé en ce qu'il comprend en outre l'étape suivante : f. munir le poste de l'étape e. d'une réplication (244) du service tel qu'agencé à l'étape c.

14.Procédé selon l'une des revendications 11 à 13, caractérisé en ce que : le stockage de l'étape b. comprend en outre, pour chaque correspondance, une indication de niveau, et la première condition de l'étape c. tient compte aussi de l'indication de niveau.

15.Procédé selon l'une des revendications 11 à 14, caractérisé en ce que la gestion de comptes utilisateurs (114) de l'étape a. est agencée de sorte que chaque compte utilisateur soit associé à au moins un alias d'utilisateur, et en ce que la règle de nommage de l'étape b. comprend l'insertion d'un alias utilisateur en position prédéfinie dans ledit format prédéterminé.

16.Procédé selon la revendication 15, caractérisé en ce que le format prédéterminé comprend l'alias utilisateur, suivi d'un séparatif, puis d'un suffixe.

17.Procédé selon l'une des revendications 11 à 16, caractérisé en ce que l'étape c. comprend une offre d'ouverture de session utilisateur (602), et en ce que ladite première condition de l'étape c. fait intervenir aussi le fait que l'appel d'adresse provient d'un utilisateur qui possède une session ouverte avec habilitation au niveau voulu pour cet appel d'adresse.

18.Procédé selon l'une des revendications 11 à 17, caractérisé en ce que le stockage d'un appel d'adresse (144) à l'étape b. comprend en outre le stockage d'un intitulé, défini par l'utilisateur, en ce que l'étape c. comprend en outre une offre de recherche par mots-cléstirés des intitulés (136), capable de pointer sur un ou des appels d'adresse dont l'intitulé comporte le ou les mots-clés présentés, sous réserve de vérification de la première condition, afin d'obtenir au moins une adresse indirecte sur le réseau étendu.

19.Procédé selon l'une des revendications 11 à 18, caractérisé en ce que la gestion de comptes utilisateurs (114) de l'étape a. comprend une première table comportant, pour chaque ligne, un identifiant d'utilisateur, un alias d'utilisateur, ainsi qu'une donnée de contrôle, et ledit stockage de correspondances (144) de l'étape b. comprend une seconde table comportant, pour chaque ligne, un alias d'utilisateur, une représentation de l'adresse d'une connexion sur le réseau étendu, ainsi qu'une indication de niveau.

20.Procédé selon la revendication 19, caractérisé en ce que l'étape c. est également 15 agencée (142 ; 152) pour permettre la recherche par alias, afin d'accéder à un ou des multiplets, permettant d'obtenir au moins une adresse indirecte sur le réseau étendu. 20 25 30 35