Brevet FR2935505A1 — publié le 20100305

YOOGET 3.FRD 1 Système informatique à serveur d'accès simplifié, et procédé correspondant. L'invention concerne le domaine de l'informatique sur réseaux étendus. Lorsqu'il est relié à un réseau étendu, comme Internet, un poste informatique actuel a potentiellement accès à une quantité d'informations augmentée presque à l'infini, et dont l'organisation lui échappe. La Demanderesse a déjà fait différentes propositions pour tenter de faciliter la vie à l'usager : FR 2 805 359 et demande de brevet français Na 08 01417, notamment. La présente invention vient améliorer encore la situation, en cherchant à simplifier l'ergonomie au maximum. L'invention concerne un système informatique, comportant un environnement hôte pour serveur. Il est muni d'un port de communication sur réseau étendu. S'y ajoute un serveur réseau, auquel est affecté une première adresse réseau ou URL d'acheminement. Ce serveur réseau comporte des applications de serveur, optionnellement comprenant une application d'abonné capable d'identifier un appelant comme utilisateur enregistré. Il est prévu un gestionnaire d'accès, qui reçoit depuis le port une expression d'appel (la requête de l'usager, débarrassée de l'équivalent de l'adresse IP affectée au port qu'elle comporte en tête). Le gestionnaire d'accès applique des règles prédéfinies à l'expression d'appel ; si une règle est vérifiée, il invoque une application de serveur qui est choisie selon l'expression d'appel et la règle qu'elle vérifie, par exemple pour fournir à l'usager ce qu'on appelle couramment une "page web". Le gestionnaire d'accès peut être prévu avec : un discriminateur, activable pour reconnaître si une expression d'appel non conforme aux règles prédéfinies, se trouve contenir un segment de type URL, et intercepter alors une telle expression, et un dérivateur capable, en cas d'expression reconnue comme de type URL, d'invoquer une application prédéfinie spécifique, avec comme paramètre ladite expression interceptée. La donnée enregistrée liée à l'utilisateur peut comprendre un identifiant de l'utilisateur, ou un pointeur d'accès à toute autre donnée liée à l'utilisateur, stockée 5 localement, ou même à distance. Selon un premier mode de réalisation, l'application prédéfinie peut comprendre la création d'une expression d'appel raccourcie en correspondance de l'expression interceptée, reconnue comme de type URL, et la mise à disposition d'un service 10 d'adressage réseau indirect, pour viser l'URL dudit segment à partir de cette expression d'appel raccourcie. Les applications de serveur peuvent comprendre une application d'abonné capable d'identifier un appelant comme utilisateur enregistré, l'application prédéfinie 15 spécifique pouvant être invoquée en présence d'au moins une donnée enregistrée liée à l'utilisateur. Selon un second mode de réalisation, l'application prédéfinie comprend la création d'une page d'envoi, au nom de l'utilisateur, d'un courriel contenant l'URL dudit 20 segment. En variante, un même système informatique peut comprendre au moins deux serveurs réseau, ayant des adresses IP différentes, et affectés à des applications prédéfinies différentes, par exemple celles du premier et du second modes de réalisation, 25 respectivement. L'invention offre également un procédé d'aide à la navigation informatique sur réseau étendu, comprenant les étapes suivantes : a. émettre depuis un poste utilisateur une requête sur le réseau étendu 30 comprenant une URL de destination, suivie d'une expression contenant une seconde URL, 2 b. dans un serveur réseau étendu, sur le port qui possède l'adresse physique correspondant à l'adresse de destination, recevoir une expression à traiter, c. déterminer si l'expression à traiter contient un segment de type URL, et d. si la détermination de l'étape c. est positive, invoquer une application 5 prédéfinie spécifique du serveur, avec comme paramètre ledit segment de type URL. 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 10 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 le schéma par blocs d'une configuration de réseau informatique étendu qui utilise l'invention, la figure 4 est un diagramme de flux illustrant de façon générale les processus qui 15 interviennent dans un mode de réalisation de l'invention, la figure 5 est un diagramme de flux illustrant de façon plus détaillée une application préférentielle de l'invention, la figure 6 est un diagramme de flux illustrant de façon plus détaillée une autre application de l'invention. 20 Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. 25 Sur la figure 1, deux postes d'usages 210 et 220 peuvent se connecter à un réseau étendu, ici Internet, pour se relier par exemple à la "toile" ("web"). Est également présent sur Internet un système serveur 100, localisé sur une ou plusieurs machines inter-communicantes. La ou les machines comprennent un environnement hôte pour serveurs, ainsi qu'un port de communication 121 sur le réseau étendu, un logiciel serveur 30 proprement dit 120, et des applications 123 accessibles au serveur. Sur la figure 1, et à titre d'exemple, on a fait apparaître dans le même environnement 100 un autre serveur 140, muni de ses applications 143, et qui possède un autre port 141. Bien entendu, les applications 123 et 143 peuvent être partagées et partager les données qu'elles utilisent dans une mémoire de masse (non représentée ici). Les serveurs 120 et 140 sont associés à deux noms de domaine respectifs. Ils peuvent mettre en oeuvre des fonctions classiques d'un site Internet, telles que l'affichage de page web en fonction des demandes des utilisateurs U1 et U2 des postes 210 et 220. 10 On sait également que sont actifs sur Internet des serveurs de nom de domaine ("DNS"), tels que 310 et 320. Ces serveurs ont la charge de transformer l'appel d'un site par un usager en l'adresse physique sur Internet ("adresse IP") de la ou des machines qui supportent le site Internet en question. Ici, selon le dessin, le poste 210 accède au serveur de nom de domaine 310, qui lui fournit l'adresse IP du port 121 ; de son côté, le poste 15 220 accède au serveur de nom de domaine 320, qui lui fournit l'adresse IP du port 141. En pratique, l'obtention de l'adresse IP se fera souvent à partir du même serveur DNS. La figure 2 illustre la constitution d'un serveur selon un mode de réalisation de l'invention. On y retrouve le port 121 de la figure 1. Le serveur 120 comprend notamment un gestionnaire d'accès 122, qui va recevoir une expression d'appel depuis le port. Par exemple, si l'appel du site par l'usager ne comprend que le nom de domaine, 25 le gestionnaire d'accès 122 va automatiquement sélectionner la page d'accueil, très souvent nommée "/index.htm". Cela donne accès à l'arborescence des pages, parmi lesquelles l'usager pourra choisir en fonction du bouton, pictogramme ou autre lien présent sur la page d'accueil qui est présentée sur son écran (à distance du serveur). A titre d'exemple la figure 2 montre les "applications de page" 131 à 134. 30 Plus généralement, le gestionnaire d'accès 122, qui reçoit une expression d'appel depuis le port, va lui appliquer des règles prédéfinies. Si une règle est vérifiée, une 20 application de serveur, par exemple une page web, va être choisie en fonction de l'expression d'appel et de la règle qu'elle vérifie. Le gestionnaire d'accès 122 peut comprendre une règle qui appelle pour l'usager une fonction d'identification en ligne, qui fait partie d'un ensemble de fonctions de gestion d'abonné 135, comprenant aussi une fonction d'ouverture de compte sur le site. Ainsi, lorsqu'un usager se connecte au site, il peut s'identifier. Et, en principe, cette identification reste valable pour la durée de sa connexion. En bref, le gestionnaire d'accès 122 permet la navigation dans une arborescence, pour appeler des pages ou autres liens à travers la page d'accueil ou une page en cours. Mais l'usager distant peut aussi appeler directement une page, en composant directement l'expression d'appel correspondante. En d'autres termes, et plus généralement, le gestionnaire d'accès donne des accès à différentes applications, qu'il s'agisse de présenter une page, d'enregistrer l'utilisateur, de lui créer un compte, ou d'autres fonctions. Lorsqu'arrive par le port 121 une expression d'appel qui ne correspond à rien de connu du gestionnaire d'accès, celui-ci refuse l'appel et renvoie un message d'erreur. L'invention opère différemment. Elle prévoit un discriminateur 137, qui est capable de rechercher si une expression d'appel contient un segment de type URL. Lorsqu'une expression d'appel ne correspond à aucune règle prédéfinie dans le gestionnaire d'accès, le discriminateur 137 l'analyse, et l'intercepte si elle est de type URL (interceptant également le message d'erreur). Un dérivateur 136 agencé pour activer le discriminateur en présence d'une expression d'appel qui provient d'un utilisateur enregistré. Dans le mode de réalisation particulier de la figure 2, la liaison entre le générateur d'accès 122 et le discriminateur 137 comporte un interrupteur, qui est sous30 commande d'un dérivateur ou moniteur 136. La figure 2 montre aussi un lien entre le moniteur 136 et la ligne de liaison entre le gestionnaire d'accès 122 et l'application 135 (usagers enregistrés). Ceci schématise le fait que le moniteur 136 sait si l'usager en cours s'est ou non 5 identifié, de sorte qu'il peut ne mettre en oeuvre le discriminateur 137 qu'en présence d'un usager enregistré et identifié pour la session en cours. Si le discriminateur reconnaît une expression de type URL alors le moniteur 136 va invoquer une application spécifique 124, avec le segment de type URL tel qu'isolé ou 10 réécrit par le discriminateur 137. Il s'y ajoute, en principe, au moins une donnée enregistrée liée à l'utilisateur. Cette donnée peut être simplement un identifiant de l'utilisateur dans la base de données des utilisateurs 139. L'opération 400 correspond à l'émission d'une requête par un usager U1. Cette 15 requête peut être de la forme illustrée en partie droite, en regard de l'élément 400 de la figure 4. La requête aboutit à un serveur de nom de domaine 410, qui va transformer le préambule de la requête en l'adresse physique du serveur recherché. On suppose, ici, que le serveur recherché est dénommé "smub.it". Et, sur la figure 4, on note l'adresse physique conforme au protocole Internet qui correspond au serveur dont la dénomination courante est "smub.it". 25 En 420, le port d'entrée de ce serveur "smub.it", qui possède l'adresse physique précitée, reçoit comme requête la suite de l'expression d'appel initial, comme indiqué en partie droite sur la figure 4. En 422, ce serveur va d'abord rechercher si cela correspond à l'adresse d'une 30 page qu'il délivre aux visiteurs ordinaires du site. Si ce n'est pas le cas, l'opération 424 va rechercher si l'émetteur de la requête en 400, à savoir l'usager U1, est un usager enregistré, qui s'est préalablement identifié lors de cette connexion. 20 Ensuite, l'opération 427 va rechercher si ce qui reste de l'expression d'appel correspond à une URL (Uniform Resource Locator) et, si c'est le cas, l'opération 429 va lancer une opération spéciale ayant pour paramètre le reste de l'expression d'appel en regard de l'élément 427 de la figure 4 (ou en regard de l'élément 420 de la figure 4), ainsi qu'une ou plusieurs données utilisateurs, que l'on peut d'ailleurs réduire à la simple identification de l'utilisateur, les données utilisateurs voulues étant recueillies ensuite par l'application spécifique 124. Certaines opérations peuvent être interverties sur la figure 4. Par exemple, on peut vérifier si l'usager U 1 s'est identifié avant de vérifier si l'appel qu'il délivre correspond à une page, à l'opération 422. Il est maintenant fait référence à la figure 3, qui permettra de comprendre l'un 15 des avantages essentiels de l'invention. Différentes requêtes Internet peuvent partir du navigateur 212 de l'utilisateur, à travers l'interface de connexion 202, et la toile. Dans un ou plusieurs systèmes serveurs 100, on prévoit une interface de communication 102, qui permet l'accès à une pluralité de 20 serveurs Internet dédiés, ayant chacun une URL différente. Ici, on a : - le serveur 120 avec l'URL "smub.it", - le serveur 140 avec l'URL "smub.to", - le serveur 150 avec l'URL "alter.from" (des suffixes de plus de deux caractères sont en voie de libéralisation), - le serveur 160 avec l'URL "other.at". De la manière précédemment décrite, chaque fois que l'un de ces serveurs est appelé par un utilisateur identifié, avec derrière l'URL, une autre URL ou quelque chose 25 30 qui ressemble à une autre URL suivant une règle prédéterminée, le serveur concerné (120, 140, 150, 160) va procéder à une réécriture de l'URL d'appel (par exemple en 122, 142, 152, 162), pour invoquer ensuite une application spécifique qui est propre à ce serveur (124, 144, 154, 164, respectivement), avec pour paramètre au moins cette URL réécrite, et de préférence une identification de l'utilisateur. On décrira maintenant deux exemples particuliers des applications spéciales 124 et 144 de la figure 3. L'application spéciale 124 peut correspondre à un diagramme de flux de la figure 5. Ce diagramme de flux est tiré de la demande de brevet française 0801417, du 14 mars 2008, au nom de la demanderesse. La figure 5 de la présente demande correspond précisément à celle de la demande antérieure, à l'exception des points suivants : la figure 5 de la demande antérieure parle de "créer/modifier", tandis que la figure 5 de la présente demande parle de seulement "créer" ; les parties de la figure 5 de la demande antérieure correspondant à la fonction "modifier" ont donc été supprimées. Sous réserve de ces modifications, le contenu descriptif de la demande antérieure relatif à sa figure 5 est à considérer comme incorporé à la présente description. Les opérations ajoutées ou modifiées pour mettre en oeuvre la présente invention ont été mises en gras sur la figure 5. L'opération nouvelle 514 reflète que l'usager s'est déjà identifié, et l'application va donc aller chercher à l'opération 514 les données du compte personnel, selon le paramètre "Userld", qui constitue, ici, l'un des paramètres de l'appel 210 (en l'occurrence le premier paramètre). L'opération 520 de choix d'un alias dans le compte personnel est en réalité optionnelle. Ensuite, à l'opération 532, au lieu de devoir saisir complètement une URL souvent très complexe, ce qui est souvent source d'erreurs, et contraint par conséquent à consacrer du temps et des ressources pour vérifier que cet URL existe bien, il suffit maintenant dans cette opération 532 de prendre l'URL "myURL" passée ici comme second paramètre dans l'appel 510, pour constituer directement l'URL qui va faire l'objet du raccourci selon la demande de brevet antérieure. L'homme de métier comprendra que les opérations sont ainsi considérablement simplifiées, et débarrassées d'une source d'erreurs importante. La simplification sera mieux comprise au vu des résumés suivants : - On considère un usager U l qui se trouve en liaison avec un site "myURL" qui l'intéresse. 15 - Cet usager est enregistré sur le site "smub". - Il se trouve dans une session au cours de laquelle il s'est identifié. - Il lui suffit alors sur la ligne d'adresse Internet (ou URL) de son navigateur, de taper : "smub.it" devant l'URL qui s'y trouve. Avec la présente invention, tout le reste est automatique, jusqu'à l'opération 514 ou 520 ou 536 de la figure 5, suivant les choix que l'on aura faits dans ce diagramme de flux de la figure 5, quant aux opérations qui sont optionnelles ou non. 25 Bien entendu, la description qui précède n'a aucun caractère limitatif. On peut prévoir différents serveurs avec différentes applications spécifiques, comme illustré sur la figure 3. Une seconde application spécifique est définie dans le diagramme de flux de la figure 6. 30 A l'opération d'entrée 610, il s'agit d'envoyer un courriel avec deux paramètres dont le premier est un identifiant d'utilisateur et le second le segment d'URL isolé en sortie du bloc 137 de la figure 2. 20 L'opération 612 présente à l'usager distant une page courriel d'un format prédéfini, dans laquelle : - l'opération 614 a permis d'accéder aux données utilisateurs correspondant à l'identifiant passé comme paramètre, et à remplir le courriel par rapport à ces données utilisateurs, suivant un format prédéfini, ou même en variante suivant un format qui peut avoir été défini par l'utilisateur lui-même. - optionnellement, l'opération 620 permet à l'utilisateur de choisir un alias correspondant à l'utilisateur, au sens des alias définis dans la demande de brevet antérieure 0801417 précitée, par exemple. 15 - l'opération 632 insère l'URL passée comme paramètre dans le message prédéfini. - l'opération 634 définit l'émetteur du courriel, d'après son identifiant utilisateur ou son alias. On permet ainsi à l'utilisateur enregistré d'envoyer directement une URL dans un message d'accompagnement à l'un quelconque de ses contacts, par la seule opération consistant à saisir "smub.to" (dans l'exemple présent), devant l'URL présentement indiquée dans la zone d'adressage de son navigateur. Bien entendu, on peut prévoir une opération 645 pour afficher cette page de courriel et y apporter d'éventuels compléments, avant l'envoi à l'opération 690. Un service d'adressage réseau 510 peut utiliser un multiplet d'un format 30 prédéterminé, ce format comprenant un élément lié à l'utilisateur enregistré. 10 20 25 Revendications1. Système informatique, comportant un environnement hôte pour serveur (100), muni d'un port de communication sur réseau étendu (121), ainsi qu'un serveur réseau (120), 5 auquel est affecté une première adresse réseau ou URL d'acheminement, avec : des applications de serveur (123), un gestionnaire d'accès (122), capable de recevoir une expression d'appel depuis le port, puis d'appliquer des règles prédéfinies à l'expression d'appel, et, si une règle est vérifiée, d'invoquer une application de serveur qui est choisie selon 10 l'expression d'appel et la règle qu'elle vérifie, caractérisé en ce que le gestionnaire d'accès comprend : - un discriminateur (137), activable pour reconnaître si une expression d'appel non conforme aux règles prédéfinies, se trouve contenir un segment de type URL, et intercepter alors une telle expression, et 15 un dérivateur (136), capable, en cas d'expression interceptée, reconnue comme de type URL, d'invoquer une application prédéfinie spécifique (124), avec comme paramètre ladite expression interceptée. 2. Système informatique selon la revendication 1, caractérisé en ce que l'application 20 prédéfinie (124) comprend la création d'une expression d'appel raccourcie en correspondance de l'expression interceptée, reconnue comme de type URL, et la mise à disposition d'un service d'adressage réseau indirect (510), pour viser l'URL dudit segment à partir de cette expression d'appel raccourcie. 25 3. Système informatique selon l'une des revendications 1 et 2, caractérisé en ce que les applications de serveur (123) comprennent une application d'abonné (135) capable d'identifier un appelant comme utilisateur enregistré, et en ce que l'application prédéfinie spécifique (124) est invoquée en présence d'au moins une donnée enregistrée liée à l'utilisateur. 11 30 4. Système informatique selon la revendication 3, caractérisé en ce que la donnée enregistrée liée à l'utilisateur comprend un identifiant de l'utilisateur. 5. Système informatique selon la revendication 2, caractérisé en ce que le service 5 d'adressage réseau indirect (510) utilise un multiplet d'un format prédéterminé, ce format comprenant un élément lié à l'utilisateur enregistré. 6. Système informatique selon l'une des revendications précédentes, caractérisé en ce que l'application prédéfinie (124) comprend la création d'une page d'envoi (610) 10 d'un courriel contenant l'URL dudit segment. 7. Système informatique selon l'une des revendications 1 à 5, caractérisé en ce qu'il comprend au moins un second serveur réseau (140), auquel est affecté une seconde URL d'acheminement, en ce que ce second serveur comprend une seconde 15 application prédéfinie spécifique (144), capable de création d'une page d'envoi de courriel, et en ce que ce second serveur réseau possède aussi un gestionnaire d'accès agencé comme le précédent, avec un dérivateur agencé pour invoquer la seconde application prédéfinie spécifique (144), avec des paramètres comprenant le segment de type URL. 20 8. Procédé d'aide à la navigation informatique sur réseau étendu, caractérisé par les étapes suivantes : a. émettre (400) depuis un poste utilisateur une requête sur le réseau étendu comprenant une URL de destination, suivie d'une expression contenant une seconde 25 URL, b. dans un serveur réseau étendu, sur le port qui possède l'adresse physique correspondant à l'adresse de destination, recevoir une expression à traiter (420), c. déterminer si l'expression à traiter contient un segment de type URL (427), et d. si la détermination de l'étape c. est positive, invoquer une application 30 prédéfinie spécifique du serveur (429), avec comme paramètre ledit segment de type URL. 9. Procédé selon la revendication 8, caractérisé en ce que l'application prédéfinie (124) de l'étape d. comprend la création d'une expression d'appel raccourcie en correspondance de l'expression interceptée, reconnue comme de type URL, et la mise à disposition d'un service d'adressage réseau indirect (510), pour viser l'URL dudit segment à partir de cette expression d'appel raccourcie. 10. Procédé selon l'une des revendications 8 et 9, caractérisé en ce que l'étape d. comprend aussi la détermination de ce que l'expression provient d'un utilisateur enregistré (424), tandis que l'application prédéfinie spécifique du serveur (429) est invoquée en présence d'au moins une donnée enregistrée liée à l'utilisateur. 11. Procédé selon la revendication 10, caractérisé en ce que la donnée enregistrée liée à l'utilisateur comprend un identifiant de l'utilisateur. 12. Procédé selon la revendication 9, caractérisé en ce que le service d'adressage réseau indirect (510) utilise un multiplet d'un format prédéterminé, ce format comprenant un élément lié à l'utilisateur enregistré. 13. Procédé selon la revendication 8, caractérisé en ce que l'application prédéfinie (124) comprend la création d'une page d'envoi (610) d'un courriel contenant l'URL dudit segment. 14. Procédé selon la revendication 13, caractérisé en ce que l'étape d. comprend aussi la détermination de ce que l'expression provient d'un utilisateur enregistré (424), tandis que l'application prédéfinie (124) comprend la création d'une page d'envoi (610) d'un courriel contenant l'URL dudit segment, au nom de l'utilisateur enregistré.30