FR2926153A1 - Procedes et dispositifs de synchronisation, dans un reseau de communication, pour applications de type vente aux encheres en temps reel. - Google Patents

Abstract

L'invention concerne des procédés et des dispositifs de synchronisation pour la mise en oeuvre d'application du type ventes aux enchères à travers un réseau de communication au moyen d'un serveur et d'au moins un poste client. Lors de la réception (305) d'un message contenant une référence à un instant prédéterminé, le message est traité (310) et une commande dudit poste client est inhibée (600) jusqu'audit instant prédéterminé. A la réception d'une offre, une valeur liée à ladite vente est mise à jour (515) et un instant à partir duquel il peut être donné suite à ladite valeur est déterminé. Un message comprenant ladite valeur et ledit instant est créé et transmis (520) audit poste client. Ledit instant est de préférence déterminé en fonction de l'instant auquel est créé et transmis ledit message et de paramètres de communication.

Description

La présente invention concerne les applications du type ventes aux enchères et plus particulièrement des procédés et des dispositifs de synchronisation pour la mise en oeuvre d'applications du type ventes aux enchères à travers un réseau de communication tel qu'Internet, permettant à des individus situés à différents emplacements géographiques de participer dynamiquement à de telles ventes. Le principe des ventes aux enchères consiste en une procédure mise en oeuvre par un tiers selon laquelle le prix d'un ou de plusieurs articles est déterminé en fonction de la demande des acheteurs potentiels dans un intervalle de temps donné selon des critères de prix proposé, de quantités demandées et d'instant des offres. L'adjudication est l'acte par lequel le tiers organisant la vente aux enchères attribue un ou plusieurs articles à un ou plusieurs enchérisseurs. Il existe plusieurs types de ventes aux enchères parmi lesquels l'enchère ascendante, aussi appelée enchère anglaise, et l'enchère descendante, aussi parfois appelée enchère hollandaise. Selon l'enchère ascendante, un prix de départ est annoncé et, à compter du début de l'enchère, chaque enchérisseur peut proposer un prix supérieur à l'enchère la plus importante ou au prix de départ s'il s'agit de la première offre. L'enchère se termine lorsqu'il n'y a plus qu'un seul enchérisseur ou lorsqu'un délai prédéterminé est écoulé. Selon l'enchère descendante, un prix de départ prédéterminé est annoncé, ce prix baissant de façon continue, à compter du début de l'enchère, jusqu'à ce qu'il atteigne un prix de réserve. L'enchère se termine lorsqu'un enchérisseur se déclare preneur ou lorsque le prix de réserve est atteint. Le prix de départ peut être déterminé en fonction du prix de vente maximum espéré par le vendeur.

Pour les enchères descendantes pour lesquelles plusieurs articles sont disponibles, le prix de départ peut être réajusté à chaque adjudication, c'est-à-dire réinitialisé à sa valeur initiale, ou non. Dans les ventes aux enchères, l'instant auquel est émise une offre, c'est-à-dire par exemple une acceptation du prix, une proposition de prix, ou une proposition de quantité et de prix, est essentiel et déterminant. Par exemple, dans le cas d'une vente aux enchères de type enchère descendante, l'adjudication concerne le premier enchérisseur. Il est donc nécessaire de déterminer l'instant auquel l'enchérisseur a soumis son offre pour le comparer, éventuellement, aux instants auxquels d'autres offres ont été soumises. Par ailleurs, l'évolution des réseaux de communication, notamment Internet, a contribué au développement de nouveaux modes de distribution de biens et de services. Par exemple, les places de marché sont des plateformes virtuelles d'échanges permettant la gestion d'offres et de demandes. De telles plateformes sont généralement mises en oeuvre par des tiers qui offrent ainsi des mécanismes de transaction sécurisée. Cependant, en raison notamment des contraintes de temps réel concernant les ventes aux enchères, il n'existe pas de solution satisfaisante mettant en oeuvre de telles méthodes de vente via des réseaux de communication comme Internet. En effet, pour mettre en oeuvre une méthode de vente aux enchères à travers un réseau de communication, il est nécessaire de respecter les contraintes imposées par ce type de vente afin que tous les utilisateurs soient traités de façons égales. En particulier, tous les utilisateurs doivent avoir la possibilité d'enchérir, indépendamment des temps de latence des transmissions pouvant être introduits par le réseau de communication. De même, l'adjudication doit être réalisée de façon fiable. L'invention permet de résoudre au moins un des problèmes exposés précédemment.

L'invention a ainsi pour objet un procédé de synchronisation pour applications temps réel de type ventes aux enchères mises en oeuvre à travers un réseau de communication au moyen d'au moins un serveur et d'au moins un poste client, ce procédé comprenant les étapes suivantes, -réception et traitement d'un message contenant au moins une référence à un instant prédéterminé ; et, - inhibition d'au moins une commande dudit au moins un poste client à la réception dudit message jusqu'audit instant prédéterminé, ladite au moins une commande étant utilisée pour répondre audit message ; lesdites étapes étant mises en oeuvre dans ledit au moins un poste client. L'invention permet ainsi à l'ensemble des acteurs d'une application de type vente aux enchères de participer simultanément, à travers un réseau de communication, à de telles ventes en permettant à chacun d'eux de disposer des mêmes informations pour leur permettre de soumettre des offres à partir du même instant. La désactivation temporaire d'au moins une partie de l'interface des postes clients et en particulier des dispositifs utilisés par les utilisateurs pour enchérir, permet de donner le temps à toutes les variables pertinentes (prix de référence, temps, meilleur enchérisseur et/ou quantités) de se resynchroniser et de retourner dans un système temps réel synchronisé conduisant à la parfaite simultanéité des valeurs de référence. De même, l'invention permet, lorsqu'une enchère est terminée, 20 d'éviter qu'une offre puisse être soumise de façon erronée. L'invention permet en outre de prendre en compte les effets des qualités variables de connexion aux réseaux de communication, rendant les temps de transmission d'information variables selon les utilisateurs. Ainsi, selon l'invention, aucun poste client n'est avantagé ou défavorisé du fait de la qualité 25 de sa connexion au réseau. En d'autres termes, tous les utilisateurs disposent de la même valeur de référence au moment où les actions permettant d'enchérir sont rétablies. La notion de temps réel est ainsi limitée dans le temps, par période. De façon avantageuse, ledit message comprend en outre au moins 30 une donnée de mise à jour d'au moins une valeur mémorisée dans ledit poste client, ledit procédé comprenant une étape de mise à jour de ladite au moins une valeur, ladite étape de mise à jour étant mise en oeuvre dans ledit poste client. Les messages transmis par le serveur aux postes clients sont ainsi utilisés pour (re)synchroniser les postes clients tant d'un point de vue applicatif que d'un point de vue temps réel. Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'initialisation durant laquelle une base de temps est reçue dudit serveur afin de permettre une synchronisation dudit au moins un poste client avec ledit serveur.

De façon avantageuse, le procédé comprend en outre une étape d'indication de l'inhibition de ladite au moins une commande afin de prévenir l'utilisateur. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de saisie d'au moins une information en réponse audit message et une étape de transmission de ladite au moins une information audit au moins un serveur pour permettre à un utilisateur de transmettre une offre. L'invention a également pour objet un procédé de synchronisation pour applications temps réel de type ventes aux enchères mises en oeuvre à travers un réseau de communication au moyen d'un serveur et d'au moins un poste client, ce procédé comprenant les étapes suivantes, - réception d'un message comprenant une offre ; - détermination d'au moins un instant à partir duquel il peut être répondu à ladite offre ; et, -création et transmission audit au moins un poste client d'un message comprenant au moins une référence audit instant ; lesdites étapes étant mises en oeuvre dans ledit serveur. L'invention permet ainsi à l'ensemble des acteurs d'une application de type vente aux enchères de participer simultanément, à travers un réseau de communication, à de telles ventes en permettant à chacun d'eux de disposer des mêmes informations pour leur permettre de soumettre des offres à partir du même instant. La désactivation temporaire d'au moins une partie de l'interface des postes clients et en particulier des dispositifs utilisés par les utilisateurs pour enchérir, permet de donner le temps à toutes les variables pertinentes (prix de référence, temps, meilleur enchérisseur et/ou quantités) de se resynchroniser et de retourner dans un système temps réel synchronisé conduisant à la parfaite simultanéité des valeurs de référence. L'invention permet en outre de prendre en compte les effets des qualités variables de connexion aux réseaux de communication, rendant les temps de transmission d'information variables selon les utilisateurs. Ainsi, selon l'invention, aucun poste client n'est avantagé ou défavorisé du fait de la qualité de sa connexion au réseau. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de mise à jour d'au moins une valeur mémorisée dans ledit serveur selon ladite offre comprise dans ledit message reçu, ladite au moins une valeur étant transmise audit au moins un poste client dans ledit message transmis. Les messages transmis par le serveur aux postes clients sont ainsi utilisés pour (re)synchroniser les postes clients tant d'un point de vue applicatif que d'un point de vue temps réel. De façon avantageuse, le procédé comprend en outre une étape d'initialisation durant laquelle une base de temps est transmise audit au moins un poste client afin de permettre une synchronisation dudit au moins un poste client avec ledit serveur. Selon un mode de réalisation particulier, ledit instant est déterminé en fonction de l'instant auquel est créé ou transmis ledit message transmis et d'au moins un paramètre de communication dudit réseau de communication afin de limiter les délais durant lesquels ladite au moins une commande est inhibée. Ainsi, le temps de désactivation peut être ajusté en fonction des types de réseaux par lesquels passent les flux d'information. L'invention a aussi pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, 5 au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement un exemple d'environnement dans lequel l'invention peut être mise en oeuvre pour permettre une vente aux enchères à travers un réseau de communication ; - la figure 2 illustre plus précisément l'architecture du système 105 10 représenté sur la figure 1, utilisée pour gérer les ventes aux enchères ; - la figure 3 illustre les modules principaux d'un poste client pour échanger des données avec un serveur d'enchère temps réel afin de recevoir des informations en temps réel propres à une session d'enchère et de permettre la transmission d'offres en temps réel ; 15 - la figure 4 représente un exemple d'algorithme pouvant être mis en oeuvre dans un serveur d'enchère temps réel pour gérer une ou plusieurs ventes aux enchères ; - la figure 5 illustre un exemple de traitement des offres reçues par un serveur d'enchère temps réel ; 20 - la figure 6 illustre un exemple d'algorithme pouvant être implémenté dans des postes clients pour traiter les messages reçus d'un serveur d'enchère temps réel ; et, - la figure 7 illustre un exemple d'algorithme adapté à saisir et à transmettre une offre à partir d'un poste client. 25 De façon générale, une contrainte de temps réel est respectée, dans un système informatique, lorsque le temps de traitement des informations est inférieur à l'inverse de la fréquence à laquelle changent les informations traitées. En outre, une contrainte de temps réel peut être telle que le résultat des traitements effectués est au moins aussi important que le respect de la 30 contrainte liée au temps d'exécution du traitement. Il s'agit alors d'une contrainte de temps réel forte.

De plus, dans un système basé sur l'utilisation d'un réseau, il est nécessaire de prendre en compte, pour déterminer le temps de traitement des informations, le temps de transfert des informations dans le réseau et les désynchronisations éventuelles de composants du réseau de communication.

Cette contrainte de temps réel forte s'applique au domaine des ventes aux enchères sur un réseau de communication. En effet, si, par exemple, le temps de traitement d'une offre d'enchère antérieure est supérieur à celui d'une offre d'enchère postérieure, dans une vente aux enchères de type descendante, l'adjudication peut être erronée.

L'invention a donc notamment pour objet de répondre à cette contrainte de temps réel forte dans les applications de type ventes aux enchères à travers un réseau de communication. La figure 1 illustre schématiquement l'environnement 100 dans lequel l'invention peut être mise en oeuvre pour permettre une vente aux 15 enchères à travers un réseau de communication. Comme illustré, un système 105 est connecté à un réseau de communication 110. Le système 105 représente ici le système d'un tiers qui gère une ou plusieurs ventes aux enchères. Plusieurs enchérisseurs potentiels peuvent se connecter à ce système à travers le réseau 110 à l'aide de 20 dispositifs personnels ou de dispositifs mis à leur disposition, appelés de façon générale postes clients. Par exemple, un premier enchérisseur potentiel utilise un téléphone mobile 115-i, un deuxième enchérisseur potentiel utilise un assistant personnel 115-j, aussi appelé PDA (sigle de Persona/ Digital Assistant en terminologie anglo-saxonne), et un troisième enchérisseur potentiel utilise un 25 ordinateur personnel 115-k. D'autres dispositifs peuvent être utilisés tels qu'un poste de télévision pourvu d'une interface utilisateur, par exemple une télécommande, et relié à un réseau de communication. Les connections entre les postes clients, référencés 115 de façon générique, et le réseau de communication 110 sont de type standard, filaires ou sans fil. Il peut s'agir, par 30 exemple, de connexions Ethernet ou de connexion WiFi. Les postes clients 115 disposent de préférence de moyens de saisie permettant de saisir et de transmettre une offre ainsi que de moyens d'affichage permettant d'afficher des informations, telles qu'un prix de référence et une quantité d'articles. Alternativement, ou de façon complémentaire, ces informations peuvent être émises sous forme vocale. Les enchérisseurs potentiels reçoivent des informations du serveur 105, notamment les informations liées aux prix, aux quantités et au temps. Les offres sont saisies à travers l'interface des postes clients utilisés à l'aide, par exemple, d'un clavier réel ou virtuel. Selon le type d'enchère, une offre peut être soumise par la simple sélection d'une touche ou par la sélection ou l'entrée d'une ou de plusieurs valeurs, pouvant être suivie, ou non, d'une commande de confirmation ou de validation. Le prix de référence est de préférence toujours affiché sur les postes clients. Selon le type d'enchère, le prix de référence est transmis par le système 105 ou déterminé par les postes clients.

L'invention vise plus particulièrement les quatre types de vente aux enchères suivantes : - l'enchère descendante à l'unité selon laquelle le prix de référence descend de façon continue. Le premier enchérisseur qui transmet une offre sous forme d'acceptation gagne l'enchère. La durée d'enchère prévue, liée au prix de départ et la vitesse de variation du prix, est variable. Elle est ici approximativement comprise entre une dizaine de secondes et quelques minutes. Une offre peut être soumise à l'aide d'une simple commande ; - l'enchère montante à l'unité selon laquelle les enchérisseurs potentiels ont un temps limité pour enchérir, par exemple un temps de 3 secondes, à partir d'un prix de départ ou d'une nouvelle offre. Chaque offre doit en outre respecter un incrément minimum prédéfini. Si aucun enchérisseur ne transmet d'offre durant un intervalle de temps prédéterminé, l'adjudication est réalisée au profit du dernier meilleur enchérisseur (la vente peut être annulée si aucune offre n'a été soumise). Dans une solution informatique selon laquelle les offres d'enchère sont réalisées à distance, plusieurs solutions sont envisageables, de façon alternative ou complémentaire, parmi lesquelles, o utiliser des touches prédéfinies correspondant chacune à un incrément prédéterminé par rapport au prix de référence visible par l'enchérisseur, par exemple ajouter un euro, deux euros ou cinq euros au prix de référence, la sélection pouvant être validée ou non à l'aide d'une autre touche ; et, o entrer et valider un montant correspondant à l'offre ; -l'enchère à l'horloge selon laquelle le prix de référence descend depuis une valeur initiale correspondant à un prix de départ jusqu'à ce qu'un enchérisseur transmette une offre ou jusqu'à un prix de réserve si aucune offre n'est reçue. L'offre consiste ici en une quantité (le prix est celui correspondant au moment où l'utilisateur a saisi son offre). Le stock des articles disponibles est alors diminué d'autant, le prix de référence est remis à son niveau initial (prix de départ) et repart à la baisse jusqu'à ce qu'une nouvelle offre soit émise.

Alternativement, après qu'une offre ait été transmise et acceptée, le prix de référence peut être déterminé en fonction du dernier prix d'acceptation ou en fonction d'une réévaluation du prix de départ. Le processus est répété jusqu'à épuisement des stocks ou jusqu'à ce que le prix de réserve soit atteint. Ce type d'enchère concerne particulièrement le déstockage de grandes quantités d'articles identiques. Une offre peut être soumise par la saisie d'une quantité ou par l'activation d'une touche correspondant à une quantité prédéterminée ; - l'enchère descendante multiple qui se différentie de l'enchère à l'horloge en ce que le prix courant n'est pas réinitialisé après qu'un enchérisseur ait soumis une offre. Selon l'enchère descendante multiple, le prix descend constamment et, lorsqu'une offre est soumise, la quantité d'articles est diminuée de la valeur contenue dans l'offre. L'enchère se termine lorsque le nombre d'articles atteint zéro ou lorsque le prix de réserve est atteint. A nouveau, une offre peut être soumise par la saisie d'une quantité ou par l'activation d'une touche correspondant à une quantité prédéterminée.

A chaque type d'enchère correspondent des commandes spécifiques accessibles par les utilisateurs, c'est-à-dire par les enchérisseurs potentiels. Le tableau suivant illustre un exemple de commandes pouvant être proposées en fonction du type de vente aux enchères. Enchère Enchère Enchère à Enchère descendante à montante l'horloge descendante l'unité multiple Acheter (ou X X X acceptation du prix) Saisie du prix X Saisie d'une X X quantité A chaque type d'enchère correspondent aussi des variables dont les nouvelles valeurs de référence sont transmises par le serveur d'enchère à l'ensemble des clients à chaque itération de l'enchère. Le tableau suivant illustre un exemple de variables pouvant être utilisées en fonction du type de vente aux enchères. Enchère Enchère Enchère à Enchère descendante montante l'horloge descendante à l'unité multiple Prix X X X X Meilleur enchérisseur X X X X Quantité X X La figure 2 illustre plus précisément l'architecture du système 105 représenté sur la figure 1, utilisée pour gérer les ventes aux enchères.

Comme représenté, le système 105 s'inscrit dans une architecture de type 'N-Tiers' et comprend ici deux serveurs frontaux 200 et 205 et deux serveurs spécifiques 210 et 215. Les serveurs 200, 205, 210 et 215 peuvent également être des ensembles de serveurs, aussi appelés fermes de serveurs. Le serveur 215, appelé serveur applicatif ou serveur de contenu, contient et gère les différentes annonces préalablement publiées par les utilisateurs, c'est-à-dire les offres de mises en vente. Chaque annonce peut être caractérisée par une référence de produit, un vendeur, un prix de départ et un prix de réserve, une quantité, le type d'enchère ainsi que la date et l'heure de planification de la session d'enchère. D'autres informations peuvent être associées aux annonces. Le serveur 215 intègre un mécanisme de programmation des sessions d'enchère dans le temps, appelé scheduler en terminologie anglo- saxonne. Le serveur 215 transmet chronologiquement les informations relatives aux sessions d'enchères aux serveurs 200 et 205. Le serveur 200, appelé SETR (sigle de Serveur d'Enchère Temps Réel), est dédié à la gestion en temps réel des sessions d'enchères, c'est-à-dire, en particulier, à la réception des offres transmises par les enchérisseurs pour un produit donné, à la validation de la pertinence d'une offre, à la mise à jour des variables de l'enchère et à la diffusion d'informations vers l'ensemble des postes clients 115 connectés à la session d'enchère. Les informations transmises aux postes clients par le serveur SETR 200 sont notamment les variables de l'enchère mises à jour et les données de synchronisation.

Le serveur 205, appelé serveur Web, est connecté au serveur applicatif 215. Il dispose ainsi d'un accès aux données relatives aux annonces et à l'agenda des sessions d'enchère terminées, en cours et à venir. Le serveur Web 205 est à l'écoute des informations transmises par le serveur 215, notamment par le mécanisme de programmation des sessions d'enchère dans le temps, ce qui lui permet de connaître les paramètres liés aux sessions d'enchère en cours et à venir. Ces paramètres regroupent notamment un identifiant unique d'une session d'enchère et un identifiant physique du serveur SETR 200 où se déroule la session. L'identifiant physique comprend par exemple l'adresse réseau du serveur SETR et une référence au protocole utilisé. Le serveur 210, appelé serveur proxy, est dédié à la gestion des offres d'enchérisseurs passées à l'avance. Le serveur proxy 210 est connecté au serveur SETR 200 et lui transmet les offres pendant la session d'enchère, comme si elles étaient émises par des enchérisseurs. Les postes clients 115 sont connectés au serveur Web 205 et peuvent ainsi accéder à la partie applicative, notamment à la gestion des annonces. Ils peuvent ainsi disposer des informations relatives aux prochaines sessions d'enchères (chronologie et paramètres). Pour participer à une session d'enchère, chaque poste client 115 doit se connecter au serveur SETR 200 à l'aide de connecteurs réseau prédéfinis selon les paramètres liés à une session. Il est ici rappelé que les connecteurs réseau, aussi appelés sockets en terminologie anglo-saxonne, sont des interfaces logicielles avec les services d'un système d'exploitation, permettant d'exploiter les services d'un protocole réseau. Les connecteurs réseau entre les postes clients 115 et le serveur SETR 200 utilisés ici permettent de bénéficier de connections réseau permanentes en mode lecture/écriture. Ces connections sont avantageusement sécurisées et ont une durée de vie limitée dans le temps, en fonction de la durée de la session d'enchère. Le mode lecture permet de recevoir des informations depuis le serveur SETR 200 tandis que le mode écriture permet d'envoyer des informations au serveur SETR 200. Certains des algorithmes mis en oeuvre dans le serveur SETR 200 sont décrits par référence aux figures 4 et 5. La figure 3 illustre les modules principaux d'un poste client 115 pour échanger des données avec le système d'enchères 105 et plus particulièrement avec le serveur SETR 200 afin de recevoir des informations en temps réel propres à une session d'enchère et de permettre la transmission d'offres en temps réel. Les modules standard, nécessaires au fonctionnement des postes clients, tels qu'un système d'exploitation, ne sont pas représentés dans un souci de clarté. Le module 300 permet d'initialiser les connecteurs réseau avec le serveur SETR 200 en établissant une connexion et en identifiant l'utilisateur ainsi que la session d'enchère associée. Il est ici admis que chaque poste client 115 s'est préalablement connecté au serveur Web 205 à l'aide, par exemple, d'une liaison web classique et du protocole http et qu'il est identifié comme un utilisateur de la plateforme.

Les postes clients 115 comprennent en outre un module 305 pour recevoir des messages transmis par le serveur SETR 200 et un module 310 pour traiter les messages reçus. Un exemple d'algorithme de traitement des messages reçus est décrit en référence à la figure 6.

Les postes clients 115 comprennent également un module 315 permettant de saisir et de transférer des offres au serveur SETR 200 pendant une session d'enchère. Un exemple d'algorithme de saisie et de transmission d'offres est décrit en référence à la figure 7. L'ensemble des modules 300, 305, 310 et 315 représente la partie applicative cliente présente sur chaque poste client 115. Associés aux connecteurs réseau, le module 305 de réception de messages et le module 315 d'émission d'offres sont de préférence autonomes et fonctionnent de manière événementielle sans délai d'attente. Pour maintenir la pertinence et la cohérence des informations partagées par les postes clients 115, un mécanisme de (re)synchronisation est mis en place entre les postes client 115 et le serveur SETR 200. Ce mécanisme permet notamment de bloquer le module 315 d'émission d'offres jusqu'à un instant donné afin que tous les postes clients 115 reçoivent les bonnes informations et soient en mesure recommencer à émettre de nouvelles offres sur une base de temps commune. La figure 4 représente un exemple d'algorithme pouvant être mis en oeuvre dans le serveur SETR 200 pour gérer une ou plusieurs sessions d'enchères. Il est ici supposé que les enchérisseurs potentiels sont connectés au serveur SETR 200.

Avant chaque session d'enchère le serveur applicatif 215 envoie au serveur SETR 200 les informations propres à la session devant débuter. En fonction de ces informations le module 400 prépare l'environnement propre à cette session d'enchère et notamment les connecteurs réseau (pour la réception des offres) avec les postes client 115. A partir de cet instant le serveur SETR 200 est prêt accepter ou à refuser les demandes de connexion des poste client 115.

Le serveur SETR 200 utilise un mécanisme d'horloge interne 405, aussi appelé timer en terminologie anglo-saxonne, pour synchroniser le début et la fin d'une session d'enchère. D'une manière générale le module 400 calcule la durée initiale, l'heure de fin de la session d'enchère (en l'absence d'offre) et initialise l'horloge 405 avec le résultat des calculs. Il doit être noté que le calcul de fin de la session d'enchère peut être itératif suivant le type d'enchère. Par exemple, pour les enchères montantes et descendantes multiples, la fin de la session est recalculée, ou la session d'enchère est arrêtée lorsque la quantité restante de produits est nulle (enchère multiple), pour chaque offre traitée. Dans tous les cas, lorsque l'horloge arrive à l'heure de fin, la session d'enchère est arrêtée. Après validation, l'adjudication 420 est communiquée aux postes clients 115. Le module 400 est également responsable du mécanisme événementiel de mise en relation des postes client 115. Pour chaque nouvelle connexion validée, le module 400 transmet directement au poste client 115 les variables associées à la session courante, qu'elle ait débutée ou non. Le serveur SETR 200 est ensuite placé dans une configuration selon laquelle il peut recevoir les offres transmises par les enchérisseurs (étape 410).

Chaque offre reçue est immédiatement traitée (étape 415) afin de déterminer, éventuellement, un nouveau prix de référence et d'en avertir les enchérisseurs, c'est-à-dire de transmettre un message aux postes clients comprenant les nouvelles informations de la vente. L'étape 415 est détaillée par référence à la figure 5.

Par ailleurs, des mécanismes sont mis en place sur les postes client 115 et sur le serveur SETR 200 afin de garantir un synchronisme dans le temps. L'utilisation de l'horloge 405 permet d'initialiser une nouvelle base de temps par session d'enchère, commune au serveur d'enchère et aux postes clients. Si l'instant to correspond au début de la session, tous les échanges entre le serveur SETR 200 et les postes clients 115 se font sur la base de l'instant to associé à la session d'enchère. Cette base de temps peut être comprise comme étant représentative d'un instant donné, la représentation de cet instant étant la même pour le serveur d'enchère et tous les postes clients. Cette représentation peut être sous la forme date/heure, l'heure étant suffisamment précise pour distinguer deux offres. La précision de l'heure est, par exemple, le millième de seconde.

La figure 5 illustre un exemple de traitement des offres reçues par le serveur SETR 200. Chaque offre reçue est mémorisée et analysée dès réception (étape 500). Un test, spécifique à chaque type d'enchère, est ensuite effectué pour déterminer si l'offre est valide (étape 505). Pour une enchère ascendante selon laquelle une offre doit être supérieure au prix actuel, le test peut notamment porter sur le montant de l'offre. Un autre test peut consister à vérifier que la session d'enchère n'est pas terminée, en particulier pour une enchère descendante simple. Ces tests sont réalisés en raison du fait, notamment, que les temps de transmissions des ordres peuvent être différents pour les différents utilisateurs : une offre envoyée à un instant ti par un poste client peut arriver après une offre envoyée à un instant tk (avec ti < tk) par un autre poste client. Si l'offre n'est pas valide, elle est ignorée. Au contraire, si l'offre est valide, les variables de l'enchère sont mises à jour (étape 510). Comme indiqué précédemment, ces variables sont par exemple un nouveau prix de référence ou une quantité de produits. Si les variables de l'enchère sont mises à jour, un message, contenant notamment ces variables et au moins une indication relative à l'instant t; à partir duquel de nouvelles offres peuvent être émises, est créé puis transmis à tous les postes clients (étape 515). Selon le type d'enchère, ce message met fin à la vente aux enchères ou les informations contenues dans celui-ci sont utilisées comme base pour de nouvelles enchères. Alternativement, les indications relatives aux instants à partir desquels de nouvelles offres peuvent être émises et les nouvelles valeurs des variables des enchères sont transmises par le serveur aux postes clients dans plusieurs messages distincts. Par exemple, un premier type de message peut être utilisé pour transmettre les indications relatives aux instants à partir desquels de nouvelles offres peuvent être émises et un deuxième type de message peut être utilisé pour transmettre les nouvelles valeurs des variables des enchères. L'instant ti à partir duquel de nouvelles offres peuvent être émises par les postes clients est déterminé, par exemple, par l'instant ttransmission auquel le message est créé ou transmis par le serveur aux postes clients et par un délai delta nécessaire à la transmission des données à travers le réseau de communication (ti = ttransmission + delta). Ce délai delta peut être prédéterminé. Ce délai delta peut également être déterminé par le serveur SETR 200, avant la vente aux enchères ou au cours de celle-ci, en estimant le temps nécessaire pour qu'un message transmis par celui-ci soit reçu par tous les postes clients des utilisateurs participant à la vente. Ce délai peut être majoré, notamment pour tenir compte d'une variabilité des temps de transmission de message à travers le réseau de communication. Le délai delta peut être déterminé selon d'autres critères.

L'indication relative à l'instant ti à partir duquel de nouvelles offres peuvent être émises peut être une représentation de l'instant ti telle qu'un codage de la date et de l'heure ou, par exemple, une représentation de la différence de temps entre les l'instants ti et to ou ti_1 et ti, l'instant ti_1 représentant l'instant à partir duquel de nouvelles offres pouvaient être émises en réponse à la réception du message précédent. La figure 6 illustre un exemple d'algorithme pouvant être implémenté dans les postes clients pour traiter les messages reçus du serveur SETR 200, correspondant au module 310 de la figure 3. Lorsque, durant une vente aux enchères, un message est reçu du serveur SETR 200, un mécanisme de gel (étapes 600 et 645) est mis en place pour une durée déterminée. Ce délai de gel est déterminé en fonction de l'instant de réception du message et de l'instant à partir duquel de nouvelles offres peuvent être émises. Ce mécanisme peut être traduit par des commandes de blocage, de désactivation ou d'inhibition de l'interface utilisateur afin d'empêcher l'utilisateur de saisir et de transmettre une offre. Selon un mode de réalisation particulier, au moins une partie de l'interface utilisateur est inhibée jusqu'à un instant prédéterminé ti (dont au moins une caractéristique est reçue du serveur SETR), c'est-à-dire qu'une ou plusieurs touches, réelles ou virtuelles, sont désactivées et ne produisent plus d'effet lorsqu'elles sont activées. Ce mécanisme de gel permet de (re)synchroniser tous les postes clients et d'éviter, par exemple, qu'un enchérisseur ne puisse transmettre une offre en réponse à un nouveau prix de référence tant que tous les dispositifs des enchérisseurs n'ont pas reçu le nouveau prix de référence. La synchronisation des postes client 115 avec le serveur SETR 200 est basée sur le partage et l'utilisation d'une base de temps commune. Tous les échanges, envoi et réception, sont ainsi synchronisés sur cette base de temps. Ainsi le mécanisme de gel et de dégel est mise en oeuvre sur tous les postes client 115 de la même manière : l'instant t;, commun à tous les postes clients, représente la fin de la période de gel. Cette information étant la même pour tous les postes clients 115, tous les postes clients sont (re)synchronisés. Tous les postes clients sont désinhibés au même instant t;. Il est ainsi possible, pour tous les utilisateurs, de répondre à une offre au même instant. A cette fin, une horloge est utilisée pour déterminer l'instant auquel l'interface est désinhibée, c'est-à-dire l'instant à partir duquel il est possible 20 d'émettre des offres (étape 605). De façon avantageuse, une indication est fournie à l'utilisateur pour le prévenir que l'interface est au moins partiellement inhibée et qu'il n'est pas possible de saisir et/ou de transmettre des offres. A titre d'illustration, un son particulier peut être émis lorsque l'interface est partiellement inhibée. 25 Alternativement, ou de façon complémentaire, un message peut être affiché sur l'écran du poste client ou certaines parties, telles qu'un clavier virtuel, peuvent apparaître en grisé. En outre, à la réception d'un message du serveur SETR 200, les nouvelles valeurs de référence sont mises à jour. 30 Parallèlement, le message reçu est analysé (étape 610) pour en déterminer la nature (étape 615). Ici, le message peut être un message d'initialisation, un message de mise à jour des offres, un message d'attente ou un message de fin. Un message d'initialisation est reçu par un poste client 115 dés lors qu'il se connecte au serveur SETR 200. Ce message unique comporte les valeurs initiales des variables liées à la session d'enchère. A la réception de ce message, le poste client 115 peut se synchroniser avec le serveur SETR 200. En effet, comme indiqué précédemment, ce message comporte une information relative à la base de temps to utilisée par la suite pour les échanges avec le serveur SETR 200 et pour les calculs de synchronisation. Ce message contient aussi le délai restant (départ) avant que ne débute la session d'enchère (la session débute ainsi à l'instant to+départ). Ce message peut contenir d'autres informations. Par exemple, dans le cas d'une enchère à l'horloge, le message peut contenir des indications relatives à l'évolution du prix en fonction du temps. Ainsi, un poste client 115 peut, à l'aide de ces indications et, éventuellement, du prix de départ et de la durée de la vente, déterminer la courbe d'évolution décroissante du prix de référence, en fonction du temps, sans qu'il soit nécessaire de transmettre toutes les données en elles-mêmes.

Un message de mise à jour des offres contient les nouvelles valeurs de référence de l'enchère, et au moins une indication relative à un instant t; à partir duquel il est possible de saisir et/ou de transmettre de nouvelles offres. Lorsqu'un message de mise à jour des offres est reçu, les nouvelles valeurs de référence sont de préférence affichées sur l'écran (étape 625) et les paramètres de la vente aux enchères sont ajustés (étape 630). Par exemple, le prix de référence courant est remplacé par le prix de référence reçu, la quantité disponible des articles est remplacée par la quantité disponible des articles et le délai autorisé pour enchérir est réinitialisé. Un message d'attente a pour principal objet d'inhiber les postes clients et d'informer les enchérisseurs potentiels qu'une vente est terminée et qu'il n'est plus possible d'enchérir. Ce message est utilisé dans les enchères descendantes simple et à l'horloge ainsi que pour la dernière unité disponible dans une enchère descendante multiple. Ce message est de préférence transmis dès que le SETR reçoit une offre valide. Il permet de faire patienter les participants à la session d'enchère (ainsi que d'éventuels spectateurs) pendant que le serveur reçoit et traite les éventuelles offres concurrentes simultanées.

Un message de fin a pour objet de mettre fin à une session d'enchère. Il est le dernier message reçu par un poste client pour une session d'enchère particulière. Ce message comporte les informations relatives à la fin de la session d'enchère, c'est-à-dire, par exemple, le(s) prix, le(s) nom(s) du (des) gagnant(s) et les quantités éventuelles associées.

A compter de la réception de ce message, la connexion avec le serveur SETR 200 est de préférence perdue et met fin à la session d'enchère en temps réel. A l'instant prédéterminé t; dont une référence est reçue via un message transmis par le serveur SETR 200, l'interface du poste client 115 est désinhibée (étape 645). Le poste client peut alors être utilisé pour saisir et transmettre une offre. La figure 7 illustre un exemple d'algorithme adapté à saisir et à transmettre une offre. Cet algorithme est par exemple implémenté dans le module 315 de la figure 3.

Un premier test est tout d'abord effectué pour déterminer l'état de l'interface du poste client 115 (étape 700). Ce test est répété tant que l'interface est au moins partiellement inhibée. Si l'interface du poste client 115 n'est pas inhibée, l'enchérisseur utilisant le poste client 115 peut saisir une offre (étape 705). Comme indiqué précédemment, le type de commandes accessibles à l'utilisateur dépend du type d'enchère de la session en cours. Un test est ensuite avantageusement effectué pour déterminer si l'offre est valide (étape 710). Par exemple, ce test peut consister à comparer le montant de l'offre au prix de référence (enchère montante) ou le montant d'articles souhaités au nombre d'articles disponibles (enchère à l'horloge). Si l'offre n'est pas valide, par exemple si le montant est inférieur au prix de référence ou si le nombre d'articles souhaités est supérieur au nombre d'articles disponibles, l'enchérisseur peut saisir une nouvelle offre après que le poste client ait vérifié que l'état de l'interface le permette (étapes 700 à 710). Si l'offre est valide, l'offre est formalisée pour être transmise au serveur SETR 200 (étape 715). La formalisation de l'offre est liée à l'implémentation logicielle de la vente aux enchères et/ou au protocole de communication utilisé entre le poste client 115 et le serveur SETR 200. L'offre est ensuite transmise au serveur SETR 200 (étape 720). Il est possible, lorsqu'une offre a été transmise par le poste client 115, d'inhiber momentanément son interface afin d'empêcher que l'enchérisseur ne transmette une seconde offre immédiatement après la première. Une telle commande peut avoir pour objet de protéger l'enchérisseur contre une mauvaise manipulation, telle qu'une double saisie involontaire, par exemple un double-clic, ou être liée à une stratégie commerciale. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (11)

REVENDICATIONS

1. Procédé de synchronisation pour applications temps réel de type ventes aux enchères mises en oeuvre à travers un réseau de communication au moyen d'au moins un serveur et d'au moins un poste client, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (305) et traitement (310) d'un message contenant au moins une référence à un instant prédéterminé ; et, - inhibition (600) d'au moins une commande dudit au moins un poste client à la réception dudit message jusqu'audit instant prédéterminé, ladite au moins une commande étant utilisée pour répondre audit message ; lesdites étapes étant mises en oeuvre dans ledit au moins un poste client.

2. Procédé selon la revendication 1 selon lequel ledit message comprend en outre au moins une donnée de mise à jour d'au moins une valeur mémorisée dans ledit poste client, ledit procédé comprenant une étape de mise à jour de ladite au moins une valeur, ladite étape de mise à jour étant mise en oeuvre dans ledit au moins un poste client.

3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape d'initialisation durant laquelle une base de temps est reçue dudit serveur.

4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'indication de l'inhibition de ladite au moins 25 une commande.

5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de saisie d'au moins une information en réponse audit message et une étape de transmission de ladite au moins une information audit au moins un serveur. 30

6. Procédé de synchronisation pour applications temps réel de type ventes aux enchères mises en oeuvre à travers un réseau de communication aumoyen d'un serveur et d'au moins un poste client, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception d'un message comprenant une offre ; - détermination d'au moins un instant à partir duquel il peut être répondu à ladite offre ; et, - création et transmission (520) audit au moins un poste client d'un message comprenant au moins une référence audit instant ; lesdites étapes étant mises en oeuvre dans ledit serveur.

7. Procédé selon la revendication 6 comprenant en outre une étape de mise à jour (515) d'au moins une valeur mémorisée dans ledit serveur selon ladite offre comprise dans ledit message reçu, ladite au moins une valeur étant transmise audit au moins un poste client dans ledit message transmis.

8. Procédé selon la revendication 6 ou la revendication 7 comprenant en outre une étape d'initialisation durant laquelle une base de temps est transmise audit au moins un poste client.

9. Procédé selon l'une quelconque des revendications 6 à 8 selon lequel ledit instant est déterminé en fonction de l'instant auquel est créé ou transmis ledit message transmis et d'au moins un paramètre de communication dudit réseau de communication.

10. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes.

11. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à9.