FR2735595A1 - Dispositif permettant de fournir des signaux depuis un appareil central a d'autres appareils servant a consulter des donnees - Google Patents

Abstract

Le dispositif sert à échanger des signaux entre un appareil et d'autres appareils aux fins de consultation. Les signaux répresentent des demandes et sont réalisés par chaque appareil de consultation (browser) afin d'obtenir des renseignements selon un format de page précise. Le dispositif se compose: de moyens d'identification des demandes des clients opérant leur consultation et qui désirent des renseignements précis en format précis; de moyens de traiter les données; de moyens de représentation des données pour un traitement efficace des données utilisant des instructions relativement simples; de moyens de fournir des signaux de salle à l'appareil de consultation de données.

Description

DISPOSITIF PERMETTANT DE FOURNIR DES SIGNAUX

DEPUIS UN APPAREIL CENTRAL A D'AUTRES APPAREILS

SERVANT A CONSULTER DES DONNEES

Cette invention consiste à fournir des signaux aux clients qui consultent, ces dits signaux représentent des commandes d'exécution par les clients afin de générer des pages de données structurées qui leur sont accessibles. En réponse à la demande du marché, I'apport de données lisibles à

l'utilisateur existe déjà dans le champ des systèmes de télévision câblées.

Les systèmes de type "Star" (marque déposée) en particulier permettent à celui qui les regarde de faire des sélections télécommandées dans le but de faire circuler le signal demandé d'un centre de distribution au

téléspectateur qui l'a sélectionné.

Les systèmes de télévision câblée sont généralement basés sur les signaux télévisuels normalement utilisés dans les diffusions standards qui exigent une taille de bande suffisamment large pour produire chaque page de données visibles. Récemment, on a tenté de comprimer des données vidéo en mettant en pratique des recommandations utilisant des modèles standard tel MPEG, pour faciliter la distribution des signaux vidéos dans des chaînes ayant des bandes de taille réduite. Ainsi, il est maintenant possible de transmettre des signaux de basse qualité sur les lignes téléphoniques traditionnelles en utilisant des techniques de compression temporelles et spatiales. Depuis quelques années, il est également possible de distribuer des données lisibles par l'utilisateur sous la forme de textes encodés. La transmission de textes, utilisant souvent l'encodage ASCII, nécessite une taille de bande plus réduite que celle utilisée pour la transmission de signaux videos, et depuis quelques années les données

3 0 de ce type sont transmises sur les câbles téléphoniques traditionnels.

En contraste avec les signaux vidéos produisant des images, la diminution de la qualité de la présentation et de l'environnement graphique en général posent un problème pour la transmission de textes. Pour cette raison, contrairement à la vidéo, la transmission de données a jusqu'à présent tendu à se développer exclusivement dans les milieux spécialisés, o la présentation n'est pas considérée particulièrement importante. Par exemple, les données reçues étaient très souvent jugées valables, et tout

aussi souvent on ré-entrait les renseignements lorsque c'était nécessaire.

Beaucoup de différents modèles et conventions se sont développés au cours de ces dernières années, ce qui pose un problème supplémentaire pour la dissémination de données. Pour cette raison, les lo utilisateurs ont eu besoin de développer des techniques spécifiques pour accéder aux différentes sources de données, ce qui en soi est devenu une

activité spécialisée.

En parallèle avec la tendance à réduire la largeur des bandes pour la transmission de signaux vidéos, il y a également eu une tendance à améliorer la forme graphique, la structure et la présentation de ce qui aurait normalement été considéré comme des données textuelles. Ainsi, bien que les données puissent être transmises dans un environnement textuel, comme par exemple dans le réseau international "Internet", il y a eu une tendance à inclure des structures de formatage qui permettent qu'une source basée sur des données puisse être vue par les utilisateurs d'un équipement présentant les données dans une forme similaire à celle d'une image vidéo. Ainsi, les deux arts du traitement des signaux vidéos et du traitement des données graphiques se rapprochent de plus en plus et

cherchent à atteindre le but commun de fournir une image haute-

résolution, bande large et haute qualité, tout en transmettant des données

sur des bandes de transmission réduites.

Depuis quelques années, les systèmes de télévisions câblées ont été utilisés pour développer le télé-achat, et grâce à leurs capacités d'échange, il est possible d'y intégrer un certain niveau d'interactivité. Les systèmes en ligne facilitent un niveau plus élevé d'interactivité et, en plus de pouvoir faire des sélections particulières en réaction aux images diffusées, il est également possible de sélectionner des pages spécifiques d'images en consultant des catalogues, des structures à tiroirs, etc. Ainsi, grâce à leur capacité de présenter des images de haute qualité similaires à celles disponibles dans les systèmes vidéos, les systèmes en ligne

présentent des environnements avec des capacités plus interactives.

Cependant, il est remarquable que dans beaucoup de ces environnements la qualité des images puisse être améliorée pour obtenir un plus grande

nombre de clients.

Un moyen connu d'améliorer la qualité des images dérivées des systèmes textuels est l'ajout de commandes de formatage ou des instructions de lignes de données. Ces instructions contrôlent les opérations d'un récepteur, afin qu'il traite les signaux pour générer une image vidéo de haute qualité capable d'être montrée sur le terminal d'un

client.

En plus d'améliorer la qualité des images présentées, une telle approche facilite l'amélioration du système de compatibilité. Ainsi, les contrôles des signaux transmis sont exécutés par le terminal d'un récepteur d'une façon compatible avec le système récepteur. Les signaux de sortie doivent être considérés comme des instructions servant à déclencher des opérations sur les données visibles en accord avec les

contraintes locales.

Ainsi, I'utilisation de systèmes de ce type doit être distinguée des simples systèmes locaux de base de données, dans lesquels toutes les opérations du système sont localement contrôlées et ne prennent pas en compte le besoin d'avoir des facilités et des caractéristiques télécommandées. De tels systèmes sont distinctement différents: dans ces systèmes de données, seul le transfert de données est manipulé par une suite de programmes de contrôle. Dans l'encodage des langages, les commandes de formatage sont transcrites sous la forme de commandes d'exécution depuis la station réceptrice, afin d'accomplir les opérations sur

les données visibles supportées par la plate-forme et les périphériques.

Les encodages de ce type doivent aussi inclure d'autres capacités précédemment introuvables dans les systèmes de distribution de données simples. En particulier, une caractéristique très précieuse est la capacité de recevoir automatiquement des fichiers supplémentaires de l'ensemble du réseau en général. Une telle procédure est possible, parce que comme précédemment établi, la transcription du langage est effectuée par le système d'exploitation local et ces procédures doivent inclure des 1o procédures pour effectuer des appels externes vers des fichiers répandus

dans le réseau accessible.

Du point de vue d'un utilisateur, de telles connexions doivent être considérées comme générant un niveau pluri-dimensionnel à l'intérieur d'un document visible, dans un mot ou une phrase particuliers sélectionnés, o une expansion est ensuite fournie et les documents en question sont identifiés. Dans le but de distinguer de tels documents d'autres documents indépendants, les textes de ce type sont couramment appelés "hypertexte". De façon similaire, de telles connexions peuvent aussi être établies pour remplir des mouvements de séquences vidéo ou

audio etc. et un tel environnement s'appelle "hypermédia".

"Hypertexte mark-up language" (HTML) développé par le CERN fin 1980- début 1990, constitue un exemple de recommandation particulière sous laquelle les signaux incluent des commandes d'exécution par les clients qui consultent, et fait depuis récemment partie du réseau Internet sous un service connu comme le "World Wide Web". Un fichier HTML est principalement un document ASCII parsemé de marques pour le formatage du texte et la diffusion des images. Les marques représentent graphiquement des instructions activées par les récepteurs de consultation, configurées pour présenter un texte ou des graphiques. La personne qui consulte a un contrôle total de la façon dont la page va

2735595

être présentée, par conséquent il est possible de générer de larges chaînes de pages conçues graphiquement depuis une modeste série de marques HTML. Le réseau Intemet est un exemple extrême d'un réseau regroupant s beaucoup d'environnements différents, ayant des protocoles et des capacités variables pouvant être interconnectés et utilisant énormément le contrôle distribué et les séries d'instructions. Corrome suggéré précédemment, les systèmes de ce type fournissent un environnement dans lequel un utilisateur peut consulter de nombreux fichiers et structures. Par; conséquent, les environnements qui facilitent la conversion et la réception de fichiers HTML sont nommés des "browsers": un "browser"' est une application permettant d'interpréter et diffuser des documents reçus en HTML de façon à ce que l'information soit transmise à l'utilisa'eur dans une forme compatible avec l'équipement dont il dispose. Ainsi, en Utilisant un15 terminal sophistiqué, fourni avec un "browser" approprie, il est possible de diffuser des données textuelles d'une qualité perçue comme étant similaire à celle d'une bande vidéo pleine, cependant que la proportion de largeur de bande utilisée pour distribuer les informations est considérablement réduite. Ainsi, comme précédemment établi, le but d'un "browser" est d'améliorer20 considérablement la qualité de l'image de façon à ce qu'une image de haute qualité vidéo soit présentée au client utilisateur si son équipement est

adéquat. En plus, le "browser"' assure la compatibilité entre les facilités du système local et les données transmises. De plus, les connexions hypertexte peuvent être définies à l'intérieur d'un document réalisé par le25 "browser" de sorte à produire des documents supplémentaires, et disponibles en réponse aux sélections conduites par l'utilisateur.

Il est possible pour les clients utilisateurs de faire usage de ces langages sophistiqués uniquement si les réseaux possèdent des sources de données accessibles. Les fichiers HTMIiL peuvent être stockés dans un fichier dont les structures sont similaires aux formats conventionnels de données. Des demandes sont formulées par des clients qui consultent des applications maintenues à un noeud de distribution, communément

dénommé "serveur".

"browsers" et "serveurs" sont des applications qui doivent être disponibles quand elles sont sollicitées, bien que lors de périodes calmes elles ne soient pas nécessairement requises. Les procédures de ce type, fixées dans les systèmes et transparentes pour les opérateurs, sont collectivement dénommées "démons", Ainsi, en opération, le serveur 1o "démon" interroge par intermittence des ports sélectionnés pour un signal de transmission des demandes. En réponse à ces demandes, les serveurs peuvent activer des opérations de sécurité et d'économie puis, si possible,

le fichier sélectionné est identifié et fourni à la demande du "browser".

Dans les anciens systèmes-textes basés sur le langage ASCII, plus simples, la production de texte dans une forme propre à la transmission

sur des réseaux impliquait des opérations relativement simples.

Généralement, les documents pouvaient être issus de fichiers textes ou de base de données et transmis directement sur le réseau. Chez le receveur, les données à traiter se trouvaient souvent dans les mémoires- tampons, mais après elles pouvaient être transmises directement à des imprimantes en ligne ou des appareils similaires, dès lors produisant une liste ou une

copie imprimée du texte ASCII transmis.

Comme précédemment exposé, HTML permet à des structures de formatage sophistiquées d'être ajoutées aux données visibles afin de 2 5 présenter une image considérablement plus attrayante aux clients utilisateurs. Cependant, un désavantage majeur de l'utilisation de tels systèmes reste qu'il est nécessaire de convertir les données en HTML avant qu'elles soient transmises sur le réseau. En pratique, une telle procédure est effectuée manuellement et un nombre significatif d'heures de travail peut être requis pour convertir un texte original en une version

HTML appropriée, convenant à une distribution sur le réseau.

Dans certains milieux, comme les milieux de la recherche, les données peuvent être sollicitées pendant de longues périodes et, dans de telles conditions, il est possible de justifier le temps et l'effort nécessaires à la transcription du texte pour une distribution sur le réseau dans une forme appropriée. Cependant, dans le domaine des magazines et des journaux, certaines formes de données, bien qu'initialement tout-à-fait valables, peuvent avoir de très courtes espérances de vie et même devenir presque sans valeur dès le lendemain. Ainsi, de nombreuses formes de 1o publications traditionnellement sur papier diffèrent leur publication électronique si la quantité d'effort et de temps fournie pour transposer les informations textes dans une forme adéquate à la distribution sur les réseaux est élevée. De plus, dans de nombreux cas, il est impossible de réduire le temps de travail en augmentant la main d'oeuvre, puisqu'il n'est possible que pour une seule personne de travailler sur une page à un

moment donné.

La transcription traditionnelle est une tâche laborieuse, de par sa nature; les données transmises sont actuellement très différentes des images visibles. Dans la plupart des cas, elle est cependant nécessaire 2 o pour ateindre un niveau de transcription acceptable, après que les données aient été transférées dans un "browser"' localement situé, ceci afin que l'image résultante puisse être considérée avant que d'autres opérations soient effectuées. Une fois créés, les fichiers sont chargés dans des mécanismes de stockage appropriés et enfin disponibles aux

demandes des clients.

Les systèmes sont disponibles, ce qui facilite la création de documents HTML. Par exemple, il est possible de traiter des documents créés en utilisant un système de traitement-de-texte, tel que "Word for Windows" (marque déposée) par lequel, en réponse aux opérations 3 o manuelles, les marques HTML sont ajoutées au texte visible par les utilisateurs. Les systèmes de ce type sont vendus sous les marques

déposées 'web author" et "Intemet assistant".

Il est bien connu que les journaux traditionnels changent au cours d'une journée, parce qu'il existe plusieurs publications par jour avec des reportages variés. Souvent la pa.e de couverture de l'édition du soir est différente de celle de l'édition du matin. Dans les environnements

électroniques il y a même davantage de variations.

Dès lors, il serait nécessaire de changer les pages manuellement de façon continue pour remédier à ce phénomène.

Des systèmes ont été proposés dans lesquels les clients sont poussés à croire qu'un journal a été modifié pour leurs besoins personnels.

L'impression est donnée aux clients que les informations sont adaptées à leurs intérêts, et sur lesquelles des sélections particulières peuvent être opérées qui modifient les documents aux besoins du client. Le problème15 avec ce genre de solution est que chaque page vue par le client doit être créée d'avance, ce qui double le nombre de pages nécessaires chaque fois qu'une décision est prise. Bien qu'une telle approche puisse avoir des applications dans des environnements particuliers, au fur et à mesure que le nombre de pages augmente, le nombre de pages actives nécessitées dans20 le système devient énorme. Il y aurait ensuite beaucoup de travail pour créer et maintenir manuellement chaque page, ce qui ne rend pas le système économique. C'est particulièrement le cas quand on pense aux publications traditionnelles sur papier, qui sont considérées comme ayant une valeur

intrinsèque basse ou nulle, comme par exemple les journaux gratuits ou les25 catalogues publicitaires.

Selon le premier aspect de cette invention, un dispositif est fourni qui permet de transmettre des signaux de sortie depuis un appareil central à plusieurs appareils de consultation lies à un réseau, et dans lequel ces signaux de sortie représentent des commandes d'exécution par chaque30 appareil de consultation afin d'obtenir montrer des données visibles qui sont conformes à un format de page spécifié. Le dispositif se compose de: moyens d'identifier les demandes des clients qui consultent afin de définir une demande de données visibles spécifiques accompagnée par des demandes de repésentation de ces données dans un format spécifié; moyens de lire les données qui représentent ces données visibles; moyens de traiter ces données lues afin de combiner une représentation de ces données visibles avec des instructions d'exécution; moyens de fournir des signaux de sortie dérivés de ces données

traitées à l'appareil de consultation d'o la commande est issue.

En accord avec cette invention, il n'est pas nécessaire de garder tous les fichiers de sortie sous la forme de fichiers prédéfinis comme HTML. Des instructions de sortie HTML sont produites au besoin, lorsque

le client les commande.

Le dispositif peut être utilisé dans plusieurs configurations de

réseaux.

Le réseau de prédilection est Internet. Dans l'idéal, les commandes sont faites par les clients qui consultent sous la forme d'URLs (Allocation de Ressource Uniforme-Uniform Resource Locator) et les signaux de sortie sont renvoyés à l'appareil de consultation sous la forme de

commandes de transcription hypertexte.

Le dispositif peut être utilisé pour fournir n'importe quel type de donnée aux clients, en particulier des données textuelles et des données graphiques. Dans l'idéal, les données visibles sont lues dans des bases de données traditionnelles en réponse à la réception d'un URL. Ensuite, ces données sont traitées de façon à les configurer dans les commandes HTML. Dans l'idéal, des données sont identifiées dans les bases de données contenues dans un index, et ceci tant que la relation entre l'index o et les données peut être réajustée. Cette opération facilite le

renouvellement des données sans nécessiter un nouveau codage HTML.

Selon un deuxième aspect de cette invention, une méthode est fournie pour diffuser des signaux de sortie à partir d'un appareil central diffusant à plusieurs appareils de consultation, eux-même liés à un réseau dans lesquels ces signaux de sortie représentent des commandes d'exécution par chaque appareil de consultation, ceci afin d'obtenir des données visibles en accord avec un format de page spécifié. Cette méthode permet de: identifier les commandes des clients en consultation et définissant une commande pour des données visibles spécifiques avec des commandes pour présenter ces données dans un format spécifié; lire les données qui représentent ces données visibles; traiter ces données lues afin de combiner une représentation de ces données visibles avec des instructions d'exécution; et fournir des signaux de sortie dérivés de ces données traitées à

l'appareil de consultation.

L'invention sera à présent décrite au moyen d'exemples avec des références aux schémas joints dans lesquels: le schéma 1 est un diagramme d'une section du réseau international Internet, qui comprend de nombreux fournisseurs et utilisateurs de services, et réalisé à travers plusieurs topologies de réseau; le schéma 2 représente un exemple de réseau d'un fournisseur de services typique, incluant un réseau local et un hôte diffusant; le schéma 3 représente des détails sur l'hôte identifié sur le schéma 2 incluant un centre de traitement et une mémoire d'accès aléatoire pour conserver les instructions d'exécution de ce centre de traitement; le schéma 4 représente un environnement de traitement spécifié par le centre de traitement et ses instructions associées, créées par le centre il de traitement, ainsi que sa mémoire associée présentée dans le schéma 3 incluant le protocole "Daemon Hypertext transport protocol" (Protocole de Transport Hypertexte Démon) et les procédures de traitement en ligne en accord avec cette invention; le schéma 5 illustre l'opération de "Protocole de Transport. Hypetexte Démon" identifié dans le schéma 4, en réponse à la réception d'une demande d'entrée URL incluant une identification des procédures d'initialisation et de traitement en ligne; le schéma 6 représente les appareils d'utilisateurs incluant un appareil de traitement et un écran de visualisation le schéma 7 représente un affichage typique montre sur l'écran de visualisation présenté par le schéma 6, en réponse aux instructions fournies à l'utilisateur d'un serveur; le schéma 8 représente un exemple des instructions sous la forme dans laquelle elles sont données à l'utilisateur qui consulte, afin de générer l'affichage présenté par le schéma 7; le schéma 9 représente les procédures d'initialisation prévues au schéma 5 en détail; le schéma 10 présente en détail les procédures en ligne prévues au schéma 5, incluant une indication pour générer des pages selon le protocole "Hypertext Transport Protocol" (HTML); le schéma 11 illustre la relation entre les composants quand ils sont configurés pour diffuser des pages HTML à un appareil de consultation; le schéma 12 présente le détail des procédures de génération des pages HTML du schéma 10, incluant une étape d'exécution d'une ligne de fonction; le schéma 13 représente en détail des procédures d'exécution d'une ligne de fonction, incluant une étape qui exécute la fonction; le schéma 14 présente les étapes qui exécutent la fonction utilisée pour générer les lignes de commande de sortie du schéma 8 en détail; 1 2

1 2 2735595

Un diagramme d'une section d'lnternet est représenté dans le schéma 1. Un réseau international de communication de données est représenté dans le diagramme par la région 101. L'accès à ce réseau est fourni par les chaînes de données 102, qui sont elles-même connectées aux noeuds de service 103. Les noeuds de service 103 donnent aux utilisateurs un accès à

Intemet avec les variations de largeur de bande de transmission.

Dans l'exemple, un réseau local 105 est fourni avec une connexion de bande large 104 au fournisseur de service sur Intemet 103. Le réseau 105 comprend des serveurs qui fournissent des données à Intemet en réponse z0 aux demandes faites par les utilisateurs. A présent, les utilisateurs accèdent à Intemet par des chaînes qui fournissent des capacités de circulation comprises entre 14,4 Kilo-bits par seconde (puissance à partir de laquelle un clavier téléphonique fonctionne) jusqu'à 100 Méga- bits par seconde et plus, dans le cas o des techniques optiques sont utilisées.15 Un utilisateur de bandes de largeur basses 106 communique avec un fournisseur de service 103 par les modems coopérants 107 et 108 connectés par un câble de transmission 109. Beaucoup d'utilisateurs de ce type peuvent accéder à l'information à partir d'un serveur, comme par exemple le serveur 105.20 Le réseau 105 est représenté en détail dans le schéma 2, le réseau est constitué d'une interface de données distribuées par des fibres (FDDI), l'anneau d'ossature "backbone" 201 ayant 4 distributeurs 202-203-204 et 205 connectés à lui-même. Le distributeur 202 est un circulaire symbolique qui dirige des données entre un réseau circulaire symbolique 206 et l'ossature "backbone" FDDI 201. Dans l'exemple représenté dans le schéma 2, un système de traitement hôte primaire 207 et un système de traitement hôte secondaire 208 sont connectés au cercle symbolique 206 ce qui faciliLe la communication entre les hôtes 27 et 28, et la communication entre ces 2 hôtes est l'anneau d'ossature "backbone" 201,

par le distributeur circulaire symbolique 202.

Un système hôte de traitement 209 et un système hôte de traitement 210 communiquent par un réseau ethernet (marque déposée) 211. Le réseau ethernet (marque déposée) 211 permet aussi la communication entre les hôtes 209 et 210 et l'anneau d'ossature

"backbone" 201 par distributeur ethernet (marque déposée) 203.

Le circuit d'ossature "backbone" communique aussi avec un réseau de transfert asynchrone (ATM), incluant un premier hôte ATM 212 et un deuxième hôte ATM 213. Les informations distribuées à Internet sont 1o générées par les opérations de service exécutées par l'hôte 212. Cet hôte communique avec le circuit d'ossature "backone" 201 via le distributeur ATM 205, qui facilite ensuite la communication à Internet lui-même via le distributeur Internet 204 et un conducteur de lignes Internet 215. Cela facilite le transfert des données à un fournisseur de services Internet

comme représenté dans le schéma 1.

L'encadrement présent est orienté vers la fourniture de données encodées HTML, en accord avec les recommandations HTML exécutées sur Internet sous la forme du service "World Wide Web". Cependant, l'invention a dans l'ensemble une application plus générale, en particulier 2 0 lorsqu'il est nécessaire de traiter des données visibles par un utilisateur en combinaison avec des signaux qui représentent une structure d'affichage sélectionnée, telle que les commandes puissent être exécutées à distance

par les clients en cours de consultation.

La station de service 212, représentée dans le schéma 1, sert les fichiers traités en accord avec le langage de transcription hypertexte (HTML) au client consultant via Internet. Un client demande que les renseignements soient fournis et cette demande est identifiée par une station de service comme, par exemple, la station 212 qui renvoie les renseignements via la connexion Internet à l'appareil du client en cours de consultation. Dès qu'une demande a été reçue, les signaux qui représentent les données visibles par l'utilisateur sont d'abord traités par la station de service. Les signaux qui représentent une structure d'affichage sélectionnée sont ensuite reçus. Ces deux signaux sont traités afin de produire une sortie unique HTML. Cependant, cette étape de traitement prend place seulement après que la demande du client ait été reçue; ainsi, les premiers signaux et les deuxièmes signaux sont traités pour produire des signaux de sortie sous forme d'instructions d'exécution par le client qui sont ensuite servis comme signaux de sortie aptes à l'exécution par le client. Ainsi, beaucoup de pages de données encodées HTML sont produites automatiquement sans qu'un effort manuel soit nécessaire pour chaque page. De plus, les pages peuvent être modifiées selon les besoins spécifiques du client et dans certains cas, il est possible d'ajuster le niveau de modification en réponse à l'histoire propre du client, tel que les sujets qui l'intéressent soient automatiquement identifiés, et que S cette identification soit utilisée pour diriger les renseignements qui l'intéressent.

Le matériel physique du réseau 105 est montré dans le schéma 2.

Une demande d'un client qui consulte est reçue par le fournisseur Internet via la donnée de connexion 104, ce qui permet au distributeur Internet de

diriger les renseignements vers le réseau d'ossature "backbone" 201.

Cette information comprend une adresse afin d'identifier l'environnement

traitant arrangé pour fournir l'information demandée.

L'hôte ATM 212 est représenté en détail dans le schéma 3. Une unité centrale de traitement 301 fournit un environnement de traitementmulti-fonctionnel à fonctions générales, qui pourrait être activé et géré par le système d'opération UNIX (marque déposée). L'unité de traitement inclut des connecteurs internes pour faciliter la communication avec un appareil à mémoire puissante comme par exemple le lecteur de disque

dur 202 et la mémoire à accès aléatoire 303.

La communication avec les appareils externes est facilitée par une

2735595

interface ou appareil entrée/sortie (E/S) 304 qui est elle-même connectée à des périphériques typiques comme un clavier, un écran, une souris etc. De plus, l'appareil E/S 304 est connecté à un distributeur ATM 205 via un circuit

de réseau contrôle 305.

Une routine est exécutée continuellement par l'appareil de traitement 301 pour identifier les demandes présentées à un port E/O particulier établi par l'appareil E/S 304. Ainsi, un paquet reçu par l'ossature "backbone" 201 inclut une adresse qui autorise l'interface avec le réseau contrôle 305, tel que ce contrôleur puisse diriger le paquet à l'interface E/S 304. Le paquet identifié par le contrôleur du réseau 305 sera présenté à un port particulier de l'appareil E/S 304. L'unité de traitement 301 identifiera le fait que des données ont été présentées au port en question et établira une connexion rendant le système effectivement actif. Une fois actif, ce paquet de données passe à travers l'appareil E/S 304 et devient un paquet d'informations alors

tenu sous le contrôle du système d'opération de l'appareil de traitement 301.

Ayant reçu cette information, l'appareil de traitement 301 est adapté pour l'exécution des étapes identifiées précédemment, cela signifie qu'il est à-même de traiter les signaux primaires et secondaires afin de produire des signaux de sortie sous forme d'instructions d'exécution par le client. Après que ce traitement ait eu lieu, le signal de sortie résultant est renvoyé pour la transmission à Intemet via l'unité de gestion de ligne 215, le distributeur Intemet 204, le distributeur ATM 205, le contrôleur de réseau 305 et l'appareil E/S 304. L'environnement traitant fourni par l'appareil de traitement 301 est 2 5 illustré dans le schéma 4. Un démon HTTP 401 est exécuté par l'environnement traitant 402 afin de détecter des demandes reçues par l'appareil E/S 304. En réponse aux demandes détectées, l'environnement traitant 402 est adapté pour la fourniture de fichiers HTML pré- déterminés à l'appareil E/S 304. De plus, il est également possible pour le démon

16 2735595

HTTP 401 d'identifier des programmes "interface de voie commune, binaire common gateway interface binary" (programmes CGI.BIN) qui sont des instructions d'exécution dans l'environnement traitant 402 ayant pour résultat que les fichiers identifiés sont fournis a l'appareil E/S 304. Les fichiers CGI.BIN peuvent fonctionner en réponse aux variations incluant des informations qui identifient le type de client qui consulte, le nom hôte du système et des détails du client. Des facilités de ce genre sont disponibles dans des serveurs HTTP déjà existants. Cependant, démon peut répondre aux demandes o le fichier de sortie HTML sera produit au besoin, en lo réponse aux instructions identifiées comme traitement en ligne. Quand il est demandé, le traitement en ligne recevra des données visibles par l'utilisateur d'une base de données 406 en combinaison avec des structures de fichier d'une source de structure de fichier 407. Ensuite, en réponse aux instructions du système de traitement en ligne 405, I'environnement 402 traitera des données visibles par l'utilisateur en combinaison avec des données sur la structure de fichier afin de produire des fichiers de sortie HTML pour l'appareil E/S 304. Les procédures de démon HTTP identifiées par 401 dans le schéma 4 sont détaillées dans le schéma 5. Les procédures d'initialisation sont

exécutées à l'étape 501 au démarrage, puis le port approprié en question est interrogé à l'étape 503 après avoir attendu pendant une période pré-

déterminée à l'étape 502. Les procédures montrées dans le schéma 5 sont exécutées dans un environnement multi-fonctionnel, donc la période d'attente à l'étape 502 représente une seule tâche, et d'autres tâches25 seront exécutées sans être affectées. A l'étape 504, une question est posee concernant la demande d'un utilisateur potentiel en attente dans le port interrogé, sous la forme d'une allocation de réseaux uniformes (URL). Si la réponse est négative, le contrôle est renvoyé à l'étape 502 et la procédure est répétée. Ainsi, comme indiqué précédemment, le système30 agit dans un environnement multi- fonctionnel comme celui foumrnit par le système d'opération UNIX (marque déposée). Pendant que les tâches particulières représentées dans le schéma 5 circulent jusqu'au moment o

un URL est reçu, le système est adapté à l'exécution d'autres tâches.

Si la réponse est positive, en d'autres termes un URL a été détecté, I'URL est traité à l'étape 505. Ensuite, les procédures de validation sont exécutées à l'étape 506. Les procédures de validation déterminent d'abord si l'URL satisfait une structure acceptable, puis des provisions de sécurité peuvent être exécutées pour établir si le serveur est autorisé à servir le client. En supposant qu'un URL valable a été fourni au serveur, la question de savoir si le client a demandé un fichier HTML pré-défini est posée à l'étape 507. Si la réponse est positive, le fichier demandé est

fourni au client à l'étape 508 et le contrôle est renvoyé à l'étape 502.

Alternativement, si la réponse est négative, le contrôle est dirigé vers

l'étape 509.

A l'étape 509, la question de la commande des procédures de traitement en ligne est posée. Si la réponse est positive, le fichier

commandé est préparé en ligne et fourni au client à l'étape 510.

Alternativement, si la réponse est négative, le contrôle est dirigé vers

l'étape 511.

A l'étape 511 la question de la fourniture d'une instruction que les programmes CGI.BIN doivent exécuter est posée. Si la réponse est positive, le contrôle est dirigé vers l'étape 512 et les instructions CGI.BIN identifiées seront exécutées. Alternativement, si la réponse est négative, toutes les possibilités auront été considérées et un message indiquant une

erreur est retourné à l'étape 514.

En référence au schéma 1, le réseau serveur 105 a été décrit en référence aux schémas 2 et 3 et les opérations exécutées dans ce serveur

212 pourraient être décrites avec une référence aux schémas 4 et 5.

L'information du serveur 212 est fournie aux clients sur Internet et les

fichiers sont mis à la disposition des clients en réponse à leur commande.

Comme établi précédemment, un client qui consulte fait des commandes sous la forme d'URLs via un modem 107. Une station de consultation 106

est illustrée en détail dans le schéma 6, et connectée à un modem 106 lui-

même connecté à Internet par un câble de communication 109. Le matériel physique du client consiste en un appareil programmable, tel un ordinateur personnel configuré pour opérer comme "browser" en réponse aux instructions installées depuis un médiateur local de mémoire permanente, d'habitude un lecteur de disque dur. Le système inclut un clavier 601 et un écran 602. Un opérateur envoie des commandes par le clavier ou la souris 603, en conséquence le "browser" envoie un URL au serveur. Les instructions de consultation exécutées par le terminal représenté dans le schéma 6 sont configurées pour être compatibles avec les instructions fournies par le serveur 212. Ainsi, des instructions particulières seraient installées sur le serveur 105 et pour qu'un utilisateur is gagne accès à ces instructions, il serait nécessaire d'installer un "browser" approprié pour l'utilisation sur le terminal du client. Quand le client envoie des commandes via le clavier 601 ou la souris 603, le "browser"' traduit ses instructions dans un URL qui, à son tour, est traité à distance par le serveur. En résultat, les instructions HTML sont fournies au "browser" 2o depuis le réseau telles que le "browser" exécute effectivement ces instructions afin de générer un signal vidéo susceptible d'être affiché. Le signal vidéo est fourni au moniteur 602, ayant pour résultat que les renseignements visibles par l'utilisateur sont affichés sur l'écran dans une forme dérivée des instructions HTML fournies au "browser" comme le

"browser" les a lui-même exécutées.

Le moniteur 602 est détaillé dans le schéma 7 qui représente une application typique du système. Dans cet exemple, la génération d'instructions HTML en ligne est utilisée pour présenter un catalogue de télé-achat en ligne aux clients, afin qu'ils puissent examiner et commander des produits. Ainsi, l'environnement interactif assure que les utilisateurs sont informés des produits disponibles et de leur p-ix en n-mê-ne temps qu'il

autorise des commandes faites facilement.

La page montrée dans le schéma 7 rep.-âsernte une table des matières pour un service s'appelant "Les Achats Fais dce Chez Soi" (qui est une publication imaginaire). La table des matières permet à un utilateur de sélectionner rapidement ses champs d'intérêts d'une façon s.ructurèe. Ainsi, de cette première page on peut sélectionner des objets ce s)ort, des produits électriques ou informatiques, des jouets, des outils de jardinage ou des vêtements. Le terminal du client, présenté dans le schéma 6, inclut une l0 souris 603, laquelle fait bouger la flèche (qui est un curseur de sélection) sur l'image affichée. L'image inclut une icône graphique reprâsentant chaque catégorie disponible. Ainsi, une icône 701 en fornme de r::!-i,:)! de tennis identifie une région adaptée à effectuer un appel aux produits liés au sport. La souris peut être manipulée pour positionner la flèche sur cette icône.15 Ensuite, un bouton-ressort sur la souris peut être pressé pour déclencher une hyper-connexion vers une autre page HTML. La sélection de l'icône sportif par le client résultera automatiquement dans la génération d'un nouveau URL, à son tour fourni au serveur via le réseau, ce qui eLntraîna la fourniture d'une seconde page au client. Similairement, une icône graphique2o 702 d'une perceuse électrique représente la sélection des produits électriques. Si le client place la flèche sur cette icône et presse le bouton- ressort de la souris, une nouvelle page contenant des produits électriques apparaîtra. Cette page peut prendre la forme d'une table dûs ma.ires de deuxième niveau qui permet d'autres sélections. Ainsi, la page suivante peut25 identifier des types particuliers de produits électr!ques: de bricolage, de matériel Hi-Fi etc. Similairement, on peut sélectionner un bouton qui affichera de nouvelles icônes et/ou de nouveaux produits. Par exemple, des produits électriques de bricolage peuvent être encore sub-divises en perceuses, ponceuses, etc. Une troisième icône 703 représente l'image graphique d'un ordinateur et, similairement, la sélection de cette icône provoquera l'apparition d'une table des matières de deuxième niveau qui identifiera des types d'équipement informatique. Une quatrième icône 704 représente la silhouette d'un enfant qui joue, et la sélection de cet icône générera une

nouvelle page par l'activation du serveur.

Une cinquième icône 705 représente deux sacs et symbolise les produits du jardinage. Une sixième icône 706 représente une jeune dame élégante pour identifier la référence aux vêtements. Ainsi, on peut _o sélectionner les icônes 705 et 706 d'une façon similaire, faisant appel au

serveur qui fournira la page en question au client.

Les icônes 701 jusqu'à 706 sont des images graphiques de haute définition et sont conservées sous forme de fichiers ".GIF", bien que d'autres formats graphiques puissent être employés. L'information utilisée pour construire la page est dérivée d'une base de données et toute l'information contenue dans la base de données peut être modifiée pour répondre aux changements dans la disponibilité, le prix des produits, etc.

en utilisant des techniques traditionnelles de gestion de base de donnée.

Précédemment, toutes les pages HTML étaient construites et gardées comme telles, ce qui les rendaient disponibles quand les clients faisaient des commandes. Un tel arrangement est similaire à celui identifié à l'étape

508 dans le schéma 5 o un fichier prédéterminé est fourni à un client.

Dans plusieurs cas, une telle méthode donne une solution parfaitement suffisante. Par exemple, les documents techniques et les livres de références ne changent habituellement pas après avoir été publiés, et l'on peut ensuite consulter ces documents longtemps après. En revanche, les catalogues changent d'habitude au moins toutes les saisons et les vendeurs préféreraient faire des promotions dès qu'ils peuvent conclure des arrangements avec leurs fournisseurs. Evidemment, si le vendeur en ligne ne peut pas répondre aux changements du marché de cette façon, il

21 2735595

serait désavantagé par rapport aux vendeurs traditionnels. Dans d'autres cas, I'espérance de vie des données peut même être plus courte. Ainsi, les magazines sont habituellement mensuels ou hebdomadaires, cependant que la plupart des journaux sont valables seulement pour une journée. De plus, les journaux sont souvent modifiés pendant leur fabrication. Ainsi, il est avantageux pour les éditeurs d'être à-même de renouveler les informations quand les événements changent. Evidemment, quand les nouvelles sont diffusées par des techniques classiques, comme par example la radio, les flash d'information sont continuellement renouvelés, ce qui désavantage la

presse.

Dans le cas présent, les données visibles sont conservées dans une base de données et des signaux sont lus depuis la base de données pour un traitement en combinaison avec des signaux secondaires qui représentant le moyen avec lequel l'information doit être formatée sur la page visible. Dans une configuration possible, le code HTML pourrait être conservé en tant que gabarit, avec des espaces internes réservés pour les données visibles tels qu'en réponse à une commande, les données pourraient être identifiées et mélangées avec les instructions HTML. Cependant, dans l'encadrement favori, une pluralité de fonctions d'exécution20 est fournie au serveur telle qu'en réponse à une commande particulière, une ligne de fonction soit exécutée, provoquant des appels à la base de

données adéquate pour commander et obtenir des renseignements visibles. Ces renseignements sont ensuite traités pour les mélanger avec des marques HTML, ceci afin de produire des signaux de sortie pour la25 transmission au client.

Des instructions HTML pour générer l'image visible montrée sur l'écran 602 sont détaillées dans le schéma 8. La ligne 1 inclut le texte visible ("Les Achats Faits de Chez Soi") et celle-ci a été marquée pour identifier ce mot comme titre du document. A la ligne 2, la marque identifie30 le début du corps du document et dans le corps du document un sous-titre

22 2735595

"table des matières" est affiché, entouré de marques de formatage H1. La ligne 3 consiste en une instruction HTML pour créer une ligne horizontale 700. Les instructions à partir de la ligne 5 créent les icônes 701 à 706 accompagnées des hyper-connexions liées avec les icônes nécessaires pour permettre que les page suivantes soient commandées par un client. Chaque icône est décrite par deux lignes: I'icône 701 est définie par les lignes 5 et 6, l'icône 702 est définie par les lignes 7 et 8, l'icône 703 est définie par les lignes 10 et 11, I'icône 704 est définie par les lignes 12 et 13, l'icône 705 est définie par les lignes 15 et 16 et l'icône 706 est définie par 0o les lignes 17 et 18. L'image visible est construite ligne par ligne, ainsi les instructions procèdent de gauche à droite et de haut en bas. Après l'icône sportive, le mot "sports", I'icône électrique et le mot "électrique" ont été traités, il est nécessaire de créer une nouvelle ligne et des paragraphes sont générés par la marque "P" visible aux lignes 9, 14 et 20. Comme énoncé précédemment, chaque icône de sélection est générée depuis deux lignes, dont la première, par exemple la ligne 5, définit l'hyper-connexion à une autre page par un URL au serveur. L'URL défini à la ligne 5 serait reconnu comme commande pour un traitement en ligne par le serveur. Les paramètres suivants augmentent de 1000 à 1001, à 1002, à 1003

à 1004 et à 1005 pour identifier uniquement la page commandée.

La deuxième ligne pour chaque entrée,par exemple la ligne 6, spécifie la position de l'icône graphique: ainsi, l'icône sportive a été gardée dans un fichier nommé "sport.gif" alors que l'icône électrique définie à la ligne 8 a été gardée comme "elec.gif", I'icône ordinateur a été gardée25 comme "comp.gif", l'icône des enfants comme '"'child.gif", l'icône jardinage comme "gard.gif" et l'icône des vêtements "clth.gif". L'encodage suivant spécifie la position de l'icône dans la page afin de rendre complets les besoins du formatage. Du point de vue du client, I'image montrée sur l'écran 602 ressemble à une image vidéo de haute définition, ceci pour assurer que le client ne soit pas dérouté par le système. Cependant, du point de vue de la transmission, I'image est générée par les instructions présentées dans le schéma 8. Cela nécessite qu'un niveau sophistiqué de traitement soit accompli par le serveur transmettant et par le "browser" recevant, mais la largeur de la bande nécessaire pour transmettre l'information est très réduite. Le signal de sortie consiste en 8 octets de données pour chaque

caractère ASCII représenté dans le schéma 8.

Bien que la largeur de bande nécessitée pour transmettre un fichier _o HTML (voir schéma 8) soit très réduite, lorsque l'on fait la comparaison avec des transmission vidéos on peut s'apercevoir que la génération manuelle de ce type prendrait beaucoup de temps, posant des difficultés économiques pour quelqu'un qui désire utiliser cette technologie afin de distribuer des informations avec une courte espérance de vie. En accord 1s avec le système présent, il est possible que l'information soit dérivée depuis des bases de données traditionnelles et que les instructions HTML soient générées au besoin selon les commandes des clients. Ainsi, la génération d'instructions (voir schéma 8) devient un procédé technique automatique réalisé en réponse aux lignes de fonction générées par les

2 0 codes gardés dans le serveur.

Les pages de sortie HTML sont créées par l'assemblage de fragments d'instructions HTML, afin de créer une page adéquate pour

générer des signaux de sortie (voir schéma 8).

Chaque fragment d'instructions HTML de sortie est créé en exécutant une fonction particulière. Cette fonction est adaptée pour traiter les données d'une ou plusieurs bases de données sous la forme de données visibles. Ces données sont ensuite traitées sous le contrôle de la fonction sélectionnée afin de générer un fragment HTML de sortie. Une fonction de formatage de ce genre peut être considérée comme l'unité la plus réduite des instructions nécessaires pour produire un fragment de

code HTML.

Le système en entier inclut une famille universelle de toutes les fonctions disponibles qui peuvent être utilisées pour générer des fragments de code HTML. Quand le système s'agrandit, des fonctions nouvelles peuvent être ajoutées à la famille et on l'attend que le standard HTML soit amélioré, nécessitant que des fonctions additionnelles soient créées. Pour des applications particulières, il est probable que toutes les fonctions possibles ne seront pas nécessaires, ainsi les fonctions peuvent être sélectionnées à partir des familles universelles de toutes les fonctions o disponibles. Des fonctions sélectionnées sont connues du "browser" et du serveur. Le "browser" envoie des URL au serveur qui sont compris par

celui-ci afin que la page HTML commandée soit renvoyée au "browser".

Il est possible qu'un serveur particulier soit configuré pour faire marcher de nombreuses applications nécessitant une sous-famille de is fonctions de formatage différente, elle-même dérivées d'une famille universelle de fonctions disponibles. Afin d'accomoder cette situation, une procédure d'initialisation est réalisée par les routines de traitement en ligne afin d'assembler les fonctions de formatage nécessitées de façon à

améliorer les vitesses de traitement en ligne.

Les fonctions de formatage sont adaptées pour générer des petits fragments de code HTML tels que la famille universelle de la fonction de formatage est minimalisée, et une page nécessaire de données de sortie peut être générée en liant les fonctions de formatage. Les procédures d'initialisation avant traitement consistent en l'identification des chaînes de fonctions de formatage nécessaires pour générer des lignes particulières de code HTML. Ainsi, une ligne particulière de code HTML est produite en exécutant séquentiellement une ligne de fonction de formatage, et l'étape avant traitement consiste en l'adaptation de ces lignes de fonction telle qu'une ligne particulière adaptée pour générer une page HTML puisse être

3 0 rapidement recherchée et exécutée pendant l'opération en ligne.

Une ligne de fonction générera une ligne particulière de code HTML.

Dans la plupart des applications, toutes les lignes ne prendront pas le même format, il est nécessaire alors de générer une pluralité de lignes de fonctions. Ces lignes sont adaptées dans une liste de lignes avec une flèche d'indication, fournie afin de permettre une ligne de fonction particulière d'être rapidement identifiée sur la liste et ensuite exécutée afin

de générer les instructions HTML de sortie.

L'étape d'initialisation 501 est détaillée dans le schéma 9. A l'étape 901, le système est rendu actif, ce qui peut consister en une application d'énergie au système résultant d'une mise hors- tension/remise en-tension automatique ou en une sélection faite pour réaliser la tâche particulière de préférence à une tâche antérieure. A l'étape 902, le système opérateur est initialisé et le système est configuré pour faciliter des connexions au réseau Internet. Cette initialisation inclut aussi toutes les procédures standard pour charger les conducteurs périphériques etc., ce qui met le

système dans des conditions opérationnelles.

A l'étape 903, des procédures traditionnelles sont exécutées pour initialiser le démon HTTP, puis des procédures sont activées pour initialiser les procédures de traitement en ligne liées aux encadrements

2 o présents.

A l'étape 904, la question de savoir si une autre ligne de fonction doit être générée sur la premiere itération devrait recevoir une réponse positive. A l'étape 905 les fonctions nécessitées pour créer la chaîne particulière, tirée de la série universelle des fonctions disponibles, sont identifiées et au point 906 la chaîne elle-même est assemblée par une suite de listage des fonctions pour le traitement séquentiel, avec les donnéess dérivées d'une ou plusieurs bases de données. Ainsi, au point

906, une chaîne de fonction entière est établie.

Au point 907 la chaîne de fonction générée au point 906 est ajoutée à la liste des chaînes créées pour cette application particulière, et au point 908 une référence d'index est identifiée dans la liste des chaînes. Ainsi, quand un appel particulier est placé pour formater les signaux, sous forme d'une chaîne d'exécution des fonctions, I'appel particulier identifie la référence d'index dans la liste des chaînes et, en conséquence, I'index choisi est sélectionné parmi la liste et est par la suite exécuté

conjointement avec les données référencées.

Par la suite, la commande est retournée au point 904 et cela permet le traitement de la prochaine chaîne de fonction. À la fin, toutes les chaînes de fonction existeront et seront annexées à la liste des chaînes 1o avec un index approprié, et en conséquence la réponse à la question posée au point 904 sera négative et la commande sera alors dirigée vers le point 909. Au point 909, des procédures sont exécutées pour initialiser les bases de données et on peut alors accéder aux données dans les bases de données conformément aux techniques conventionnelles. Les mesures en ligne pour préparer les fichiers, comme identifiés dans la figure 5, sont exposées en détail dans la figure 10. Au point 1001, I'URL qui entre, et qui était jusque-là traité par le démon HTTP comme démontré dans la figure 5, est mémorisé dans une structure des données qui est définie par les traitements en ligne. L' URL embrassera un élément qui identifie les données demandées, un élément qui identifie le type de formatage demandé, les informations concernant l'utilisateur et une

somme de contrôle pour rejeter les URLs altérés pendant la transmission.

Au point 1002 la question est posée en ce qui concerne la validité de la somme du contrôle, et au cas o la réponse serait négative parce que la somme de contrôle n'est pas valide, la commande est alors dirigée vers le point 1009 et, en conséquence, un message d'erreur est retourné

au client qui consulte.

De la même façon, une question est posée au point 1003 en ce qui concerne la validité de l'identification de l'utilisateur. Pour répondre à cette question, il faut faire un appel à une base de données listant les utilisateurs qui renverra une indication en ce qui concerne l'identification de l'utilisateur dans la base de données. Si l'on découvre que l'identité de l'utilisateur n'existe pas couramment dans la base de données, on peut donc promouvoir des routines qui faciliteront le traitement de l'utilisateur comme un utilisateur nouveau et un compte approprié sera ouvert pendant que l'utilisateur reste en ligne. Ainsi, par exemple, ces routines peuvent demander à l'utilisateur de fournir des détails concernant sa carte de crédit

etc. pour ouvrir un compte immédiatement.

De plus, I'analyse de l'identité de l'utilisateur au point 1003 permet I'extraction d'informations supplémentaires de la base de données d'utilisateurs qui se rapportent à cet utilisateur particulier. Si l'identité d'un utilisateur a expiré, la réponse à la question posée au point 1003 peut être négative et en conséquence la commande sera dirigée vers le point 1009,

et un message d'erreur sera dirigé vers le client qui consulte.

_5 Après validation de la somme de contrôle et de l'identité de l'utilisateur, on pose la question au point 1004 en ce qui concerne la validité de l'identificateur de données. Les identificateurs pour les données sont mis en formes établies et si le serveur ne peut pas identifier les données demandées, un message d'erreur sera produit au point 1009. De la même façon, un identificateur pour la mise en forme demandée est validé au point 1005, ce qui peut encore produire un message d'erreur au

point 1009.

Après avoir validé l'identificateur de données et l'identificateur de la mise en forme aux points respectifs, la ou les pages HTML sont produites 2s au point 1006 en ce qui concerne l'identificateur de données et l'identificateur de la mise en forme. Par la suite, en ce qui concerne l'identité de l'utilisateur, les pages sont données en retour à la personne

qui consulte par le réseau. Après avoir donné en retour les pages au client qui consulte, le système

est conscient de ce fait et donc il sait les données alimentées à

28 2735595

un utilisateur à n'importe quelle heure. Dans quelques systèmes, ces données sont considérées comme sans valeur et donc rien de plus ne se passe. Cependant, dans les autres systèmes, particulièrement à l'occasion de ventes de produits, des informations commerciales peuvent être considérées comme de grande valeur, donc on prévoit que ces informations

peuvent être données à la base de données de l'utilisateur au point 1008.

De cette façon, à l'avenir, des informations seront disponibles en ce qui concemrne les préférences des utilisateurs et ces informations peuvent être utilisées pour modifier le fonctionnement du système dans des

0 circonstances particulières.

On se rend compte du fait que, pendant le fonctionnement normal du système, des portions diverses de données seront utilisées à plusieurs occasions. Ainsi, conformément aux techniques conventionnelles, les données lues dans une base de données peuvent être cachées de telle sorte que les données seront davantage disponibles une prochaine fois et que l'on n'aura ainsi pas besoin d'un autre appel à la base de données. Le

système peut être configuré de telle façcon à cacher des données pour une période déterminée d'avance, par exemple trente minutes. Ainsi, si on n'utilise pas les données dans un délai de trente minutes, la mémoire-cache20 peut être nettoyée de telle sorte que, n'importe quand, des données cachées représentent un instantané des utilisateurs qui utilisent le système.

Une représentation schématique de l'unité de traitement 301 conjointement avec son associé RAM 303 (mémoire à accès aléatoire), configurée pour exécuter les instructions de traitement en ligne, est25 démontrée dans la figure 11. Le HTPD 403 est démontré schématiquement sur la gauche de la figure 11 et est arrangé pour alimenter des URLs à une mémoire tampon en entrée URL 1101 et pour recevoir des données HTML en sortie d'une mémoire tampon en sortie HTML 1102. Le processeur en ligne 310 (processeur 301 de la figure 330 arrangé pour exécuter les procédures de traitement en ligne 405 de la figure 4) communique avec la base de données de l'utilisateur 1000 comme démontré dans la figure 10. De plus, le processeur 301 est arrangé pour accéder aux chaînes d'une mémoire des listes des chaînes 1103, pour accéder au texte visible d'une base de données de texte 1104 et pour accéder aux graphiques visibles d'une base de données de graphiques 1105. Chacune des bases de données et la mémoire des listes des chaînes est relationnelle, c'est à dire, qu'un index reconnu par le

processeur 301 se rapporte à une entrée particulière de base de données.

Ainsi, quand le processeur 301 indique un index, les données connexes sont des données en retour au processeur 301. La mémoire des listes des chaînes 1103 inclut une partie de l'index des chaînes 1106 et la partie véritable des listes des chaînes 1107. Des chaînes de fonction sont ajoutées à la partie des listes des chaînes 1107 au point 907 de la figure 9

et leur référence connexe d'index est ajoutée à la partie 1106 au point 908.

is Le processeur 301 fait une demande afin d'identifier une référence particulière d'index qui est mémorisée dans la partie 1106. Cet index se rapporte à une chaîne particulière mémorisée dans la partie 1107. Ainsi, il est possible d'ajuster le rapport entre les indexes et les chaînes et on ajuste la façon de formater les données en réponse à une demande

2 o particulière.

De la même façon, les données de texte dans une base de données de texte 1104 consistent en des données textuelles elles-mêmes dans la partie 1108 et les indexes connexes des données textuelles dans la partie 1109. Ainsi, les données sont choisies dans la base de données 1104 par le processeur en ligne 301 qui délivre un index particulier à la partie 1109, ce qui cause le retour des données connexes de la partie 1108 au processeur en ligne 301. Les indexes sont reconnus par le processeur en ligne 301 et le rapport entre les indexes et leurs données connexes de texte peut être ajusté pour changer les données retournées en réponse à

une demande particulière.

La base de données des graphiques 1105 est également divisée en parties connexes qui constituent la partie d'index 1110 et une partie de données 1111. Ainsi, en réponse à l'identification d'une référence particulière par le processeur en ligne 301 dans la partie 1110, on peut lire les données graphiques de la partie 1111. Comme déjà exposé, une chaîne lue dans la partie 1107 consiste en une chaîne des fonctions d'exécution. Ces fonctions sont envoyées au

processeur en ligne 301 pour exécution sur le processeur mentionné.

L'exécution d'une fonction lue dans la liste des chaînes peut causer les _o écritures directes des onglets HTML à la mémoire tampon HTML en sortie 1102. D'autre part, I'exécution de ces fonctions peut causer un appel à la base de données textuelles 1104 ou à la base de données graphiques 1 111. Dans l'un ou l'autre cas, l'appel identifie un index dans la partie 1109 ou dans la partie 1110, qui cause l'alimentation directe des données connexes textuelles ou des données graphiques à la mémoire tampon

HTML en sortie 1102.

Ainsi, I'entrée URL identifiera des types particuliers de mise en forme et des données. L'information de mise en forme pour l'URL causera la lecture des chaînes particulières de fonction dans la mémoire de la liste des chaînes 1103. Par la suite, ces fonctions sont exécutées en relation avec les identificateurs des données, ce qui occasionne la lecture des données textuelles et des données graphiques dans les bases respectives de données 1104 et 1105. Pendant l'exécution des fonctions, la sortie HTML est écrite à la mémoire tampon HTML en sortie 1102 et, après I'exécution d'une série identifiée des fonctions, la HTML mémorisée dans la mémoire tampon en sortie 1102 est lue pour alimenter les signaux

HTML en sortie au démon HTTP 403.

En plus de l'utilisation de la base de données des utilisateurs pour confirmer la validité de l'utilisateur et pour enregistrer les actions faites par I'utilisateur (peut-être pour des factures), le procédé en ligne 301 doit aussi faire usage de la lecture d'informations de la base de données des utilisateurs dans le but d'ajuster les relations entre les index (1106, 1109,

1110) et leurs fonctions associant liens et données (1107, 1108, 1111).

Ainsi est-il possible pour la machine de traitement de texte de répondre à un URL de trois manières. D'abord, au cours d'un mode d'opération normal, la sortie HTML créée pour répondre aux données URL à traiter restera constante. La base de données des utilisateurs sert simplement à vérifier la validité de l'utilisteur et à enregistrer l'usage du système. Ainsi, la sortie ne dépend pas du type d'utilisateur et chaque 1o utilisateur a accès aux mêmes données. Pourtant, on peut faire des changements progressifs afin de mettre à jour et améliorer les bases de

données selon les circonstances.

Pour acheter de chez soi, la disponibilité des produits et les variations de prix se traduisent selon les bases de données. Parallèment, les bases de données des revues et des journaux qui sont en ligne peuvent être changées pour répondre aux contraintes éditoriales qui sont souvent déterminées par les événements. Il n'est donc pas toujours nécessaire pour les éditeurs de créer un nouveau document HTML s'ils

ont l'intention de distribuer des documents ainsi formatés aux utilisateurs.

Le formatage nécessaire pour créer une page dans ce format est distribué selon les fonctions du formatage. Par exemple, pour mettre à jour une information, un éditeur n'a qu'à mettre à jour les données dans la base de données (d'habitude la base de données 1104) selon les techniques de

bases de données classiques.

Au cours d'un seconde mode d'opération, l'utilisateur peut identifier les renseignements du système pour exprimer ses préférences en tant qu'utilisateur. Par exemple, si l'utilisateur veut acheter de chez lui, il est possible de spécifier le produit auquel il s'intéresse. Il est possible par exemple qu'un utilisateur ne s'intéresse qu'au jardinage. L'utilisateur founit ce renseignement au système et le système donne les renseignements sur le jardinage uniquement. Lors de l'initiation au système, le premier URL (Uniform Resource Locator - Allocation de Ressource Uniforme) donnera une référence pour les produits de jardinage. Ce système aide à éviter le premier écran (voir le diagramme 7) qui intéresse peu le client. Le client sera toujours capable d'accéder à toutes les fonctions disponibles. Par exemple, il y aurait sur le deuxième écran qui montre surtout les produits de jardinage, un lien pour "autres sujets" et en opérant cette saisie, l'utilisateur aurait accès à une page d'un niveau supérieur qui lui permettrait d'accéder à d'autres sujets du catalogue en ligne. Dans un système plus sophistiqué, peut-être l'utilisateur s'intéresse-t-il uniquement à l'appareillage électrique et aux équipements sportifs. Dans ce cas le premier écran montrerait un icône "sports" suivi des sports spécifiques et dans le même temps un icône "appareillage électrique". Ainsi, I'utilisateur peut préciser des préférences pour que le système lui devienne

personnellement ergonomique.

On peut se servir d'une telle méthode dans les publications d'informations. Par exemple, il y a des utilisateurs qui s'intéressent surtout aux pages de finance tandis que d'autres s'intéressent aux sports. Si on a programmé la base de données de façon à suivre les renseignements, l'ordre des pages change selon les préférences de l'utilisateur. Il y aura possibilité de préciser si les sujets sont pour les enfants ou pour les adultes. Les pages destinées aux enfants pourraient être écrites dans un 2 5 style plus simple avec davantage de liens interactifs hypertexte, permettant aux enfants d'accéder aux données ayant rapport à ce qu'ils lisent. Dans beaucoup de situations, il y aurait des pages convenables pour les adultes et les enfants. Dans ce cas, I'éditeur déciderait de la disponiblité des informations. Parallèlement, on pourrait augmenter les

frais pour certains renseignements.

Au cours d'un troisième mode d'opération, d' "apprentissage", il n'est pas nécessaire que l'utilisateur identifie ses préférences pour faire des changements aux pages. Le système enregistre l'histoire de l'usage et les rapports entre les sélections d'un browser et les données qui sont retournées au client. Peut-être un utilisateur ne s'intéresse-t- il qu'aux vêtements. Ayant constaté cet intérêt, les styles de vêtements particuliers auxquels s'intéresse l'utilisateur seront la priorité. Si l'utilisateur s'intéresse uniquement aux grandes marques, le système identifie le renseignement,

puis donne la priorité aux soldes dans ce domaine.

l0 On pourrait créer un endroit sur une page pour donner des renseignements ou des publicités précises. Le type de renseignement dépendrait de l'histoire du client, et le système serait capable d'identifier automatiquement une bonne affaire et le client qui s'intéresserait à cette situation. Quand ce genre d'utilisateur entre en interaction avec le système, les renseignements pertinents lui seront envoyés automatiquement. Parallèlement, une publicité pour une veste de qualité

ne sera pas envoyée à un client qui ne s'intéresse qu'aux ordinateurs.

Le système sera capable d'identifier les situations dans lesquelles on a consulté les produits pendant des périodes importantes. Le système pourrait être programmé pour identifier ceci et puis modifier la situation quand l'utilisateur inter-agit. Par exemple, après avoir identifié qu'un client s'intéresse à un produit, on peut assumer que le client compte l'acheter mais n'a toujours pas décidé. Le système pourrait convaincre le client d'acheter le produit. Ainsi le système pourrait-il être programmé pour donner des renseignements sur les remises au client. Le client croirait que tous les utilisateurs bénéficient des mêmes renseignements. Il est possible alors que le fait que le client s'intéresse particulièrement à ce produit et que ces produits soient devant lui sur l'écran soit considéré par

le client comme une simple coincidence, ce que ce n'est évidemment pas.

Chaque utilisateur recevrait quelque chose que le système aurait choisi selon ses préférences. Les possibilités sont infinies. Les pages HTML sont renvoyés aux utilisateurs par l'index des localisations dans les bases de données. Le rapport entre un index et un produit peut être changé pour que les mêmes instructions puissent être utilisées pour accéder à des données différentes. Le système peut identifier l'utilisateur

concerné et puis sélectionner un index qui diffère de l'index habituel.

Sinon, un index particulier identifié par un utilisateur peut être traité au

hasard, sélectionné selon les renseignements sur l'utilisateur.

Les opérations réalisées par l'ordinateur 301 (voir le diagramme 11) sont expliquées par le diagramme 12. A l'étape 1201 une chaîne est identifiée qui permet au 301 d'appeler une base de données par l'introduction de la chaîne à la base de données pertinente. En 1201 un appel est fait à la base de données pertinente. Ensuite la chaîne est retournée à la base de données de l'ordinateur 301. Alors, si on regarde le diagramme 11, l'opération réalisée en 1201 mène à un ordre de l'ordinateur 301 à l'index 1109 ou à la base de données 1104. Puis les

données de 1108 sont retournées à l'ordinateur 301.

A l'étape 1203 un index de chaîne est identifié lors du formatage des renseignements dans l'URL et à l'étape 1204, l'index de chaîne est lu dans le stockage de la chaîne 1103. A I' étape 1205, la chaîne du

stockage de la chaîne 1103 est réalisée.

* Ceci mène à la réalisation du code reçu pour le tampon HTML 1102 et, à l'étape 1206, une question est posée pour déterminer si une autre chaîne est identifiée. Si la réponse est oui le contrôle est retourné à 1201 et les procédures sont répétées. Finalement, la question posée à l'étape 1206 aura une résponse négative, résultante des procédures à l'étape 1006. Pour la réalisation d'une fonction de chaîne, I'étape 1205 est augmentée sur le diagramme 13. Une chaîne de fonctions est réalisée par

ordre à l'étape 1205.

A l'étape 1301 la prochaine fonction est lue dans la chaîne de fonction. A l'étape 1302 cette fonction est réalisée et mène à la transmission du code HTML au tampon HTML 1102 à l'étape 1303. A l'étape 1304 une question est posée. Si la réponse est positive, le contrôle 5 est restitué à l'étape 1302 pour que la prochaine fonction soit réalisée. Une

étape est considérée comme la part la moins importante d'une fonction qui mène au tampon HTML.

Après toutes les étapes de la fonction, à la question posée à l'étape

1304 la résponse sera négative, et mène à une question à l'étape 1305.

1o Cette question détermine s'il y a une autre fonction dans la chaîne. S'il y a une autre fonction présente dans la chaîne la question posée à l'étape 1305

sera répondue affirmativement et retoumrne le contrôle à I'étape 1301. Les étapes 1301, 1302, 1303 et 1304 sont répétées dans l'ordre pour réaliser la prochaine fonction dans la chaîne, lues dans la liste des chaînes.

Finalement toutes les fonctions dans la chaîne seront réalisées qui et mènent à une question à l'étape 1305. La réponse sera négative pour compléter les procédures dans l'étape 1205. Les fonctions réalisées dans les étapes 1302-1304 seront créées pour produire le code HTML demandé (voir le diagramme 14). La fonction

représentée dans le diagramme 14 sert à produire la première ligne de l'exemple du code HTML.

La première étape (1401) écrit les titres <Head><Title> au début de la première ligne. Ces titres sont écrits au tampon HTML à l'étape 1303,

puis la réponse à la question à l'étape 1303 sera positive, ce qui mène à la25 réalisation d'une fonction à l'étape 1302.

Suivant l'exemple dans le diagramme 14 il faudrait réaliser l'étape 1402 qui consiste à envoyer au tampon HTML des données de "LES ACHATS FAITS DE CHEZ SOI". Cette partie du code est créée en appelant la base de données du texte. L'instruction "écrire" consiste en un index de la base de données. La base de données 1104 est identifiée ainsi que la position de l'index 001. Ainsi, on sait que la position de l'index 001 dans la base de données 1104 a été mise en réserve. Il se peut qu'un éditeur veuille changer le titre original pour "Acheter à la maison". Quand il faut un changement de ce genre, il est simplement nécessaire que l'éditeur change l'entrée de la base de données à la position 001 dans la base de données 1104. Ceci est réalisé au moyen de techniques de base de

données classiques sans besoin d'une connaissance profonde d'lnternet.

L'opération n'est pas changée par ce nouveau titre et la procédure à

o l'étape 1402 sera réalisée comme prévue initialement.

A l'étape 1402 la base de données est identifiée, une adresse est créée et le texte est renvoyé à l'ordinateur 301. Le texte est transporté à la prochaine localisation au tampon HTML 1102 à l'étape 1303 et le contrôle est dirigé vers l'étape 1304, la question est posée pour déterminer s'il y a une autre étape de fonction présente. La réponse sera affirmative, ce qui mène au retour du contrôle à l'étape 1302 afin de réaliser la

prochaine étape.

La prochaine étape consiste en l'étape 1403, qui mène aux titres </TITLE</HEAD> à la sortie de la mémoire-tampon HTML 1102 à l'étape 1303. De nouveau, la question sera posée à l'étape 1304 et la réponse

sera négative, ce qui mènera à la direction du contrôle à l'étape 1305.

Il est évident qu'une fonction mène à trois opérations différentes; un titre,un texte et un titre HTML. Cette procédure est répétée pour chaque fonction dans la chaîne de fonction jusqu'à ce qu'on obtienne une page

entière du code HTML et qu'on ait écrit à la mémoire-tampon HTML 1102.

Les signaux de la mémoire-tampon HTML 1102 sont donnés au démon

HTTP 403 qui donne des signaux aux "browser" via Internet.

Les bases de données pour stocker des textes sont classiques. Le langage SQL est utilisé pour obtenir des données en produisant une

3 0 demande SQL.

Claims (10)

REVENDICATIONS

1. Dispositif permettant de fournir des signaux de sortie depuis un appareil agissant comme centre-serveur à d'autres appareils servant à consulter des données et connectés à un réseau, les signaux de sortie représentant des demandes réalisées par chaque appareil de consultation afin de présenter des informations selon un format de page précis; le dispositif étant caratérisé par: des moyens d'identification des demandes de consultation issues des clients qui désirent des renseignements précis en format précis, des moyens pour traiter les données, des moyens pour la représentation des données utilisant des instructions simples, ainsi que

des moyens pour fournir des signaux de sortie à l'appareil de consultation de données après traitement des données requises.

2. Le dispositif de la revendication 1 en liaison avec le réseau Intemet.

3. Le dispositif des revendications 1 et 2 dans lequel les ordres sont

en langage hypertexte.

4. Le dispositif des revendications 1 à 3 dclans lequel les données sont en texte ou en diagramme.

5. Le dispositif des revendication 1 a 4 dans lequel les données sont lues à partir de bases de données classiques.

6. Le dispositif des revendication 1 à 5 dans lequel les données sont identifiées par un index dans une base de données.

7. Le dispositif de la revendication 6 dans lequel les données d'une base de données peuvant être modifiées.

8. Le dispositif des revendications 1 à 7 dans lequel les moyens de

traitement de données comprennent des moyens d'élaboration d'instructions pour des entrées de données précises et des instructions de formatage précises.

9. Le dispositif de la revendication 8 dans lequel les instructions sont lo dans un index et dans lequel le rapport entre les instructions et un index peut

être modifié.

10. Le dispositif des revendications 1 à 9 dans lequel les moyens sont prévus pour changer un rapport entre une demande précise et une chaîne

séquentielle précise de fonctions parmi une liste de fonctions disponibles.