Brevet FR2802373A1 — publié le 20010615

CONTEXTE DE L'INVENTION Domaine technique La présente invention concerne d'une manière générale le domaine informatique et en particulier les environnements informatiques collaboratifs. Plus précisément, présente invention concerne des systèmes et des méthodes pour personnaliser la qualité des services (ci-après appelée fournis à des clients dans un environnement informatique collaboratif. 2. Description de l'état actuel de la technique Les environnements informatiques collaboratifs utilisent généralement une architecture client/serveur dans laquelle un ou plusieurs systèmes informatiques font office de serveurs, fournissant des ressources à un ou plusieurs autres systèmes informatiques qui font office de clients. Un des principaux avantages de cette architecture de réseau est qu'elle permet à des clients qui ont besoin de certaines ressources de les obtenir sur les serveurs. L'Internet par exemple, est un réseau client/serveur doté d'un grand nombre de serveurs web qui fournissent des ressources telles des pages web à des clients (c'est à dire des systèmes informatiques exécutant des logiciels clients) à la demande de ceux-ci. Actuellement, des entreprises et autres organismes fournissent couramment des informations et/ou autres services (p. ex., des services de vente) au public via des serveurs web. Un serveur web est un système informatique est connecté à un réseau tel que l'Internet et qui fournit des informations ou des services à d'autres systèmes informatiques à leur demande. Cependant, un inconvénient du paradigme client/serveur est qu'un serveur ne peut répondre à un nombre limité de demandes de services simultanées avant que ses performances se dégradent notablement. Un certain nombre de stratégies ont été proposées pour répondre problème de la surcharge des serveurs, compris des stratégies qui prennent en compte le fait que souvent, les organismes ne gèrent pas leurs propres serveurs web mais achètent ou reçoivent gratuitement les services d'hébergement un fournisseur d'hébergement de contenus (ci-après appelé un "hébergeur"). Par exemple, une telle stratégie permet de remplacer le transmetteur de demandes séquentiel classique des serveurs (avec lequel les demandes sont traitées ordre de réception) par un transmetteur classe les demandes en fonction du fait qu'elles nécessitent l'accès aux ressources d'un client payant de l'hébergeur ou d'un client qui reçoit des services d'hébergement complémentaires. Les stratégies établies en fonction des serveurs telles que celle-ci (c'est à dire les stratégies qui classent les demandes selon les caractéristiques de la ressource fournie) offrent des avantages en ce sens qu'elles permettent aux hébergeurs de personnaliser la QS proposée en fonction des ressources. En revanche, de telles stratégies ne permettent pas aux serveurs de personnaliser la QS fournie en fonction des clients (c'est à dire en fonction des caractéristiques des clients qui font la demande). La présente invention tient compte du fait que organismes considèrent souvent que les demandes de certains clients sont plus importantes que celles d'autres clients même lorsque ces demandes impliquent les mêmes ressources. Par exemple, si une compagnie aérienne qui vend des billets sur Internet reçoit deux demandes d'information sur les prix, une émanant d'une personne inconnue de la compagnie et l'autre d'un client qui a déjà acheté des billets de classe affaires, la compagnie peut préférer traiter la deuxième demande avant la première. Toutefois, les serveurs et les clients du web utilisent généralement le protocole Hypertext Transfer Protocol (HTTP), or ce protocole est non persistant (ou sans état). Autrement dit, HTTP ne fournit pas de contexte permettant d'identifier les demandes successives d'un même client. Au contraire, les serveurs web établissent une nouvelle connexion pour chaque demande, même si les demandes concernent des eléments de contenu (tels que du texte et des images) qui peuvent être affichés sur une même page web. Un autre protocole utilisé par certains serveurs et clients web, le HTTP persistant (P-HTTP), conserve suffisamment d'informations d'état pour permettre aux clients et aux serveurs d'utiliser une seule connexion pour plusieurs demandes liées entre elles (telles que toutes les demandes concernant des infirmations figurant sur une même page web). Toutefois, P-HTTP permet aux serveurs et aux clients de fermer la connexion unilatéralement, auquel cas plusieurs demandes liées entre elles peuvent nécessiter de multiples connections bien que P-HTTP soit utilisé. De plus, comme HTTP, P-HTTP ne conserve pas 'état sur plusieurs sessions d'interaction séparées. Par "session d'interaction" on entend ici un ensemble de demandes d'un client impliquant en ensemble de ressources de serveur liées entre elles (telles que des pages web d'un site donné) et les réponses correspondantes. La session commence lorsque le client transmet demande initiale impliquant des ressources liées entre elles. La session se termine, par exemple, lorsque le client commence à communiquer avec un autre site web ou quitte navigateur web. Comme indiqué plus haut, même avec P-HTTP, session peut nécessiter plusieurs connections. Les protocoles de communication tels HTTP et P-HTTP ne conservant pas les informations d'état d' session à l'autre, il est plus difficile d'établir un système de priorité en fonction des clients sur des réseaux qui utilisent de tels protocoles que sur des réseaux qui utilisent des réseaux à état (p. ex. des protocoles qui conservent des informations d'état permettant d'identifier des clients même après que leurs demandes aient été satisfaites). Toutefois HTTP offre aux serveurs la possibilité d'enregistrer des blocs de données ("témoins") sur les clients, les données enregistrées étant renvoyées automatiquement aux serveurs lors des demandes ultérieures de ces clients. Le Microsoft Press Computer Dictionary, troisième édition, donne la définition suivante du "témoin" . un bloc de données qu'un serveur web enregistre sur systeme client. Lorsqu'un utilisateur revient sur le même site web, le navigateur renvoie une copie du témoin au serveur. Les témoins sont utilisés pour identifier les utilisateurs, ordonner au serveur d'envoyer version personnalisée de la page web demandée, envoyer des informations de compte à l'utilisateur et effectuer d'autres tâches administratives (déf. 2). Ainsi, en utilisant des témoins, un serveur web peut créer contexte lui permet d'identifier une demande d'un client comme étant liée à des demandes antérieures du même client. Comme l'indique la définition citée ci-dessus, les témoins sont actuellement utilisés pour influencer le contenu fourni à client par un serveur web. A l'inverse, la présente invention utilise des outils de création de contexte tels que témoins, pour influencer la qualité des services offerts à client, par exemple en réservant aux demandes clients privilégiés un traitement préférentiel par rapport demandes des clients moins importants ou inconnus. RESUME DE L'INVENTION Pour répondre aux insuffisances des techniques classiques de traitement des demandes sur réseau, la présente invention propose une méthode, un système et un programme dans lesquels un indice de priorité est transmis à un premier client en réponse à une première demande de celui-ci. Une deuxième demande de ce premier client qui contient indice priorité et une troisième demande émanant d' deuxième client sont ensuite reçues par le serveur. Ensuite, le serveur réserve à la deuxième demande un traitement préférentiel par rapport à la troisième demande fait de 'indice de priorité de la deuxième demande. Dans version préférentielle, l'indice de priorité est transmis au premier client dans un témoin HTTP. Tous les objets, caractéristiques et avantages de la présente invention ressortent de la description détaillée ci-après. La figure 1 représente le schéma fonctionnel d'une version donnée à titre d'illustration d'un serveur doté de fonctions pour personnaliser la en fonction des clients conformément à la présente invention. La figure 2 est le schéma des logiciels du serveur représenté sur la figure 1. La figure 3 représente exemple d'environnement informatique collaboratif correspondant à la présente invention. La figure 4 représente organigramme logique d'un exemple de processus, correspondant à la présente invention, pour attribuer des indices de priorité aux demandes en fonction des clients. La figure 5 représente organigramme logique d'un exemple de processus pour afficher les demandes de services à satisfaire en priorité conformément à la présente invention. Enfin, la figure 6 représente l'organigramme logique d'un exemple de processus de réponse aux demandes transmises conformément à la présente invention. DESCRIPTION DETAILLEE DE LA VERSION DONNEE A TITRE D'ILLUSTRATION ce qui concerne maintenant les figures, et plus particulièrement la figure 1, celle-ci représente le schéma fonctionnel d'un serveur 100 doté de fonctions, conformément à la présente invention, pour personnaliser la qualité des services fournis en fonction des clients. Comme on le voit, le serveur comprend un bus système 210 qui est connecté à au moins unité centrale (C PU) 212 et à des mémoires, dont une mémoire morte (ROM) 214 et une mémoire vive (RAM) 216. Le bus système 210 est couplé à un bus local PCI 218 par une passerelle PCI 220. Le bus local PCI 218 est connecté à d'autres unités de stockage de données rémanentes telles qu'une ou plusieurs unités de disque 222, et à un adaptateur audio 230 et un adaptateur graphique 232 pour contrôler respectivement la sortie audio avec un haut-parleur et la sortie vidéo avec un moniteur 236. Une passerelle bus PCI-ISA, telle qu'une passerelle bus d'extension 238, relie le bus local PCI 218 à un bus ISA 240, lequel est relié (par des adaptateurs appropriés) à un clavier 242 et une souris 244 pour recevoir les entrées de l'opérateur. Le serveur 100 comprend aussi des ports données pour communiquer avec les équipements extérieurs tels que d'autres systèmes informatiques. Ces ports de données comprennent, sans que cela soit limitatif, un port série 250 connecté au bus ISA 240 pour relier le serveur 100 aux systèmes informatiques distants via un dispositif de communication de données tel qu'un modem (non représenté) ou une unité de service de canal/unité de service de données (CSU/DSU) (non représentée). Ces ports de données peuvent aussi comprendre un adaptateur de réseau 252 connecté au bus PCI 218 pour relier le serveur 100 à d'autres postes d'un réseau local (LAN) (non représenté). Le serveur 100 contient aussi des programmes et des données qui sont enregistrés sur les unités de stockage de données telles une unité de disque 222. Les programmes sont récupérés les unités de stockage de données, chargés dans la RAM et exécutés par la CPU 212 pour effectuer différentes fonctions. Sur la version représentée, le serveur 100 est un serveur web. Par conséquent, les programmes du serveur 100 comprennent un programme serveur 260 gère l'échange de données entre le serveur 100 et autres systèmes informatiques. Les données comprennent site web (ci-après appele "le site web Acme") doté d'une ou plusieurs pages web qui permettent aux gens de consulter les prix des billets et d'acheter des billets Acme Airline sur Internet. Comme nous le verrons de manière plus détaillée ci-après, le programme serveur 260 comprend un dispositif d'entrée 262 pour recevoir des messages (tels que des demandes de ressources) de systèmes informatiques distants, une file d'attente 263 pour stocker les demandes reçues et un gestionnaire de priorité 264 pour affecter un indice de priorité à ses demandes en fonction des clients. En outre, le programme serveur 260 comprend un transmetteur 266 qui transmet les demandes de services selon leur niveau de priorité respectif, et un ou plusieurs processus élémentaires 268 qui satisfont les demandes transmises et renvoient des réponses aux systèmes informatiques distants. La figure 2 représente le schéma des logiciels du serveur 100. Au sommet du schéma se trouvent les programmes d'application 310, y compris le programme serveur web 260. Au milieu se trouve une interface de programmes d'application (API) 320 par laquelle les programmes d'application 310 demandent des services au système d'exploitation 330. Le système d'exploitation 330 qui occupe le bas schéma gère les opérations du serveur 100 en effectuant opérations telles que l'attribution des ressources, la gestion des tâches et la détection des erreurs. Le système d'exploitation 330 contient aussi des outils pour gérer les communications entre le serveur 100 et les systèmes informatiques distants (tels les clients 110a et 110b de la figure 3). Le système exploitation 330 contient aussi un noyau 332 qui gère la mémoire, les fichiers et les périphériques du serveur 100. Au bas du schéma se trouvent aussi des gestionnaires de périphérique, tels qu'un gestionnaire de clavier 340, un gestionnaire de souris 342 et un gestionnaire réseau 344, que le noyau 332 utilise pour gérer les entrées sorties des periphériques et des ports de communication. La figure 3 représente un exemple d'environnement informatique collaboratif ou de réseau conforme à la présente invention qui comprend un serveur 100. Le réseau de la version représentée comprend aussi deux clients 110a et 110b sont connectés au serveur 100 via des moyens de communication 120 (tels que des paires de câbles torsadées, des câbles coaxiaux, des lignes téléphoniques, des liaisons par micro-ondes et/ou des liaisons radio) et un système informatique intermédiaire tel qu'un serveur Internet ("ISP") 130. Sur la version représentée, chacun des clients 110a et 110b comprend un navigateur web avec des fonctions pour recevoir et enregistrer des témoins des serveurs web et les leur renvoyer. En outre, le client 110a contient un "témoin propriété" du site web Acme, contrairement au client 110b. "témoin de priorité", on entend ici un bloc données qui est (ou est supposé) enregistré dans un client qui contient un nom et/ou une valeur qui seront inclus dans les demandes ultérieures de ce client et qui pourront être identifiés un serveur comme indiquant un niveau de priorité pour demandes ultérieures. Sur la version représentée, le programme serveur 260 utilise des témoins de priorité contenant des indices de priorité de "1" à "8" ("8" étant le niveau de priorité supérieur). Le témoin de priorité du client 110a qui contient un indice de priorité (p ex., la valeur "8") a été reçu (conformément au processus décrit ci-après pour les étapes 640 à de la figure 6) en réponse à l'achat d'un billet sur le site web Acme lors d'une précédente session d'interaction avec ce site. La figure 4 représente l'organigramme d'un exemple de processus, correspondant à la présente invention, pour attribuer des indices de priorité aux demandes en fonction des clients sur le serveur 100. Ce processus commence au bloc 510 lorsque le serveur 100 exécute le programme serveur 260, lequel prépare la réception des demandes des clients initialisant la file d'attente 263 et les processus élementaires 268, au bloc 512. Le processus entame ensuite boucle d'entrée dans laquelle les demandes des clients sont reçues, affectées d'un indice de priorité et placées dans la file d'attente 263 en attendant d'être traitées. Cette boucle d'entrée commence au bloc 520 dans lequel le dispositif d'entrée 262 reçoit la demande d'un client. Le processus passe ensuite au bloc 530 dans lequel le gestionnaire de priorité 264 examine la demande pour déterminer si elle contient un témoin de priorité. si demande provient du client 110b, celui-ci ne contenant pas de témoin de priorité (réponse NON au test 530) pour le serveur la demande n'en contient pas non plus. Par conséquent, processus passe ensuite au bloc 532 dans lequel le gestionnaire de priorité 264 attribue l'indice de priorité plus faible (c'est à dire "1") à la demande. En revanche, la demande provient du client 110a (réponse OUI au test 530), la demande contient un témoin de priorité et le processus passe donc du bloc 530 au bloc 540. Au bloc 540, le gestionnaire de priorité 264 examine l'indice de priorité témoin pour déterminer si cette valeur est valide. Si elle l'est , le gestionnaire de priorité 264 attribue l'indice de priorité le plus faible à la demande, au bloc 532. Sinon, la demande conserve l'indice de priorité du témoin, au bloc 542. Sur la version représentée, le programme serveur 260 représenté sur la figure 1 place toutes les demandes dans la file attente 263 pour qu'elles y soient transmises et traitées selon les processus décrits ci-dessous à propos des figures 5 et 6. La file d'attente 263 est organisée par ordre de priorité et par âge, les demandes dotées d'un niveau de priorité élevé étant placées devant (c'est à dire plus près de la tête de la file d'attente) les demandes de niveau de priorité plus faible. Parmi les demandes d'un même niveau de priorité, les demandes récentes sont placées derrière les plus anciennes. Lorsque les demandes sont placées dans la file d'attente 263, elles ne contiennent plus de témoins de priorite; cependant, chaque demande est placée dans la file d'attente 263 dans le cadre d'une nuplet (ou structure de données) qui contient aussi l'indice de priorité de cette demande Après avoir déterminé l'indice de priorité qui doit être associé à la demande, le programme serveur 260 détermine s'il y a un emplacement libre dans la file d'attente 263, au bloc 550. Si c'est le cas, le programme serveur 260 place demande et son indice de priorité dans l'emplacement libre met cet emplacement devant toutes les demandes de niveau de priorité inférieur (le cas échéant) et derrière les demandes de même niveau plus anciennes (le cas échéant), au bloc En revanche, s'il n'y a pas d'emplacement libre dans la file attente 263 - réponse NON au bloc 550 - le processus passe bloc 554 dans lequel le programme serveur 260 détermine si un emplacement contient une demande de niveau de priorité inférieur, en commençant par la demande plus récente du niveau de priorité le plus bas. S'il trouve un emplacement de niveau de priorité inférieur, le programme serveur 260 libère cet emplacement en supprimant la demande qu'il contient, comme le montre le bloc 556. Le programme serveur utilise ensuite l'emplacement libéré pour mettre la demande et son indice de priorité à une place appropriée dans la file d'attente 263, comme le montre le bloc 552 et comme indiqué plus haut. En revanche, s'il ne trouve pas d'emplacement de niveau de priorité inférieur, le programme serveur supprime la demande, comme le montre le bloc 560. Au bloc 570, une fois que la demande a été ajoutée à la file d'attente 263 ou supprimée, le système détermine si le programme serveur 260 doit s'arrêter (p. ex., en réponse aux instructions d'un administrateur de système). Si c'est le cas, (réponse OUI au bloc 570), le programme serveur 260 effectue différentes opérations de nettoyage, telles que l'arrêt processus élémentaires 268, et le processus se termine, comme le montre le bloc 580. Sinon, le processus revient bloc 520 pour recommencer la boucle d'entrée. La figure 5 représente un exemple de processus de transmission de demandes dotées d'un indice de priorité. Ce processus, qui se déroule en général quasiment simultanément avec le processus représenté sur la figure 4, commence au bloc 710, avec l'exécution du programme serveur 260 dans le serveur 100. Le processus passe ensuite au bloc 720 dans lequel le transmetteur 266 détermine si la file d'attente 263 contient des demandes. Si la file d'attente est vide - réponse NON au bloc 720 - le transmetteur répète l'opération de détermination décrite au bloc 720 attendant qu'une demande soit placée dans la file d'attente Sinon - réponse OUI au bloc 720 - le processus passe bloc 730 dans lequel le transmetteur 266 détermine si des processus élémentaires 268 sont disponibles. Si aucun processus élémentaire 268 n'est disponible - réponse OUI au bloc 720 - transmetteur 266 répète l'opération de détermination décrite au bloc 730 en attendant qu'un processus élémentaire 268 devienne disponible. Dans le cas contraire - réponse NON au bloc 720, le processus passe au bloc 750 dans lequel le transmetteur envoie la demande en tête de la file d'attente 263, vers processus élémentaire 268 disponible. Si un processus élémentaire 268 doté d'un niveau de priorité de système d'exploitation correspondant à l'indice de priorité de la demande à transmettre est disponible, le transmetteur 266 le sélectionne. Sinon, le processus élémentaire 268 disponible doté du niveau de priorité de système d'exploitation le plus faible est sélectionné. De plus, lorsqu'il transmet la demande, le transmetteur 266 joint de préférence l'indice de priorité de celle-ci comme entrée dans le processus élémentaire 268 sélectionné. Ce processus élémentaire 268 traite ensuite la demande transmise comme indiqué ci-après à propos de la figure 6. De préférence, le programme serveur 260 utilise plusieurs processus élémentaires 268 de traitement pour chaque CPU du serveur 100, de manière à ce que, si une instruction est bloquée sur un processus élémentaire 268 (p. ex., en attente d'une E/S), la CPU puisse traiter les instructions sur un autre processus élémentaire 268. En outre, le programme serveur 260 associe de préférence un ou plusieurs processus élémentaires 268 avec chaque indice de priorité et attribue niveau de priorité de système d'exploitation à chaque processus élémentaire 268 qui correspond à l'indice priorité avec lequel ce processus élémentaire 268 a associé. Par exemple, le processus élémentaire(s) associé(s) avec l'indice de priorité "2" peut/peuvent avoir un niveau de priorité de système d'exploitation supérieur à celui du/des chemin(s) 268 associé (s) avec l'indice de priorité "1". Une fois que la demande a été transmise, le transmetteur 266 marque l'emplacement de celle-ci comme vide et la place en queue de la file d'attente 263, au bloc 752 Ensuite, au bloc 760, le système détermine si le programme serveur 260 doit s'arrêter,( auquel cas le processus termine, au bloc 770. Sinon - réponse NON au bloc 760 processus revient au bloc 720 pour commencer à traiter la demande suivante en tête de la file d'attente 263. La figure 6 représente un exemple de processus de traitement des demandes transmises selon la présente invention. Le processus commence au bloc 610, le transmetteur 266 ayant transmis une demande à un chemin 268 disponible, bloc 750 de figure 5. Le processus passe ensuite au bloc 620 dans lequel le chemin 268 détermine si son niveau priorité de système d'exploitation correspond à l'indice priorité de demande. Si les deux niveaux de priorité ne coïncident - réponse NON au bloc 620 - le processus passe au bloc 622 dans lequel le chemin 268 ajuste son niveau de priorité de système d'exploitation à l'indice de priorité, appelant le système d'exploitation par l'API. Une fois que les niveaux de priorité sont mis correspondance (ou déterminés pour coïncider) - réponse OUI bloc 620 - le processus passe au bloc 640 dans lequel chemin 268 traite la demande. Selon la nature des services demandés, le chemin 268 peut traiter la demande directement indirectement à l'aide d'un agent de service. S'il utilise agent de service, le chemin 268 sélectionne et configure celui-ci en fonction de la nature des services demandés l'active, puis reçoit un résultat. Lorsqu'il configure un agent de service, le chemin 268 lui communique le niveau de priorité. Par exemple, si une demande dotée d'un indice de priorité "8" nécessite un appel à une base de données, le chemin 268 fait en sorte que l'appel à la base de données soit associé avec un niveau de priorité que le moteur de la base de données reconnaîtra comme élevé (ou le plus élevé), et donnera à la demande la priorité sur des demandes dotées d'indices de priorité plus faibles. Une fois qu'il a obtenu un résultat, directement ou à l'aide d'un agent de service, le chemin 268 calcule un nouvel indice de priorité pour le client en fonction de la nature de la demande traitée et/ou de son résultat, au bloc 650. Par exemple, les demandes peuvent être réparties classes d'interaction (p. ex., affichage seulement de classe économique ou de classe affaires pour les demandes sans achat achat de billets de classe économique et achat de billets de classe affaires), et le chemin 268 peut déterminer nouveaux indices de priorité en fonction de la classe d'interaction de la demande traitée. Au bloc 660, le chemin 268 détermine ensuite si nouvel indice de priorité correspond à l'indice d'origine. Si c'est le cas, (réponse OUI au bloc 620), le chemin 268 renvoie simplement le résultat au client, au bloc 670. En revanche, si le nouvel indice de priorité est différent de l'indice d'origine - réponse NON au bloc 660 - le chemin 268 joint au résultat un témoin de priorité portant le nouvel indice de priorité, au bloc 662, avant de renvoyer le résultat au client, au bloc 670. Par exemple, si la demande traitée est une demande d'achat de billet de première classe provenant du client 110b (au quel cas, 1a demande ne contient pas d'indice de priorité), le programme serveur 260 peut renvoyer une réponse comprenant un message confirmant la vente du billet et un témoin de priorité contenant un indice "8". Au bloc 680, une fois que le chemin 268 a transmis 1e résultat au client, il est marqué comme disponible. Le processus se termine alors, au bloc 690. Comme nous l'avons vu, la présente invention propose un système de priorité en fonction des clients, sur un réseau utilisant des protocoles de communication persistants et non persistants Les niveaux de priorité sont établis en mémorisant des indices de priorité sur les clients leurs demandes ultérieures contenant ces indices de priorité mémorisés. Bien que l'invention ait été plus particulièrement représentée et décrite en se référant à une version donnée à titre d'illustration, les spécialistes comprendront que diverses modifications de forme et de détail peuvent être apportées sans trahir l'esprit ni sortir de l' et de l'invention exemple, la version représentée et décrite comprend une file d'attente et des processus élémentaires, mais d'autres versions de la présente invention pourraient tout aussi bien avoir des configurations différentes telles que plusieurs files d'attente dont chacune serait consacrée à une ou plusieurs classes de priorité. De même, autres versions pourraient utiliser différentes stratégies de transmission, par exemple en vidant d'avance les processus élémentaires contenant des demandes de faible niveau de priorité lorsque des demandes de plus haut niveau de priorité sont reçues, en utilisant plusieurs transmetteurs et/ou en déterminant si des demandes de haut niveau de priorité ont été reçues après avoir déterminé qu'un chemin est devenu disponible mais avant de transmettre une demande à ce chemin pour la traiter. Par ailleurs, bien que certains processus transmission des demandes et de traitement des demandes transmis aient été décrits à titre d'illustration, la présente invention pourrait utiliser d'autres processus dans lesquels par exemple, le transmetteur et les processus élémentaires seraient intégrés de telle sorte que les processus élémentaires sélectionneraient eux-mêmes les demandes dans la file d'attente. De même, bien que le serveur de la version donnée à titre d'illustration soit décrit comme un ordinateur personnel, la présente invention pourrait aussi bien être appliquée sur d'autres types de serveurs tels que, sans que cela soit limitatif, des mini-ordinateurs ou des gros ordinateurs. De plus, certaines opérations de la présente invention ont été décrites comme étant exécutées par programmes, notamment par un dispositif d'entrée 262, gestionnaire de priorité 264, un transmetteur 266 et processus élémentaires 268, chacun étant décrit comme élément du programme serveur 260. Or les spécialistes comprendront que certaines ou la totalité des opérations décrites pourraient être exécutées par des éléments séparés du programme serveur 260, qu'ils soient appliqués sous forme logiciels, de matériels, de micro logiciels ou d' combinaison des trois catégories. I1 faut également comprendre que la présente invention n'est pas limitée aux communications par Internet HTTP/P-HTTP, mais pourrait aussi bien bénéficier d'environnements informatiques collaboratifs utilisant d'autres protocoles. De même, alors que la version donnée à titre d'illustration utilise des témoins HTTP pour conserver les indices de priorité des clients, d'autres versions destinées à d'autres protocoles pourraient utiliser des mécanismes similaires mais non identiques pour conserver les indices priorité des clients. En outre, alors que la version donnée à titre d'illustration décrit des témoins contiennent des valeurs de sécurité non cryptées (p. , "8"), d'autres versions de la présente invention pourraient crypter indices de priorité avant de les mémoriser sur clients. Enfin, alors que certains aspects de la présente invention ont été décrits en se référant à un systeme informatique exécutant un programme qui dirige les fonctions de la présente invention, il faut comprendre que la présente invention pourrait être appliquée sous la forme d'un programme à utiliser avec un système informatique. Les programmes définissant les fonctions de la présente invention peuvent être transmis à un système informatique par divers supports de signaux tels que, sans que cela soit limitatif, des supports de stockage non réinscriptibles (p. ex., un CD-ROM), supports de stockage réinscriptibles (p. ex., une disquette une unité de disque dur) ou des moyens de communication tels que des réseaux numériques ou analogiques. Il faut comprendre, par conséquent, que de tels supports de signaux transportant ou cryptant des instructions lisibles par ordinateur qui dirigent les fonctions de la présente invention représentent d'autres versions possibles de la présente invention. Revendications 1. Une méthode utilisée dans un environnement informatique collaboratif pour personnaliser la qualité des services en fonction clients, comprenant les opérations suivantes transmission d'un indice de priorité par un serveur à un premier client en réponse à une première demande dudit premier client, reception d'une deuxième demande dudit premier client et d'une troisième demande d'un deuxième client, ladite deuxième demande contenant ledit indice de priorité, et fourniture à ladite deuxième demande d'un traitement préférentiel par rapport à ladite troisième demande, du fait dudit indice de priorité de ladite deuxième demande. 2. Une méthode conforme à la revendication 1, l'opération de transmission dudit indice de priorité audit premier client comprenant la transmission dudit indice de priorité lors d' première session d'interaction entre ledit premier client et ledit serveur, de telle sorte que ledit premier client renvoie ledit indice de priorité audit serveur lors d'une ou plusieurs sessions interaction ultérieures entre ledit premier client et ledit serveur. 3. Une methode conforme à la revendication 2, selon laquelle ledit serveur est un serveur web utilisant un protocole Hypertext Transfer Protocol, et ladite opération de transmission dudit indice de priorité audit premier client comprend la transmission dudit indice de priorité dans un témoin Hypertext Transfer Protocol. 4. Une méthode conforme à la revendication 1 comprenant en outre la sélection dudit indice de priorité pour transmettre audit premier client en fonction d'une plusieurs transactions demandées par ledit premier client. 5. Une methode conforme à la revendication 4, selon laquelle ou plusieurs transactions comprennent une transaction commerciale entre un utilisateur dudit premier client et un vendeur, et ladite opération de sélection dudit indice de priorité pour le transmettre audit premier client comprend sélection dudit indice de priorité en fonction d'une plusieurs caractéristiques de ladite transaction commerciale. 6. Une méthode conforme à la revendication 1, selon laquelle ledit indice de priorité est un premier indice de priorité, ladite méthode comprend en outre la transmission d'un deuxième indice de priorité audit deuxième client réponse à une précédente demande dudit deuxième client reçue avant ladite troisième demande, et ladite opération de fourniture à ladite deuxième demande d'un traitement préférentiel comprend la fourniture a ladite deuxième réponse d'un traitement préférentiel en fonction, respectivement, desdits premier et deuxième indices de priorité desdites deuxième et troisième demandes. 7. Une méthode conforme à la revendication 1, selon laquelle ladite opération de fourniture à ladite deuxième demande d'un traitement préférentiel comprend la transmission de ladite deuxième demande à satisfaire avant la transmission de la troisième demande. 8. Une méthode conforme à la revendication 1, selon laquelle ladite opération de fourniture à ladite deuxième demande d'un traitement préférentiel comprend la transmission dudit indice de priorité à un agent de service pour ladite deuxième demande. 9. Un serveur doté de fonctions pour personnaliser qualité des services fournis dans un environnement informatique collaboratif en fonction des clients, ledit serveur comprenant les éléments suivants un chemin de traitement qui transmet un indice priorité à un premier client en réponse à une première réponse dudit premier client, dispositif d'entrée qui reçoit une deuxième demande dudit premier client et une troisième demande d'un deuxième client, ledit deuxième client contenant ledit indice de priorite, et transmetteur qui provoque le traitement préférentiel de ladite deuxième demande par rapport à ladite troisième demande, en fonction dudit indice de priorité ladite deuxième demande. 10. Un serveur conforme à la revendication 9, ledit chemin traitement transmettant ledit indice de priorité audit premier client lors d'une première session d'interaction entre ledit premier client et ledit serveur, de telle sorte que ledit premier client renvoie ledit indice de priorité audit serveur lors d'une ou plusieurs sessions d'interaction ultérieures entre ledit premier client et ledit serveur. 11. Un serveur conforme à la revendication 10, ledit serveur étant un serveur web utilisant un protocole Hypertext Transfer Protocol;, et ledit chemin de traitement transmettant ledit indice priorité audit premier client dans un témoin Hypertext Transfer Protocol. Un serveur conforme à la revendication 9, ledit chemin de traitement sélectionnant ledit indice de priorite en fonction une ou plusieurs transactions demandées par ledit premier client. Un serveur conforme à la revendication 12, Ladite/lesdites transactions comprenant une transaction commerciale entre un utilisateur dudit premier client et un vendeur, et ledit chemin de traitement sélectionnant ledit indice de priorité en fonction d'une plusieurs caractéristiques de ladite transaction commerciale. 14. Un serveur conforme à la revendication 9, ledit indice de priorité étant un premier indice de priorité, ledit chemin de traitement transmettant un deuxième indice de priorité audit deuxième client en reponse à une précédente demande dudit deuxième client reçue avant ladite troisième demande, et ledit transmetteur provoquant le traitement préférentiel de ladite deuxième demande en fonction, respectivement, desdits premier et deuxième indices de priorité desdites deuxième et troisième demandes. 15. Un serveur conforme à la revendication 9, ledit transmetteur provoquant le traitement préférentiel ladite deuxieme demande en transmettant ladite deuxième demande à satisfaire avant de transmettre ladite troisième demande. 16. serveur conforme à la revendication ledit transmetteur provoquant le traitement préférentiel de ladite deuxième demande en transmettant ledit indice de priorité à un agent de service pour ladite deuxième demande 17. Un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.