FR2976385A1

FR2976385A1 - Procede pour definir une transaction a effectuer au moyen d'un serveur

Info

Publication number: FR2976385A1
Application number: FR1155114A
Authority: FR
Inventors: Frederic Boucher; Adrien Korniloff
Original assignee: KIIPS
Current assignee: Lusis Fr
Priority date: 2011-06-10
Filing date: 2011-06-10
Publication date: 2012-12-14
Anticipated expiration: 2031-06-10
Also published as: FR2976385B1

Abstract

Un serveur de transactions (SVT) établit une définition d'une transaction à effectuer lorsque le serveur de transactions a reçu une communication en provenance d'un dispositif de communication (DC), la communication comprenant : - une représentation d'un identifiant (CT) associé à une partie acheteur, et - une représentation d'un code (CD) présenté à un point de paiement (PP) associé à une partie vendeur. Le serveur de transactions (SVT) obtient une spécification d'un objet de la transaction par un des schémas suivants : - la communication comprend la spécification de l'objet de la transaction, - la communication comprend une référence à la spécification de l'objet de la transaction ayant préalablement été reçue par le serveur de transactions, et - la communication est reçue dans un intervalle de temps donné par rapport à une autre communication en provenance du point de paiement (PP), cette autre communication comprenant la spécification de l'objet de la transaction accompagnée d'un identifiant (ID ) du point de paiement.

Description

Procédé pour définir une transaction à effectuer au moyen d'un serveur. [0001] DOMAINE TECHNIQUE [0002] La présente invention concerne un procédé pour définir une transaction à effectuer impliquant un serveur de transactions. La transaction à effectuer peut être, par exemple, un achat d'un ou plusieurs produits dans un magasin.

L'invention concerne également un procédé pour effectuer une transaction, un programme permettant à un processeur de mettre en oeuvre un tel procédé, et un système pour définir une transaction à effectuer. [0003] ETAT DE LA TECHNIQUE ANTERIEURE [0004] Un procédé de paiement dématérialisé peut fonctionner selon le schéma suivant. Un commerçant, qui constitue une partie vendeur, identifie un particulier, qui constitue une partie acheteur, à l'aide d'un support tel que, par exemple, une carte à puce ou un autre type de carte de paiement. Le particulier obtient une définition de la transaction du commerçant sous forme de, par exemple, un montant de la transaction. Dans le cas où le particulier valide cette définition, la transaction est effectuée par un ou plusieurs intermédiaires. [0005] Ce procédé de paiement dématérialisé présente divers inconvénients. Premièrement, une transaction est toujours à l'initiative du commerçant ; le particulier ne peut difficilement prendre l'initiative, ou même pas du tout. De plus, lorsque le particulier s'identifie auprès du commerçant, cette identification peut être l'objet d'une usurpation d'identité. Diminuer ce risque et garantir un anonymat de la transaction nécessite typiquement des mesures d'authentification complexes. [0006] EXPOSE DE L'INVENTION [0007] Il existe un besoin pour une solution permettant de définir une transaction à effectuer de façon souple et flexible. [0008] Selon un aspect de l'invention, un procédé pour définir une transaction à effectuer est caractérisé en ce qu'un serveur de transactions établit une définition de la transaction à effectuer lorsque le serveur de transactions a reçu une communication en provenance d'un dispositif de communication, la communication comprenant : - une représentation d'un identifiant associé à une partie acheteur, et ~o - une représentation d'un code présenté à un point de paiement associé à une partie vendeur. Le serveur de transactions obtient une spécification d'un objet de la transaction par un des schémas suivants : - la communication comprend la spécification de l'objet de la transaction, 15 - la communication comprend une référence à la spécification de l'objet de la transaction ayant préalablement été reçue par le serveur de transactions, et - la communication est reçue dans un intervalle de temps donné par rapport à une autre communication en provenance du point de paiement, cette autre communication comprenant la spécification de l'objet de la transaction 20 accompagnée d'un identifiant du point de paiement. [0009] En fait, la communication identifiant la partie acheteur et comprenant la représentation du code présenté au point de paiement constitue une demande de paiement de la part du particulier. Le serveur de transactions traite cette demande de paiement en établissant une définition de la transaction à effectuer, qui peut 25 être soumise à une ou plusieurs validations. Cette approche permet un schéma où la partie vendeur établit la spécification de l'objet de la transaction, ainsi qu'un schéma où la partie acheteur établit cette spécification. L'une ou l'autre partie peut donc prendre l'initiative. [oo1o] De plus, l'invention permet de préparer et d'effectuer une transaction de 30 façon anonyme. Une partie acheteur n'a pas besoin de s'identifier ou de s'authentifier au point de paiement. Le serveur de transactions peut être la seule 2 entité connaissant à la fois la partie acheteur et la partie vendeur. La partie acheteur n'a pas besoin d'entrer un code PIN, PIN étant l'acronyme du terme anglais « Personal Identification Number ». [0011] En outre, l'invention peut être mise en oeuvre avec une infrastructure relativement légère et peu coûteuse. Par exemple, le dispositif de communication peut être sous forme d'un téléphone portable « intelligent » (en anglais : Smart Phone) qui est déjà matériellement apte à mettre en oeuvre l'invention : il suffit de télécharger une application appropriée sur ce téléphone portable. De surcroît, l'invention permet que la partie vendeur puisse faire une économie sur des frais généraux liés aux transactions, car l'invention permet un paiement de façon dématérialisée et simple. [0012] Selon un autre aspect de l'invention, un programme pour un processeur comprend des données exécutables par le processeur pour l'exécution du procédé défini dans ce qui précède lorsque ledit programme est exécuté sur le processeur.

Selon un encore autre aspect de l'invention, un système pour définir une transaction à effectuer comprend un serveur de transactions apte à mettre en oeuvre le procède défini dans ce qui précède. [0013] Un mode de réalisation de l'invention comprend avantageusement une ou plusieurs des caractéristiques supplémentaires suivantes, lesquelles sont décrites dans les paragraphes suivants. Ces caractéristiques supplémentaires contribuent généralement à la souplesse et la flexibilité. [0014] Le procédé comprend avantageusement une étape d'interrogation dans laquelle le serveur de transactions interroge une base de données à partir d'au moins un des éléments suivants : la partie vendeur, la partie acheteur, et l'objet de la transaction, pour vérifier si la base de données comprend un élément supplémentaire à intégrer dans la définition de la transaction. [0015] Avantageusement, le serveur de transactions n'établit la définition de la transaction qu'à condition que la communication comprenne un mot de passe ayant préalablement été convenu entre la partie acheteur et le serveur de transactions. [0016] Avantageusement, le serveur de transactions n'établit la définition de la transaction qu'à condition que la communication s'effectue à travers un canal de communication sécurisé. [0017] Le procédé comprend avantageusement une étape préalable dans lequel le serveur de transactions reçoit la spécification de l'objet de la transaction en provenance du dispositif de communication et en association avec l'identifiant associé à la partie acheteur. [0018] Le code présenté au point de paiement appartient avantageusement à une séquence de codes pseudo-aléatoire associée de façon unique au point de paiement. [0019] La communication comprend avantageusement une donnée numérique résultant d'une conversion du code présenté au point de paiement sous forme d'un signal sonore, la conversion étant effectuée par le dispositif de communication captant le signal sonore. [0020] Le procédé comprend avantageusement une étape de demande de confirmation dans laquelle le serveur de transactions envoie la définition de la transaction établie à la partie vendeur pour confirmation. [0021] Le procédé comprend avantageusement une étape d'effacement dans laquelle le serveur de transactions efface la définition de la transaction lorsque le serveur de transactions n'a reçu aucune confirmation pour cette transaction de la partie vendeur dans un intervalle de temps prédéfini suite à l'étape de demande de confirmation. [0022] Selon un autre aspect de l'invention, le procédé décrit dans ce qui précède en incluant l'étape de demande de confirmation, est appliqué dans un procédé pour effectuer une transaction comprenant une étape de réception de confirmation dans lequel le serveur de transactions reçoit une confirmation de la partie vendeur relative à la définition de la transaction envoyée, la transaction étant effectuée suite à cette étape de réception de confirmation. [0023] Avantageusement, la transaction n'est effectuée qu'à condition que la confirmation de la partie vendeur comprenne une signature électronique authentifiant la partie vendeur. [0024] Le procédé comprend avantageusement une étape de débit dans laquelle le serveur de transactions débite un compte monétaire appartenant à la partie vendeur suite à l'étape de réception de confirmation. [0025] Le procédé comprend avantageusement une étape d'archivage central dans laquelle le serveur de transactions archive une description de la transaction effectuée dans une base de données d'archivage centrale. [0026] Le procédé comprend avantageusement une étape d'attribution d'avantages commerciaux dans laquelle le serveur de transactions crédite un compte appartenant à la partie acheteur lorsque la transaction a été effectuée. [0027] Une description détaillée en référence à des dessins illustre l'invention brièvement exposée précédemment, ainsi que les caractéristiques supplémentaires identifiées précédemment. [0028] DESCRIPTION SOMMAIRE DES DESSINS - La figure 1 est un diagramme conceptuel illustrant une infrastructure permettant de définir une transaction et d'effectuer cette transaction. - La Figure 2 est un organigramme illustrant un procédé mis en oeuvre dans l'infrastructure pour définir une transaction et pour effectuer cette transaction. [0029] DESCRIPTION DETAILLEE DE L'INVENTION [0030] La fiqure 1 illustre schématiquement une infrastructure INF qui permet de définir une transaction et d'effectuer cette transaction. L'infrastructure INF comprend diverses entités : un serveur de transactions SVT, un point de paiement PP, un dispositif de communication DC, et au moins un réseau de communication. Deux réseaux de communication R1, R2 sont représentés à la figure 1 à titre d'exemple. Dans cet exemple, un premier réseau de communication R1 relie le dispositif de communication DC et le serveur de transactions SVT entre eux de façon communicative. Un second réseau de communication R2 relie le point de paiement PP et le serveur de transactions SVT entre eux de façon communicative. [0031] Le serveur de transactions SVT peut appartenir à un opérateur de services de paiement qui configure et gère au moins partiellement l'infrastructure INF illustrée à la figure 1. Le point de paiement PP peut être sous forme d'une caisse dans un magasin qui appartient à une entité de vente. Le point de paiement PP peut faire partie d'un système de caisse dans le magasin ; le point de paiement PP peut constituer un poste client dans un tel système. Le dispositif de communication DC appartient à un particulier P qui est également schématiquement représenté à la figure 1. Le dispositif de communication DC peut être sous forme d'une téléphone portable « intelligent » (en anglais : Smart Phone) apte à exécuter des programmes applicatifs. Dans ce cas, le premier réseau est typiquement un réseau sans fil. [0032] L'infrastructure INF illustrée à la figure 1 peut également comprendre diverses entités complémentaires : un serveur bancaire SVB et un serveur de gestion d'avantages commerciaux SVA. Ces serveurs SVB, SVA gèrent typiquement une ou plusieurs bases de données. Le serveur bancaire SVB et le serveur de transactions SVT peuvent être reliés entre eux de façon communicative par le second réseau de communication R2, ou un autre réseau de communication. De même, le serveur de gestion d'avantages commerciaux SVA et le serveur de transactions SVT peuvent être reliés entre eux de façon communicative par le second réseau de communication R2, ou un autre réseau de communication. [0033] L'infrastructure INF peut comprendre plusieurs entités du même type. Par exemple, de nombreux particuliers, chacun disposant d'un dispositif de communication, peuvent utiliser l'infrastructure INF illustrée à la figure 1. De même, de nombreux magasins, chacun disposant d'au moins un point de paiement, peuvent utiliser l'infrastructure INF illustrée à la figure 1. L'infrastructure INF peut également comprendre plusieurs serveurs de transactions, plusieurs serveurs bancaires, et plusieurs serveurs de gestion d'avantages commerciaux.

La figure 1 n'illustre qu'une entité par type pour des raisons de clarté et de compréhension. [0034] Plus en détail, le point de paiement PP comprend un dispositif de présentation de code CD, une mémoire de données MEMpp, et une interface de communication ICpp. Le point de paiement PP peut également facultativement comprendre une interface opérateur 10. Le dispositif de présentation de code CD peut comprendre, par exemple, un émetteur de son, un émetteur de champ électromagnétique, ou un afficheur d'image. Le dispositif de présentation de code CD peut également comprendre un générateur de code, de préférence à caractère aléatoire. [0035] La mémoire de données MEMpp du point de paiement PP comprend un identifiant IDpp sous forme d'un code numérique stocké dans une mémoire. La mémoire de données MEMpp peut également comprendre une donnée racine à partir de laquelle le générateur de code peut générer des codes à caractère pseudo aléatoire. L'interface de communication ICpp peut comprendre, par exemple, une connexion réseau reliant le point de paiement PP à un système de caisse reliée au serveur de transactions SVT de façon communicative. L'interface opérateur IO comprend typiquement un écran et un clavier ou un autre type de dispositif permettant à un opérateur d'entrer des données. [0036] Le dispositif de communication DC comprend un module d'identification d'utilisateur réseau MID, une mémoire de données MEMpc, et un processeur PRCpc. Le dispositif de communication DC peut également facultativement comprendre un module de localisation de type GPS, GPS étant l'acronyme du terme anglais « Global Positioning System ». Le module d'identification d'utilisateur réseau MID comprend un identifiant IDp associé au particulier P à qui le dispositif de communication DC appartient. Cet identifiant IDp permet un accès au premier réseau de communication R1 illustrée à la figure 1. L'identifiant sera appelée l'identifiant d'utilisateur réseau IDp dans ce qui suit. Le module d'identification d'utilisateur réseau MID peut être sous forme de, par exemple, une carte SIM, SIM étant l'acronyme du terme anglais « Subscriber Identity Module ». [0037] La mémoire de données MEMpc du dispositif de communication DC comprend une application AP, c'est-à-dire un ensemble de données exécutables, permettant au particulier P, propriétaire du dispositif de communication DC, de définir une transaction et d'effectuer cette transaction au moyen de l'infrastructure INF illustrée à la figure 1. Cette application AP sera appelée application de paiement AP dans ce qui suit. La mémoire de données MEMpp peut également comprendre une application pour effectuer une communication de façon sécurisée comme, par exemple, une application SSL, et une application VPN, SSL étant l'acronyme du terme anglais « Secure Sockets Layer » ; VPN étant l'acronyme du terme anglais « Virtual Private Network ». La mémoire de données MEMpp peut en outre facultativement comprendre une application d'auto-activation pour activer une application de façon automatique à partir d'une information indiquant un contexte d'utilisation du dispositif de communication DC. Cette information peut provenir, par exemple, du module de localisation de type GPS mentionné dans ce qui précède. [0038] La mémoire de données MEMDc du dispositif de communication DC comprend en outre une clé privée KP et un certificat CT. Ces éléments d'authentification permettent au dispositif de communication DC de s'authentifier auprès du serveur de transactions SVT. La clé privée KP peut également contribuer à l'intégrité d'une transaction. Le dispositif de communication DC obtient la clé privée KP et le certificat CT du serveur de transactions SVT, ou une entité associée à celui-ci, ce qui sera décrit plus en détail dans ce qui suit. [0039] Le serveur de transactions SVT comprend une base de données de comptes d'utilisateurs BCU, une base de données de points de paiement BPP, un processeur PRCsvT, et une interface de communication ICSVT. La base de données de comptes d'utilisateurs BCU spécifie un ensemble d'éléments qui sont associés de façon unique à un utilisateur comme le particulier P illustré à la figure 1. Ces éléments, qui constituent un compte utilisateur, comprennent un identifiant et une clé publique associée à une clé privée KP attribuée à l'utilisateur en question. Le compte utilisateur peut également facultativement comprendre un mot de passe convenu avec l'utilisateur en question. Le compte utilisateur peut en outre comprendre un ou plusieurs paramètres relatifs à un processus de définition de transaction. Par exemple, le compte utilisateur peut spécifier un seuil de montant pour une sécurisation supplémentaire par mot de passe. Un mot de passe ne sera demandé que lorsqu'une transaction dépasse ce seuil. [0040] En tout état de cause, le compte utilisateur comprend typiquement un compte monétaire appartenant à l'utilisateur. Ce compte monétaire est dédié aux transactions effectuées par l'intermédiaire de l'infrastructure INF illustrée à la figure 1. Le compte monétaire peut faire l'objet d'opérations de débit et de crédit. Une opération de débit concerne typiquement un achat, un payement effectué par l'intermédiaire de l'infrastructure INF illustrée à la figure 1. Une opération de crédit qui concerne typiquement une alimentation du compte monétaire à partir d'un compte bancaire. Cette alimentation peut s'effectuer par l'intermédiaire du serveur bancaire SVB. [0041] La base de données de points de paiement BPP spécifie un ensemble d'éléments qui sont associés de façon unique au point de paiement PP. Ces éléments comprennent une association du point de paiement PP à une entité de vente, l'identifiant IDPP du point de paiement PP, et une définition d'un ensemble de codes associés de façon unique au point de paiement PP. Cette définition peut comprendre, par exemple, une donnée racine et une identification d'un générateur de code pouvant générer l'ensemble de codes en question. [0042] Pour qu'un particulier propriétaire d'un dispositif de communication puisse utiliser l'infrastructure INF illustrée à la figure 1 pour définir une transaction et pour effectuer cette transaction, une souscription doit être effectuée. Le particulier peut effectuer cette souscription, par exemple, par Internet en accédant à un portail de l'opérateur de services de paiement exploitant le serveur de transactions SVT. Lors de la souscription, le particulier spécifie un ensemble d'éléments personnels comme, par exemple, son nom, son adresse, et ses coordonnées bancaires. De préférence, le portail auprès duquel la souscription est effectuée, ou une autre entité de l'opérateur de services de paiement, vérifie que les éléments que l'utilisateur a spécifiés sont cohérents. [0043] En particulier, lors de la souscription le particulier P spécifie un identifiant d'utilisateur de services de paiement. De préférence, cet identifiant est associée à l'identifiant d'utilisateur réseau IDP présent dans son dispositif de communication. Par exemple, dans le cas où le dispositif de communication DC est un téléphone portable, le particulier P peut spécifier un numéro de téléphone portable comme l'identifiant utilisateur de services de paiement. Le numéro de téléphone portable est associé de façon unique à l'identifiant d'utilisateur réseau IDP compris dans le module d'identification d'utilisateur. [0044] Lors de la souscription le particulier P peut déjà spécifier un ou plusieurs paramètres d'utilisation qui seront appliqués lors d'un processus de définition de transaction. Le seuil de montant pour une sécurisation supplémentaire par mot de passe, qui a été mentionné dans ce qui précède, est un exemple d'un tel paramètre. L'utilisateur peut également spécifier des paramètres relatifs à une alimentation du compte monétaire. Par exemple, l'utilisateur peut spécifier un seuil pour déclencher l'alimentation du compte monétaire. Dans le cas où le compte monétaire présente un montant en dessous ce seuil de déclenchement, un crédit est automatiquement effectué à partir d'un compte bancaire associé au compte monétaire. L'utilisateur peut également spécifier un montant standard pour alimenter le compte monétaire. Le crédit automatiquement effectué sera donc à hauteur du montant standard. [0045] Lors de la souscription, le portail, ou une autre entité de l'opérateur de services de paiement, génère un mot de passe d'activation à usage unique et à caractère aléatoire. Le particulier P reçoit le mode passe d'activation sous forme de, par exemple, un message SMS, SMS étant l'acronyme du terme anglais « Short Message Service ». Il est supposé que le particulier P a déjà téléchargé sur son dispositif de communication DC l'application de paiement AP mentionné dans ce qui précède. En fait, le particulier P peut être invité à effectuer ce téléchargement dans une étape précédant lors de la souscription. [0046] Le particulier P lance l'application de paiement AP qui se connecte au serveur de transactions SVT. L'application de paiement AP invite l'utilisateur à spécifier le mot de passe d'activation qu'il a reçu, ainsi que l'identifiant d'utilisateur de services de paiement qu'il a spécifié lors de la souscription comme, par exemple, son numéro de téléphone portable. Lorsque l'utilisateur a spécifié ces éléments, l'application de paiement AP amène le dispositif de communication DC à transmettre au serveur de transactions SVT des données d'activation. Les données d'activation comprennent le mot de passe d'activation, l'identifiant d'utilisateur de services de paiement, et un identifiant matériel associé de façon unique au dispositif de communication DC. [0047] Le serveur de transactions SVT reçoit les données d'activation et les vérifie. En outre, le serveur de transactions SVT vérifie que les données d'activation sont reçues dans un intervalle de temps suite à l'instant où le mot de passe d'activation a été envoyé le particulier P. Dans le cas ou ces vérifications sont positives, le serveur de transactions SVT crée un certificat CT et une clé privée KP à partir de, par exemple, l'identifiant matériel et une donnée à caractère aléatoire. Le serveur de transactions SVT transmet le certificat CT et la clé privée KP au dispositif de communication DC du particulier P accompagné d'un message d'activation. Puis, le serveur de transactions SVT détruit le certificat CT de la clé privée KP afin de garantir qu'aucune entité autre que le dispositif de communication DC ne détienne ces éléments. Ainsi, la souscription a donnée lieu à la création d'un compte utilisateur dans la base de données de comptes d'utilisateurs BCU. [0048] L'application de paiement AP sur le dispositif de communication DC réceptionne le certificat CT et la clé privée KP pour que ces éléments soient stockés de façon sécurisée. L'application enregistre un statut « actif » ce qui permet au particulier P d'utiliser l'infrastructure INF illustrée à la figure 1 pour définir une transaction et pour effectuer celle-ci. [0049] La figure 2 illustre un procédé pour définir une transaction et pour effectuer cette transaction. Ce procédé est mis en oeuvre dans l'infrastructure INF illustrée à la figure 1 et décrite dans ce qui précède. Ce procédé comprend une série d'étapes impliquant différentes entités dans cette infrastructure INF. La figure 2 est organisée en trois colonnes correspondant à trois différentes entités. En allant de gauche à droite, une première colonne représente des étapes effectuées par le dispositif de communication DC, une seconde colonne représente des étapes effectuées par le serveur de transactions SVT, une troisième colonne représente des étapes effectuées par le point de paiement PP. [0050] Les étapes représentées dans la première colonne peuvent être considérées comme une représentation sous forme d'organigramme d'un ensemble de données exécutables permettant au dispositif de communication DC d'effectuer diverses opérations décrites dans ce qui suit en référence à la figure 2. De même, les étapes représentées dans la seconde et la troisième colonne peuvent respectivement être considérées comme des représentations sous forme d'organigramme de deux ensembles de données exécutables permettant respectivement au serveur de transactions SVT et au point de paiement PP d'effectuer diverses opérations décrites dans ce qui suit en référence à la figure 2. A cet égard, il convient de noter que l'application de paiement AP mentionné dans ce qui précède en référence à la figure 1 constitue un ensemble de données exécutables présent dans le dispositif de communication DC. [0051] Dans une première étape El, le dispositif de communication DC commence à exécuter l'application de paiement AP. Le particulier P peut manuellement lancer cette exécution de l'application de paiement AP. Dans le cas où le dispositif de communication DC comprend une application d'auto-activation décrite dans ce qui précède, cette application peut également lancer l'application de paiement AP. Par exemple, le dispositif de communication DC peut recevoir une information indiquant que celui-ci se trouve dans un magasin, ou se trouve à proximité d'un magasin. Cette information peut provenir, par exemple, d'un module de localisation de type GPS ou d'une interface de réseau sans fil de type « WiFi » recevant un identifiant associé à un magasin ou un autre type de point de vente. [0052] Dans une seconde étape E2, l'application de paiement AP amène le dispositif de communication DC à se connecter au serveur de transactions SVT de façon communicative (DCHSVT). Le dispositif de communication DC transmet l'identifiant d'utilisateur de services de paiement au serveur de transactions SVT.

Le dispositif de communication DC peut également s'authentifier auprès du serveur de transactions SVT au moyen du certificat CT établi lors de la souscription comme décrit dans ce qui précède. En fait, la seconde étape E2 peut être considérée comme une demande d'ouverture de session de paiement. Une cession de paiement implique une communication entre le dispositif de communication DC et le serveur de transactions SVT avec divers échanges décrits dans ce qui suit. [0053] Dans une troisième étape E3, le serveur de transactions SVT vérifie la base de données de comptes d'utilisateurs BCU pour connaître les paramètres d'utilisation spécifiés par le particulier P et donc applicables (INT_BCU). Par exemple, le particulier P peut avoir subordonné une session d'utilisation à la fourniture du mot de passe convenue entre le particulier P et le serveur de transactions SVT. Dans ce cas, le serveur de transactions SVT transmet une demande de mot de passe au dispositif de communication DC. Le serveur de transactions SVT n'ouvre alors une session de paiement qu'à condition d'une réception du mot de passe en provenance du dispositif de communication DC. De plus, une condition supplémentaire peut s'appliquer : le mot de passe doit être reçu dans un intervalle de temps prédéfini. Dans le cas où le particulier P n'a pas subordonné une session de paiement à la fourniture du mot de passe, le serveur de transactions SVT ouvre directement une session de paiement. [0054] Dans la troisième étape E3, le serveur de transactions SVT peut envoyer un identifiant de session au dispositif de communication DC. Le dispositif de communication DC peut ensuite utiliser cet identifiant de session dans des transmissions de messages vers le serveur de transactions SVT. Le serveur de transactions SVT peut ainsi reconnaître qu'un message provient du dispositif de communication DC. Le serveur de transactions SVT peut donc associer ce message au compte d'utilisateur du particulier P. L'identifiant de session est de préférence une donnée à caractère aléatoire. De plus, l'identifiant de session est de préférence transmis d'une façon sécurisée en appliquant, par exemple, un chiffrage. [0055] Il est supposé que le particulier P se présente auprès du point de paiement PP sous forme d'une caisse opérée par une caissière. Le particulier P indique oralement à la caissière qu'il souhaite effectuer un paiement par l'intermédiaire de l'opérateur de services de paiement en utilisant son dispositif de communication DC. Ce mode de paiement sera désigné comme mode de paiement mobile et anonyme dans ce qui suit. [0056] Dans une quatrième étape E4, le point de paiement PP reçoit une information de la caissière par l'intermédiaire de l'interface opérateur 10. Cette information indique que le particulier P souhaite utiliser le mode de paiement mobile et anonyme. En outre, le point de paiement PP reçoit de la même façon d'autres informations permettant de définir au moins partiellement la transaction à effectuer. Ces informations comprennent des éléments traditionnellement présents sur un ticket de caisse. Pour des raisons de convenance, ces éléments seront donc désignés comme « ticket de caisse » dans ce qui suit. [0057] Dans la quatrième étape E4 encore, le point de paiement PP transmet le ticket de caisse au serveur de transactions SVT (TR_TC). Le ticket de caisse est accompagné de l'identifiant IDpp du point de paiement PP. De préférence, cette transmission de données est effectuée de façon sécurisée, par exemple, par une connexion SSL ou une connexion VPN. La transmission peut nécessiter une authentification du point de paiement PP auprès du serveur de transactions SVT afin que la transmission soit considérée comme valable. [0058] Dans une cinquième étape E5, le point de paiement PP présente un code de localisation propre au point de paiement PP (PR_CD). C'est-à-dire, aucun autre point de paiement PP ne devrait typiquement présenter ce code. De préférence, le code de localisation présenté au point de paiement PP change régulièrement de façon aléatoire. Par exemple, le point de paiement PP peut présenter un nouveau code de localisation pour chaque nouveau paiement à effectuer. Pour ce faire, le générateur de code faisant partie du point de paiement PP peut être agencé pour générer une séquence de code pseudo-aléatoire à partir d'une donnée racine. Le code de localisation est alors un code d'une telle séquence. [0059] Le point de paiement PP peut présenter le code de localisation suite à une détection du dispositif de communication DC à proximité du point de paiement PP. Cette détection peut être basée sur, par exemple, un champ électromagnétique émis par le dispositif de communication DC. De façon alternative, ou complémentaire, le code de localisation peut apparaître lorsque le point de paiement PP reçoit l'information de la caissière indiquant que le particulier P souhaite utiliser le mode de paiement mobile et anonyme. [0060] Le point de paiement PP peut présenter le code de localisation de diverses façons. Par exemple, le code de localisation peut être présenté sous forme d'un son audio tel que décrit dans le brevet français FR 2 886 753. Le code de localisation peut également être présenté sous forme d'une représentation visuelle pouvant exprimer un code, tel qu'un code barre monodimensionnelle ou bidimensionnelle. Par exemple, le point de paiement PP peut comprendre un dispositif d'affichage orienté vers le particulier P pour afficher une telle représentation visuelle. Selon une autre variante, le point de paiement PP peut présenter le code de localisation au moyen d'un champ électromagnétique modulé. Par exemple, le point de paiement PP peut comprendre un module pour une communication à champ proche (en anglais : near field communication, dont l'acronyme est NFC), ou un module d'identification radiofréquence (en anglais : radio-frequency identification, dont l'acronyme est RFID). [0061] Dans une sixième étape E6, le dispositif de communication DC capte le code de localisation présenté au point de paiement PP. En fait, l'application de paiement AP peut mettre le dispositif de communication DC dans un mode de captage de code suite au lancement de cette application. Dans une variante, le particulier P peut faire basculer le dispositif de communication DC dans ce mode. Le dispositif de communication DC comprend typiquement un composant apte à capter le code de sorte qu'il n'est pas nécessaire d'ajouter un composant spécifique. Un microphone permet de capter un code de localisation sous forme d'un son audio. Un camera permet de capter un code de localisation sous forme d'une représentation visuelle. Un module de type NFC ou RFID permet de capter un code de localisation sous forme d'un champ électromagnétique modulée. [0062] Dans la sixième étape E6 encore, le dispositif de communication DC convertit le code de localisation que celui-ci a capté en une représentation numérique ayant un format spécifique (C_CD=CDC). Pour ce faire, l'application de paiement AP peut comprendre un module apte à faire cette conversion. La représentation numérique du code de localisation sera appelée « code de localisation converti » dans ce qui suit. Le code de localisation converti peut éventuellement correspondre à l'identifiant IDPP du point de paiement PP. En tout état de cause, ce code désigne de façon non-équivoque le point de paiement PP. [0063] Dans la sixième étape E6 encore, le dispositif de communication DC transmet au serveur de transactions SVT le code de localisation converti (TR CDC). Cette transmission comprend l'identifiant de session, ou un autre identifiant comme, par exemple, l'identifiant d'utilisateur de services de paiement.

Ce qui compte c'est que le serveur de transactions SVT puisse reconnaître que cette transmission du code de localisation provient du dispositif de communication DC en question. De préférence, la transmission du code de localisation est effectuée de façon sécurisée, par exemple, par une connexion SSL ou une connexion VPN. [0064] Le serveur de transactions SVT est donc susceptible de recevoir deux transmissions : une transmission en provenance du point de paiement PP et une transmission en provenance du dispositif de communication DC. La transmission en provenance du point de paiement PP comprend le ticket de caisse et l'identifiant IDPP du point de paiement PP. Cette transmission s'effectue lors de la quatrième étape E4 décrite dans ce qui précède. La transmission en provenance du dispositif de communication DC comprend le code de localisation converti accompagné d'un identifiant associé au particulier P, tel que l'identifiant d'utilisateur de services de paiement ou l'identifiant de session. Cette transmission s'effectue lors de la sixième étape E6 décrite dans ce qui précède. [0065] Les deux transmissions précitées ne sont pas nécessairement simultanées et, de plus, n'ont pas nécessairement un ordre prédéfini. Le serveur de transactions SVT peut recevoir la transmission en provenance du dispositif de communication DC, qui comprend le code de localisation, avant la transmission en provenance du point de paiement PP, qui comprend le ticket de caisse. C'est-à-dire, chronologiquement parlant, la quatrième étape E4 décrite dans ce qui précède ne s'effectue pas nécessairement avant la sixième étape E6, et vice versa. [0066] Dans une septième étape E7, le serveur de transactions SVT vérifie que les deux transmissions précitées sont reçues dans un intervalle de temps prédéfini (VER TR). Autrement dit, le serveur de transactions SVT vérifie que la transmission comprenant le code de localisation converti est reçue dans l'intervalle de temps prédéfini par rapport à la transmission comprenant le ticket de caisse, peu importe laquelle des deux transmissions a été reçue en premier. Dans le cas où cette vérification est positive, la session de paiement se poursuit, ce qui implique que d'autres étapes du procédé illustré à la figure 2 seront effectuées. Dans le cas où cette vérification est négative, le serveur de transactions SVT peut envoyer un message d'échec de transaction au point de paiement PP ou au dispositif de communication DC, en fonction duquel des deux a effectué une première transmission. La session de paiement se termine sans qu'une définition de transaction soit établie. [0067] Plus en détail, il est supposé que le serveur de transactions SVT reçoit en premier la transmission en provenance du point de paiement PP, qui comprend le ticket de caisse. Le serveur de transactions SVT vérifie alors que dans l'intervalle de temps prédéfini suivant cette première réception, le serveur de transactions SVT reçoit la transmission en provenance du dispositif de communication DC, qui comprend le code de localisation converti. Dans la négative, le serveur de transactions SVT envoie un message d'échec de transaction au point de paiement PP. La session de paiement est terminée. [0068] Le serveur de transactions SVT effectue une vérification similaire dans le cas où le serveur de transactions SVT reçoit en premier la transmission en provenance du dispositif de communication DC, qui comprend le code de localisation converti. Est-ce que dans l'intervalle de temps prédéfini qui suit cette première réception, il y a réception de la transmission en provenance du point de paiement PP, qui comprend le ticket de caisse ? Dans la négative, le serveur de transactions SVT envoie un message d'échec de transaction au dispositif de communication DC. La session de paiement est terminée. [0069] De préférence, le serveur de transactions SVT s'assure également que les transmissions en question ont été reçues par l'intermédiaire d'un canal de communication sécurisée. Le serveur de transactions SVT rejette alors une telle transmission dans le cas où la transmission n'est pas sécurisée. Si un tel rejet n'est pas suivi par une retransmission de façon sécurisée, la session de paiement se termine sans qu'une définition de transaction soit établie. [0070] Dans la septième étape E7 encore, le serveur de transactions SVT fait un rapprochement entre la transmission en provenance du dispositif de communication DC et la transmission en provenance du point de paiement PP (CDCHTC). Ce rapprochement se fait par le biais de deux données : (i) le code de localisation converti compris dans la transmission en provenance du dispositif de communication DC, et (ii) l'identifiant IDpp du point de paiement PP compris dans la transmission en provenance du point de paiement PP. En fait, le rapprochement est déjà implicite dans la vérification sur l'intervalle de temps prédéfini décrite dans ce qui précède. Grâce à ce rapprochement, le serveur de transactions SVT sait, en quelque sorte, que le ticket de caisse est destiné au particulier P propriétaire du dispositif de communication DC. Le serveur de transactions SVT dispose donc des éléments de base pour définir une transaction : le particulier P propriétaire du dispositif de communication DC constitue une partie acheteur, l'entité de vente associée au point de paiement PP constitue une partie vendeur, le ticket de caisse constitue une définition d'un objet de la transaction. [0071] Dans une huitième étape E8, le serveur de transactions SVT se met en communication avec le serveur de gestion d'avantages commerciaux SVA (SVTHSVA). Ainsi, le serveur de transactions SVT peut identifier des avantages commerciaux, s'il y en a, qui sont à ajouter au ticket de caisse. Les avantages commerciaux peuvent être sous forme, par exemple, d'une réduction de prix, d'une ristourne, d'un bon d'achat, ou d'un coupon de réduction pour un futur achat. Par exemple, le serveur de gestion d'avantages commerciaux SVA peut gérer un compte de points de fidélité appartenant au particulier P et attribué par l'entité de vente associée au point de paiement PP. Un nombre donné de points de fidélité acquis peuvent donner lieu à un avantage commercial. Le serveur de gestion d'avantages commerciaux SVA peut également gérer des promotions offertes par l'entité de vente ou, plus particulièrement, le magasin en question. Par exemple, un achat dans une période particulière peut donner lieu à un avantage commercial. Cette offre promotionnelle peut s'appliquer à tout client ou peut être réservée à un groupe de clients particulier. [0072] En tout état de cause, le serveur de transactions SVT est à même d'obtenir des éléments supplémentaires à intégrer dans une définition de la transaction en interrogeant une ou plusieurs bases de données, dans le cas d'espèce par l'intermédiaire du serveur de gestion d'avantages commerciaux SVA. Pour ce faire, le serveur de transactions SVT dispose des éléments nécessaires : une identification de la partie acheteur, une identification de la partie vendeur, et une spécification de l'objet de la transaction. En outre, le serveur de transactions SVT dispose d'autres éléments utiles : une indication de date et heure pour la transaction à effectuer ainsi qu'une indication de lieu. En fait, le code de localisation atteste que le particulier P se trouve au point de paiement PP concerné. [0073] Dans une neuvième étape E9, le serveur de transactions SVT établit une définition de la transaction à effectuer (DEF_TA). La définition spécifie le particulier P en tant que partie acheteur, l'entité de vente associée au point de paiement PP en tant que partie vendeur, le ticket de caisse en tant qu'objet de la transaction, complété par un ou plusieurs avantages commerciaux, s'il y en a, identifiés dans la huitième étape E8. Le serveur de transactions SVT détermine ainsi un montant de la transaction. [0074] La définition de la transaction peut être soumise à une vérification du compte monétaire du particulier P. Par exemple, dans le cas où le compte monétaire présente un solde insuffisant, en tenant compte d'une éventuelle alimentation de celui-ci, le serveur de transactions SVT peut ne pas établir la définition de la transaction. Le serveur de transactions SVT peut émettre une notification de cette impossibilité au dispositif de communication DC et au point de paiement PP. Le serveur de transactions SVT peut également vérifier si la condition suivante s'applique ou non : le montant de la transaction dépasse un seuil pour une sécurisation supplémentaire par mot de passe. [0075] Dans la neuvième étape E9 encore, le serveur de transactions SVT transmet la définition de la transaction à effectuer au dispositif de communication DC pour validation. Cette transmission peut comprendre une demande de mot de passe, par exemple, dans le cas où le montant de la transaction dépasse le seuil précité. [0076] Dans une dixième étape E10, le dispositif de communication DC affiche la définition de la transaction à effectuer reçue du serveur de transactions SVT. Le particulier P peut ainsi vérifier cette définition. Le dispositif de communication DC invite le particulier P à donner son accord ou son refus (VAL / REF). Le dispositif de communication DC peut également inviter le particulier P à entrer un mot de passe relatif à un dépassement d'un seuil de montant. Ce mot de passe peut être identique au mot de passe utilisé pour déclencher une session de paiement, si un tel mot de passe à été défini. [0077] Lorsque le particulier P a validé ou refusé la définition de la transaction, le dispositif de communication DC transmet au serveur de transactions SVT un message indiquant cette validation ou ce refus, selon ce qui s'applique. De préférence, le dispositif de communication DC revêt ce message d'une signature électronique à partir de la clé privée KP reçue lors de la souscription. Ceci s'applique notamment dans le cas où le message indique la validation de la définition de la transaction. [0078] Dans une onzième étape El 1, le serveur de transactions SVT vérifie que, dans un intervalle de temps donné suite à la transmission de la définition de la transaction à effectuer lors de la neuvième étape E9, un message en provenance du dispositif de communication DC a été reçu indiquant la validation ou le refus cette définition (VER_RM). Si cette vérification est négative, le serveur de transactions SVT abandonne la définition de la transaction ; la définition n'est plus ouverte à la validation. De préférence, le serveur de transactions SVT efface la définition de la transaction pour des raisons de sécurité et de confidentialité. Dans le cas où le serveur de transactions SVT reçoit un message indiquant le refus, le serveur de transactions SVT en informe le point de paiement PP. Dans ce qui suit, il est supposé que le serveur de transactions SVT reçoit un message indiquant la validation de la définition de la transaction. [0079] Dans une douzième étape E12, le serveur de transactions SVT vérifie le message indiquant la validation de la définition de la transaction (VER VAL). Dans le cas où ce message est revêtu d'une signature électronique, le serveur de transactions SVT vérifie cette signature au moyen de la clé publique associée à la clé privée KP mentionnée dans ce qui précède. Cette vérification atteste que la validation provient bien du particulier P et constitue un élément de non répudiation. Dans le cas où le serveur de transactions SVT a demandé un mot de passe, tel que décrit en relation avec la neuvième étape E9, le serveur de transactions SVT vérifie que le message comprend bien le mot de passe demandé. Dans le cas où une quelconque de ces vérifications est négative, la session de paiement se termine sans qu'une transaction soit effectuée. Le serveur de transactions SVT en informe le dispositif de communication DC et le point de paiement PP. Dans le cas où toutes vérifications sont positives, la session de paiement continue, ce qui implique que d'autres étapes du procédé illustré à la figure 2 seront effectuées. [0080] Dans une treizième étape E13, le serveur de transactions SVT effectue la transaction dont la définition a été validée par le particulier P (EFF_TA). Le serveur de transactions SVT débite le montant de la transaction du compte monétaire du particulier P et crédite du même montant un compte monétaire de l'entité de vente. Ce transfert monétaire peut nécessiter une alimentation du compte monétaire du particulier P, ou déclencher une telle alimentation. Pour ce faire, le serveur de transactions SVT peut se mettre en relation avec le serveur bancaire SVB. Le serveur de transactions SVT peut également prélever du compte monétaire du particulier P une commission qui est due à l'opérateur de services de paiement. [0081] Le serveur de transactions SVT peut générer un identifiant de la transaction effectuée sous forme, par exemple, d'un numéro unique. Cet identifiant peut être utilisé pour faire référence à la transaction dans une base de données qui peut faire partie du serveur de transactions SVT ou d'une autre entité comme, par exemple, le serveur bancaire SVB ou le serveur de gestion d'avantages commerciaux SVA. [0082] Dans le cas où la transaction implique des acquis de fidélité, le serveur de transactions SVT se met en relation avec le serveur de gestion d'avantages commerciaux SVA. Par exemple, la transaction peut comprendre une consommation d'un nombre de points de fidélité. Le serveur de gestion d'avantages commerciaux SVA débite alors le nombre de points de fidélité du compte de points de fidélité concerné. Dans un autre exemple, la transaction peut donner lieu à un crédit d'un certain nombre de points de fidélité qui peut être lié au montant de la transaction ou d'autres éléments de la transaction. [0083] Dans une quatorzième étape E14, le serveur de transactions SVT transmet au dispositif de communication DC un message confirmant que la transaction a été effectuée (TR_CONF). Ce message de confirmation peut comprendre un récapitulatif de la transaction. Le serveur de transactions SVT peut également envoyer un tel message de confirmation au point de paiement PP. Le serveur de transactions SVT archive une description de la transaction effectuée dans une base de données d'archivage centrale (ARCH). [0084] Dans une quinzième étape E15, le dispositif de communication DC archive également une description de la transaction effectuée dans, par exemple, une mémoire qui fait partie du dispositif de communication DC (ARCH). Cet archivage s'effectue suite à la réception du message de confirmation en provenance du serveur de transactions SVT. Le particulier P dispose donc d'un ticket de caisse sous forme dématérialisée. Le particulier P peut ainsi avoir une vue sur divers achats qu'il a effectués au moyen du dispositif de communication DC. Cette information peut servir pour établir une liste de course. Lorsque le particulier P se trouve dans un magasin, l'application de paiement AP, ou une autre application sur son dispositif de communication DC, peut établir une liste de divers produits que le particulier P a précédemment achetés dans ce magasin. [0085] L'infrastructure INF illustrée à la figure 1 permet de mettre en oeuvre d'autres procédés que celui illustré à la figure 2 et décrit dans ce qui précède. En fait, dans le procédé illustré à la figure 2, une spécification de l'objet de la transaction est établie par l'entité de vente, plus particulièrement par la caissière au point de paiement PP. Dans un autre procédé, le particulier P peut définir une spécification de l'objet de la transaction. C'est-à-dire, le particulier P peut prendre une initiative pour définir une transaction à effectuer. Un tel procédé sera décrit dans ce qui suit et désigné « procédé à l'initiative du particulier ». [0086] Le particulier P peut établir une spécification de l'objet de la transaction lorsqu'il fait un parcours d'achat dans un magasin. Par exemple, le dispositif de communication DC peut être équipé pour lire des codes apposés sur des produits présents dans le magasin et pour convertir ces codes en description de produits, y compris leurs prix. Le particulier P peut ainsi préparer une commande de façon conviviale et facile en faisant lire son dispositif de communication DC les codes sur les produits qu'il souhaite acheter. A la fin du parcours d'achat, la commande est finalisée et le particulier P se présente à un point de paiement, tel que le point de paiement PP illustré à la figure 1. [0087] Au point de paiement PP, le particulier P initie une session de paiement par exemple en lançant une exécution de l'application de paiement AP. Puis, le dispositif de communication DC s'authentifie auprès du serveur de transactions SVT dans des étapes similaires à la seconde étape E2 et à la troisième étape E3 décrites dans ce qui précède en référence à la figure 2. Le point de paiement PP présente un code de localisation dans une étape similaire à la cinquième étape E5 décrite dans ce qui précède. Le dispositif de communication DC transmet une représentation de ce code de localisation au serveur de transactions SVT dans une étape similaire à la sixième étape E6 décrite dans ce qui précède. En outre, le dispositif de communication DC transmet la commande que le particulier P a établie lors de son parcours d'un achat dans le magasin. [0088] Puis, le serveur de communication établit une définition de la transaction à effectuer dans une étape similaire à la neuvième étape E9 décrite dans ce qui précède. La définition spécifie la commande préparée par le particulier P en tant qu'objet de la transaction. Les étapes qui suivent peuvent être similaires aux étapes qui suivent la neuvième étape E9 décrite dans ce qui précède. Les informations transmises au point de paiement PP peuvent également être transmises à une autre entité appartenant au magasin en question. Cette alternative s'applique typiquement dans le cas où le point de paiement PP fonctionne sans opérateur. [0089] Dans une variante du procédé à l'initiative du particulier décrit dans ce qui précède, le particulier P peut établir une spécification de l'objet de la transaction avant d'entrer dans un magasin. Par exemple, le particulier P peut visiter un site Web du magasin en utilisant son dispositif de communication DC. Ce site Web peut permettre au particulier P de préparer une commande en sélectionnant un ou plusieurs produits proposés sur ce site. Dans ce cas, la commande est déjà prête lorsque le particulier P entre dans le magasin pour prendre et acheter les produits sélectionnés. La commande peut être transmise au préalable au serveur de transactions SVT qui stocke la commande avec un identifiant qui permet de faire référence à la commande. [0090] Pour effectuer la transaction, il suffit que le particulier P se présente à un point de paiement, tel que le point de paiement PP illustré à la figure 1, pour que le dispositif de communication DC puisse lire un code de localisation présenté au point de paiement PP. Le serveur de transactions SVT reçoit alors une transmission du dispositif de communication DC comprenant au moins deux éléments : une représentation du code de localisation et une référence à la commande sous forme de l'identifiant précité. Cette transmission constitue en effet une demande de paiement. [0091] REMARQUES FINALES [0092] La description détaillée donnée ci-dessus en se référant aux figures n'est qu'une illustration de l'invention parmi d'autres. L'invention peut être réalisée de diverses façons. Afin d'illustrer ceci, quelques alternatives sont indiquées sommairement. [0093] Il existe différentes infrastructures permettant de mettre en oeuvre l'invention. Par exemple, un seul réseau de communication suffit pour mettre en oeuvre l'invention. Dans un tel mode de réalisation, diverses entités peuvent communiquer avec un serveur de transactions par l'intermédiaire de ce seul réseau de communication. Il n'est pas nécessaire qu'un point de paiement comprenne une interface de communication pour recevoir des messages en provenance du serveur de transactions. En fait, il suffit que le point de paiement présente un code qui peut être transmis au serveur de transactions par l'intermédiaire du dispositif de communication. Le serveur de transactions peut envoyer divers messages concernant une transaction (échec, validation, refus, confirmation) à un dispositif appartenant à une entité de vente autre que le point de paiement. Par exemple, ces messages peuvent être envoyés à un poste de surveillance dans un magasin. Il convient également de noter qu'un dispositif de communication n'est pas nécessairement sous forme d'un téléphone portable. Par exemple, le dispositif de communication peut être sous forme d'un assistant personnel numérique, en anglais : « Personal Digital Assistant » dont l'acronyme est P DA. [0094] Le terme « communication » doit être interprété de façon large. Ce terme embrasse toute forme de transmission d'information qui peut comprendre une seule transmission ou une séquence de transmissions. Le terme « serveur » doit être interprété de façon large. Ce terme embrasse toute forme d'entité apte à traiter des données et de communiquer avec d'autres entités ayant cette même aptitude. Le terme « bases de données » doit être interprété de façon large. Ce terme embrasse tout type d'entité informatique comprenant des données et permettant d'interroger ces données de façon globale et homogène. [0095] Par ailleurs, bien que les dessins montrent différentes entités fonctionnelles sous la forme de différents blocs, cela n'exclut en aucune manière des réalisations où une seule entité physique effectue plusieurs fonctions, ou inversement des réalisations où plusieurs entités physiques effectuent collectivement une seule fonction. [0096] Il existe de nombreuses entités fonctionnelles pouvant être implémentées au moyen de matériel (en anglais: hardware) ou de logiciel (en anglais: software) ou une combinaison de matériel et de logiciel. La description d'une implémentation sous forme de logiciel n'exclut nullement des implémentations sous forme de matériel, et vice versa. Des implémentations hybrides sont également possibles dans le sens où un système, ou une entité fonctionnelle comprise dans le système, comprend un ou plusieurs circuits dédiés ainsi qu'un ou plusieurs processeurs convenablement programmés. [0097] Les remarques qui précèdent montrent que la description détaillée et les figures illustrent l'invention plutôt qu'elles ne la limitent. En particulier, les signes de références n'ont aucun caractère limitatif. Les verbes « comprendre », « inclure » et « comporter » éventuellement utilisés n'excluent pas la présence d'autres éléments ou d'autres étapes que ceux listés dans les revendications. Le mot « un » ou « une » précédant un élément ou une étape n'exclut pas la présence d'une pluralité de tels éléments ou de telles étapes.

Claims

REVENDICATIONS1. Procédé pour définir une transaction à effectuer dans lequel un serveur de transactions (SVT) établit une définition de la transaction à effectuer lorsque le serveur de transactions a reçu une communication en provenance d'un dispositif de communication (DC), la communication comprenant : - une représentation d'un identifiant (CT) associé à une partie acheteur, et - une représentation d'un code (CD) présenté à un point de paiement (PP) associé à une partie vendeur, le serveur de transactions obtenant une spécification d'un objet de la transaction par un des schémas suivants : - la communication comprend la spécification de l'objet de la transaction, - la communication comprend une référence à la spécification de l'objet de la transaction ayant préalablement été reçue par le serveur de transactions, et - la communication est reçue dans un intervalle de temps donné par rapport à une autre communication en provenance du point de paiement, cette autre communication comprenant la spécification de l'objet de la transaction accompagnée d'un identifiant (IDpp) du point de paiement.
2. Procédé selon la revendication 1 comprenant : - une étape d'interrogation (E8) dans laquelle le serveur de transactions (SVT) interroge une base de données à partir d'au moins un des éléments suivants : la partie vendeur, la partie acheteur, et l'objet de la transaction, pour vérifier si la base de données comprend un élément supplémentaire à intégrer dans la définition de la transaction.
3. Procédé selon l'une quelconque des revendications précédentes, dans lequel le serveur de transactions (SVT) n'établit la définition de la transaction qu'à condition que la communication comprenne un mot de passe ayant préalablement été convenu entre la partie acheteur et le serveur de transactions. 25
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel le serveur de transactions (SVT) n'établit la définition de la transaction qu'à condition que la communication s'effectue à travers un canal de communication sécurisé.
5. Procédé selon l'une quelconque des revendications précédentes, comprenant : - une étape préalable dans lequel le serveur de transactions (SVT) reçoit la spécification de l'objet de la transaction en provenance du dispositif de communication (DC) et en association avec l'identifiant (CT) associé à la partie acheteur.
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel le code (CD) présenté au point de paiement (PP) appartient à une séquence de codes pseudo-aléatoire associée de façon unique au point de paiement.
7. Procédé selon l'une quelconque des revendications précédentes, dans lequel la communication comprend une donnée numérique résultant d'une conversion du code présenté au point de paiement (PP) sous forme d'un signal sonore, la conversion étant effectuée par le dispositif de communication (DC) captant le signal sonore.
8. Procédé selon l'une quelconque des revendications précédentes, comprenant : une étape de demande de confirmation (E9) dans laquelle le serveur de transactions (SVT) envoie la définition de la transaction établie à la partie vendeur pour confirmation.30
9. Procédé selon la revendication 8 comprenant : une étape d'effacement (El 1) dans laquelle le serveur de transactions (SVT) efface la définition de la transaction lorsque le serveur de transactions n'a reçu aucune confirmation pour cette transaction de la partie vendeur dans un intervalle de temps prédéfini suite à l'étape de demande de confirmation.
10. Procédé pour effectuer une transaction dans lequel le procédé selon la revendication 8 est appliqué pour établir une définition de la transaction à effectuer, le procédé comprenant : - une étape de réception de confirmation (E12) dans lequel le serveur de transactions (SVT) reçoit une confirmation de la partie vendeur relative à la définition de la transaction envoyée, la transaction étant effectuée (E13) suite à cette étape de réception de confirmation.
11. Procédé selon la revendication 10, dans lequel la transaction n'est effectuée qu'à condition que la confirmation de la partie vendeur comprenne une signature électronique authentifiant la partie vendeur.
12. Procédé selon l'une quelconque des revendications 10 et 11, comprenant : - une étape de débit (E13) dans laquelle le serveur de transactions (SVT) débite un compte monétaire appartenant à la partie vendeur suite à l'étape de réception de confirmation (E12).
13. Procédé selon l'une quelconque des revendications 10 à 12, comprenant : - une étape d'archivage central (E14) dans laquelle le serveur de transactions (SVT) archive une description de la transaction effectuée dans une base de données d'archivage centrale.
14. Procédé selon l'une quelconque des revendications 10 à 13, comprenant :- une étape d'attribution d'avantages commerciaux dans laquelle le serveur de transactions (SVT) crédite un compte appartenant à la partie acheteur lorsque la transaction a été effectuée.
15. Programme pour un processeur (PRCsvT), le programme comprenant des données exécutables par le processeur pour l'exécution des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur le processeur.
16. Système pour définir une transaction à effectuer, le système comprenant un serveur de transactions (SVT) apte à établir une définition de la transaction à effectuer lorsque le serveur de transactions a reçu une communication en provenance d'un dispositif de communication (DC), la communication comprenant : 15 - une représentation d'un identifiant (CT) associé à une partie acheteur, et - une représentation d'un code (CD) présenté à un point de paiement (PP) associé à une partie vendeur, le serveur de transactions obtenant une spécification d'un objet de la transaction 20 par un des schémas suivants : - la communication comprend la spécification de l'objet de la transaction, - la communication comprend une référence à la spécification de l'objet de la transaction ayant préalablement été reçue par le serveur de transactions, et - la communication est reçue dans un intervalle de temps donné par 25 rapport à une autre communication en provenance du point de paiement, cette autre communication comprenant la spécification de l'objet de la transaction accompagnée d'un identifiant (IDpp) du point de paiement.