DE PAIEMENT.

La présente invention concerne un procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement et un produit programme d'ordinateur pour mettre en œuvre le procédé.

Il est connu différents moyens pour recueillir l'avis d'un utilisateur sur une prestation ou un achat qu'il a effectué.

Par exemple, si l'achat a eu lieu à distance en utilisant internet et que l'acheteur a laissé une adresse de courriel au commerçant, ce dernier, directement ou par l'intermédiaire d'un prestataire, peut envoyer un courriel à l'acheteur quelque temps après l'achat pour l'inciter à remplir un questionnaire en ligne sur sa satisfaction concernant l'achat.

Un autre moyen consiste à inciter les acheteurs à laisser des appréciations sur des sites spécialisés, appréciations qui seront à la libre disposition des autres utilisateurs du site. C'est ainsi qu'il existe, par exemple, des sites qui listent les restaurants d'une ville ou d'une région et qui proposent en plus d'une fiche signalétique des restaurants et, éventuellement des commentaires par les gestionnaires du site, une zone de forum sur laquelle les consommateurs peuvent laisser des appréciations en lien avec le(s) restaurant(s) listé(s).

Ce type de commentaires peut être accompagné d'une sorte de classement consolidé composé par la moyenne d'une note d'appréciation donnée par les différents utilisateurs.

Dans la réalité, on s'aperçoit que, par exemple sur les sites de restaurants, chaque restaurant n'est noté que par une très infime minorité, souvent moins d'une dizaine de personnes, avec des opinions souvent très contrastées et donc la représentativité des opinions recueillies est extrêmement faible, et l'utilisation difficile, d'autant que la garantie n'est souvent pas apportée que le votant a été un consommateur effectif. II serait donc particulièrement avantageux d'établir un procédé d'acquisition fiable d'opinions qui permette le recueil d'un nombre d'opinions suffisamment représentatif, recueillies avec une qualité suffisante.

Pour résoudre un ou plusieurs des inconvénients cités précédemment, un procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement, comporte :

• suite à la clôture de la transaction de paiement, présenter une requête d'acquisition de donnée sur un écran du terminal de paiement ; • acquérir la donnée par le terminal de paiement ;

• valider dans le terminal la donnée acquise ;

• si la donnée est valide, transmettre la donnée par le terminal de paiement vers un serveur de consolidation et présenter à l'utilisateur un message de fin de validation sur l'écran du terminal. La donnée est considérée comme invalide lorsque, l'acquisition comportant un paramètre de durée maximale, la donnée est acquise au- delà de cette durée maximale.

Ce procédé permet ainsi avantageusement de recueillir une opinion fiable des clients en ce qu'elle est acquise de façon systématique et rapide et sans que le commerçant puisse intervenir facilement pour modifier le vote.

Des caractéristiques ou des modes de réalisation particuliers sont :

• il comporte en outre, si la donnée est invalide : o transmettre une information d'échec par le terminal de paiement vers le serveur de consolidation et o présenter à l'utilisateur un message de fin de validation sur l'écran du terminal.

• si la transaction de paiement est une transaction de paiement par carte à puce, 'il comporte une étape de validation à partir de la présence de la carte. • la requête d'acquisition et sa présentation sur l'écran du terminal de paiement sont personnalisées par le serveur de consolidation puis transmises par le serveur de consolidation au terminal de paiement. • la transmission de la donnée du terminal vers le serveur de consolidation est réputée terminée par le terminal dès réception d'un message de réponse envoyé par le serveur de consolidation, ledit message étant envoyé par le serveur avant la validation par le serveur de la donnée.

• si la donnée n'est pas validée par le serveur de consolidation, la donnée n'est pas consolidée par le serveur de consolidation et le résultat statistique global n'est pas affecté par la donnée non validée par non consolidation de l'ensemble de la requête d'acquisition.

• la requête d'acquisition appartenant à un ensemble de requêtes définissant une campagne d'enquête, campagne réalisée via un ou plusieurs terminaux de paiement sur lesquels sont réalisées une pluralité de transactions de paiement, la personnalisation est réalisée par le serveur de consolidation pour répartir les requêtes de l'ensemble des requêtes de la campagne en cours sur la pluralité des transactions de paiement de telle sorte que la consolidation des données recueillies par le ou les terminaux de paiement permette d'utiliser la loi statistique des grands nombres pour obtenir des résultats statistiquement significatifs.

• la personnalisation tient compte de paramètres non-identifiants associés à l'utilisateur en provenance du serveur de consolidation ou de la carte de l'utilisateur. • la requête d'acquisition est adaptée pour recueillir une pluralité de données consécutivement.

• la personnalisation définit un ordre variable de recueil de la pluralité de données, ordre variable dépendant de paramètres associés à l'utilisateur ou à l'environnement. • le terminal de paiement comportant un interpréteur d'une suite d'instructions pour afficher la requête d'acquisition ou une pluralité de requêtes d'acquisitions sur le terminal et recueillir la donnée ou la pluralité de données, ledit interpréteur bloque les instructions de saut en arrière et limite la durée d'exécution de telle sorte qu'aucune suite d'instructions ne peut conduire à une exécution non finie dans le temps.

• le code PIN d'une carte comportant N chiffres, l'interpréteur interdit la saisie de plus de N-P données, avec P supérieur ou égal à 1 , de manière à empêcher qu'une suite d'instructions chargée de manière malveillante dans le terminal puisse conduire l'utilisateur à entrer le code secret de la carte bancaire. • le serveur de consolidation associe la donnée acquise avec une donnée non-identifiante et qualifiant l'utilisateur via l'heure d'acquisition de la donnée acquise.

Dans un second aspect de l'invention, un produit programme d'ordinateur comporte des instructions de code de programme enregistrées sur un support lisible par un calculateur d'appareil mobile de type terminal de paiement, pour mettre en œuvre les étapes d'un procédé précédent.

Dans un troisième aspect de l'invention, un système de recueil statistique d'informations comporte un serveur de consolidation. Le serveur de consolidation est connecté à un ou plusieurs terminaux de paiement effectuant une pluralité de transactions de paiement, et comporte :

• un stockage d'une liste de questions à poser à des utilisateurs ;

• un calculateur d'un plan d'interrogation pour la pluralité de terminaux de paiement, le dit plan définissant pour chaque transaction de paiement un sous-ensemble de la liste de questions;

• des interfaces de communication avec chaque terminal de paiement pour transmettre à chaque terminal les sous- ensembles de questions sous forme de requêtes d'acquisition et pour recueillir des données correspondant aux questions assignées à ce terminal, le ou les terminaux étant adaptés pour mettre en œuvre le procédé d'acquisition décrit ci-dessus ;

• un stockage de la liste des réponses retournées par les utilisateurs ; • un calculateur statistique pour la consolidation des données acquises par utilisation de la loi des grands nombres. L'invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d'exemple, et en référence aux figures en annexe dans lesquelles :

- la figure 1 est une vue schématique d'un système d'acquisition selon un mode de réalisation de l'invention ;

- les figures 2 et 3 sont un ordinogramme d'un procédé d'acquisition selon un mode de réalisation de l'invention ; - la figure 4 est un ordinogramme d'une variante du procédé de la figure 2 ;

- la figure 5 est un ordinogramme d'un procédé de consolidation selon un mode de réalisation de l'invention ;

- la figure 6 est une illustration partielle du fonctionnement d'instructions d'une machine virtuelle sur un terminal de paiement selon un mode de réalisation de l'invention; et

- la figure 7 est une vue schématique de certains aspects d'un protocole de communication selon un mode de réalisation de l'invention. En référence à la figure 1 , un terminal de paiement 1 comporte un support de connexion 3 d'une carte à puce 5, un écran 7 et un clavier 9 ainsi que des moyens 11 de communication à un réseau de données 13. Tous ces éléments peuvent être liés dans un terminal monobloc, ou peuvent être séparés ou dupliqués ; il peut par exemple y avoir plusieurs claviers et plusieurs écrans. Par l'intermédiaire de ce réseau de données, le terminal de paiement 1 est connecté à un serveur de paiement 15, à un serveur de consolidation 17 et à un serveur de maintenance à distance 19.

La carte à puce 5, le terminal de paiement 1 et le serveur de paiement 15 sont de préférence conformes à la dernière norme en vigueur, par exemple norme EMV (Eurocard/Mastercard/Visa) 4.2 disponible pour téléchargement sur le site _. http_://ww^

Le serveur de paiement est, par exemple, un serveur sécurisé géré par un organisme bancaire ou financier. Le serveur de maintenance et le serveur de consolidation sont des machines informatiques de type serveur. Le serveur de maintenance est, par exemple, géré par une société de service informatique en charge de la maintenance des terminaux. Le serveur de consolidation permet la préparation des campagnes de questions, le recueil et la consolidation statistique des réponses. Il est utilisé, par exemple, par une société de service marketing, spécialiste des campagnes d'analyse de satisfaction ou par un commerçant souhaitant connaître en permanence la satisfaction de sa clientèle sur le service rendu.

Les questions à poser suivant une ou plusieurs campagnes d'enquête sont définies et stockées dans l'étape 2 dans le serveur de consolidation 17, ce serveur dispose d'un calculateur qui définit dans l'étape 4, pour chaque terminal et chaque client, la question ou le sous ensemble de questions qui seront posées au client en fonction de paramètres comme la date, l'heure, le numéro d'ordre du client. Ce plan de questions est transmis à l'étape 8, à travers l'interface 6 au réseau 13, puis à l'étape 10 aux terminaux de paiement concernés.

Les terminaux remontent les réponses à l'étape 12 vers le réseau 13. A l'étape 14 ces réponses sont restituées au serveur de consolidation 17. Ce serveur dispose d'un calculateur statistique qui établit à l'étape 16 les résultats de l'ensemble des enquêtes en fonction des réponses reçues depuis les terminaux de paiement, et présente les résultats complets des enquêtes à l'étape 18.

Dans d'autres modes de réalisation les différents stockages et calculateurs peuvent par exemple ne pas être regroupés dans le même serveur de consolidation. La figure 2 est un ordinogramme d'un mode de réalisation d'un procédé d'acquisition utilisant les moyens décrits en relation avec la figure 1. Pour permettre une visualisation des différents flux, chaque moyen réalisant une étape est indiquée sur une ligne en haut de la figure, les étapes réalisées par un moyen donné se trouvant à la verticale de celui-ci, le système comprenant notamment les différents serveurs de la figure 1. Le procédé d'acquisition de donnée comporte :

• fin de la transaction, étape 20, de paiement suite à l'accord donné par la carte 5, étape 22. Cela correspond, par exemple, à l'étape « 10.1 1 Completion » de la norme EMV 4.2 ; cela se traduit souvent par un message « Paiement accepté » sur l'écran de visualisation du terminal ; dans d'autres cas, par exemple dans le cas d'une carte à piste, l'accord peut être donné par le système ; • début de l'opération d'acquisition, étape 24 ;

• présentation, étape 26, d'une requête d'acquisition de donnée personnalisée sur l'écran 7 du terminal de paiement ;

• acquisition, étape 28, de la donnée sur le clavier 9 du terminal de paiement ; • validation, étape 30, dans le terminal la donnée acquise ;

• si la donnée est valide,

1. enregistrement, étape 32, de la donnée ;

2. transmission, étape 34, de la donnée par le terminal de paiement vers le serveur de consolidation 17 et 3. présentation, étape 36, à l'utilisateur d'un message de fin de validation, celui-ci pouvant être l'autorisation d'enlèvement de la carte sur l'écran 7 du terminal dans le cas d'une carte à puce ;

• si la donnée n'est pas validée,

4. enregistrement, étape 38, de l'échec ; 5. transmission, étape 40, de l'échec par le terminal de paiement vers le serveur de consolidation 17 et

6. présentation, étape 42, à l'utilisateur un message d'autorisation d'enlèvement de la carte sur l'écran 7 du terminal dans le cas d'une carte à puce ; L'étape d'acquisition 28 comporte une durée maximale pour la saisie de la donnée. Au-delà de cette durée, la donnée est considérée comme invalide et le terminal pourra terminer la session. Ceci est particulièrement avantageux dans le contexte d'un paiement. En effet, à cet instant, aussi bien le client que le commerçant souhaitent que l'ensemble de la transaction se déroule rapidement. Or, ne pas donner de durée maximale à la saisie pourrait bloquer le terminal en mode d'attente de saisie. De plus, cela peut laisser aussi une opportunité de donner une fausse réponse en permettant par exemple au commerçant de récupérer le terminal et de répondre lui-même à la question. Pour éviter cela, une durée maximale de quelques secondes, par exemple entre 5 et 10 secondes est un bon compromis pour permettre le temps de lecture et d'assimilation de la question puis la saisie de la réponse de façon quasi-spontanée. De même, la durée de saisie peut être limitée par la présence obligatoire de la carte dans le terminal de paiement. En effet, tant que la carte est présente dans le terminal, il est raisonnable de faire l'hypothèse que le client est toujours en possession ou près du terminal. Ainsi, dans le schéma classique de paiement par carte à puce où les messages « Paiement accepté » et « Retirer la carte » s'enchainent, l'ensemble des étapes d'acquisition est avantageusement réalisé entre ces deux messages.

Le procédé décrit peut avantageusement être mis en œuvre sous la forme d'un produit programme d'ordinateur, par exemple un script, formé d'instructions. Ce produit programme d'ordinateur est alors installé dans les moyens de commande du terminal de paiement pour contrôler les différents moyens du terminal de paiement dans l'exécution du procédé décrit.

Le serveur de consolidation comporte également un produit programme d'ordinateur pour d'une part préparer et envoyer les questions aux terminaux de paiement, d'autre part recueillir les informations envoyées par les terminaux, les transmettre ou en faire la synthèse. Cette synthèse peut ensuite être présentée aux consommateurs sous forme d'un site web de notation et de comparaison des commerçants.

La requête d'acquisition de donnée peut prendre la forme d'une question personnalisée. La personnalisation se fait par l'intermédiaire du serveur de consolidation en fonction des demandes reçues par ce serveur. La question elle-même peut ainsi varier en fonction du temps, du lieu, du commerce lui-même, ou d'autres paramètres. Les autres messages qui apparaissent sur l'écran ainsi que l'affichage peuvent également être personnalisés et sont une personnalisation de la requête d'acquisition. Dans les cas où le terminal est connecté en temps réel au serveur de consolidation, la requête d'acquisition peut avantageusement prendre en compte les achats réalisés par le client, et connus du serveur de consolidation, pour personnaliser la question à poser. La validation de la donnée permet de s'assurer avec un degré de confiance suffisant que la donnée a bien été entrée par le client, afin de disposer de données suffisamment fiables.

Le terminal possédant généralement un écran de petite taille d'une part et le client étant généralement pressé de terminer la transaction, le nombre de questions et la complexité de celles-ci doivent être réduits au minimum. On peut ainsi considérer qu'il est ergonomiquement avantageux de ne pas dépasser trois questions simples auxquelles il suffit de répondre au moyen d'une seule touche du clavier. Cette limitation pourrait impliquer que les campagnes d'enquête utilisant ce procédé de recueil d'information soient beaucoup moins riches d'enseignement que les campagnes d'enquête « classiques » faites par questionnaire téléphonique, internet, etc., campagnes comportant souvent une vingtaine de questions avec des sélections multiples, des arbres de parcours de questionnaire en fonction de la réponse à certaines questions, etc.

Cette limitation pourrait également empêcher de mener plusieurs campagnes d'enquête dans le même temps demandées par des personnes ou des sociétés différentes. Pour supprimer cette limitation et obtenir des résultats ayant statistiquement les mêmes qualités que les campagnes « classiques », il est proposé d'utiliser la loi statistique des grands nombres permettant ainsi d'obtenir des résultats statistiquement valables pour connaître l'évolution de l'avis des utilisateurs, ou comparer l'avis de ces utilisateurs, par exemple sur les services rendus par des commerces différents mais à l'activité comparable, ou l'avis des utilisateurs sur le service rendu à des périodes de temps différentes, par exemple le matin et l'après-midi, ou durant la semaine et durant le week-end.

Ces avis sont recueillis en utilisant le procédé décrit ci-dessus dans les différents contextes que l'on veut comparer.

Le caractère systématique de ce recueil d'opinion permet d'obtenir un grand nombre de réponses pour la même question. Or, les lois de la statistique (loi des grands nombres) assurent qu'il est suffisant d'obtenir l'avis d'un échantillon représentatif des utilisateurs concernés pour obtenir un résultat statistiquement valide, c'est-à-dire quasi-certainement proche du résultat moyen qui serait obtenu en interrogeant tous les utilisateurs concernés. Ainsi interroger un grand nombre de clients, chacun sur un nombre limité de l'ensemble des questions à poser pour la ou les campagnes d'enquête en cours, permet, d'après la loi des grands nombres, de disposer d'une mesure représentative de l'avis de tous les clients sur l'ensemble des questions de la campagne ou de toutes les campagnes en cours. Le serveur de consolidation permet de regrouper toutes les campagnes comme si toutes les questions étaient issues d'une même campagne, et de ne poser à chaque client qu'un petit nombre de questions.

Cependant, afin que ces résultats soient utilisables effectivement, il importe de s'assurer que :

• le nombre de réponses à chaque question est suffisamment important pour être statistiquement valide ou que le nombre de réponses est indiqué pour informer la personne qui utilise ces données ;

• les résultats par période de temps considéré et par terminal soient effectivement comparables et puissent être combinés de manière statistiquement correcte. A titre d'exemple, considérons un magasin avec 2 terminaux différents :

• un terminal T1 pose 30 fois une question à ses clients pendant une journée, obtient une note moyenne de 5 à cette question, et par ailleurs pose d'autres questions à 470 clients dans cette même journée. Alors les 30 notes de moyenne 5 sont représentatives de 500 utilisateurs ; et

• un terminal T2 pose 30 fois la même question à ses clients pendant une journée, obtient une note moyenne de 3, et par ailleurs n'a aucun autre client ; La moyenne 5 obtenue par un échantillon de 30 questions sur le terminal T1 est alors représentative de l'avis de 500 clients ; la moyenne 3 obtenue par un échantillon de 30 questions sur le terminal T2 est alors représentative de l'avis de 30 clients. La moyenne représentative de l'avis des 530 clients ne peut pas être calculée en faisant la moyenne de 3 et de 5, même si les échantillons représentatifs sont de même taille. La dite moyenne doit être calculée en pondérant selon la population représentée par chaque moyenne séparée. Soit, en l'occurrence, (5 ^* 500 + 3 ^* 30)/530, soit environ 4,89. Afin de permettre la comparaison de résultats statistiquement valables, le procédé comporte :

• sur le serveur de consolidation, préalablement au lancement de l'enquête, permettre aux personnes demandant l'enquête de programmer les questions à poser et de définir les contextes pour lesquels ils veulent comparer l'avis des clients. Ces contextes peuvent être définis, par exemple, comme des commerces, comme des parties de commerces, comme des ensembles de commerces, comme des périodes de temps, ou des ensembles de périodes de temps, ou des combinaisons de ces critères.

• Par le serveur de consolidation, pendant le déroulement de l'enquête : o garder en mémoire un estimé initial, puis éventuellement un estimé historique, du nombre de paiements effectués sur chaque TPE et par période de temps. Cet estimé permet de déterminer le nombre minimum de TPEs ainsi que la durée minimale permettant d'obtenir ces échantillons statistiquement valides. Ces estimés sont fonctions de la fréquence à laquelle la question est posée au client : si la question est posée à un client sur dix, il faudra 2 fois plus de transactions de paiement pour obtenir, par exemple 50 réponses, que si la question est posée à un client sur 5. Ces estimés sont portés à la connaissance de la personne demandant l'enquête, lors de sa programmation, explicitement ou implicitement dans les choix qui lui sont offerts. o vérifier, lors de la consolidation des résultats, que des échantillons statistiquement valides ont bien été atteints, ou afficher le nombre de questions posées ou de réponses obtenues.

• Par chaque terminal de paiement, retourner au serveur de consolidation l'ensemble des résultats : o date et heure à laquelle une question a été posée ; o identifiant de la question posée ; o vote, ou bien information indiquant que le client n'a pas voté ; o date et heure de chaque transaction de paiement, même si aucune question n'est posée ;

• par le serveur de consolidation, appliquer les règles de calcul dérivant de la science statistique à ces informations afin de présenter aux personnes consultant les résultats des enquêtes des résultats statistiquement valides. En particulier, calculer les valeurs statistiques, tels moyennes, écart-type, en pondérant de manière valide les populations représentées par des échantillons suffisamment importants.

Cette utilisation de la loi des grands nombres permettant de poser peu de questions à beaucoup de clients n'est pas limitée aux campagnes utilisant les moyens de paiement comme décrit ci-dessus. En effet, cela peut être utilisé dans d'autres environnements dans lesquels il est souhaitable, pour obtenir un bon taux de retour, que la réponse à un questionnaire soit très rapide. Par exemple, il est possible d'utiliser cette technique statistique à des campagnes de sondage utilisant internet ou le courriel comme support. Dans une variante, le procédé permet de recueillir l'avis du client sur une séquence de questions, plutôt que sur une seule question, dans le même contexte du terminal de paiement. De fait, certains contextes d'utilisation des terminaux de paiement permettent de demander l'avis de l'utilisateur non seulement sur une question, mais sur une telle séquence de questions. Ces contextes comprennent les cas où le contexte permet, suscite ou requiert une interaction prolongée avec le client.

La personne qui commande une telle enquête cherche en général à poser des questions différentes au client, non seulement en fonction de critères externes tels la date, l'heure, la langue, mais également en fonction de ses réponses à des questions précédentes.

Certaines de ces données peuvent être obtenues à partir des données présentes dans la carte de paiement de l'utilisateur. Par exemple, la langue dans laquelle une question est présentée est généralement la langue usuelle du pays où le terminal est opéré. Cependant, il est souvent possible de déduire la langue préférée de l'utilisateur à partir des données stockées dans la carte. Il est alors possible d'exprimer la question dans la langue préférée de l'utilisateur, ou dans une langue plus communément comprise que la langue usuelle du pays. Cela est particulièrement intéressant pour les commerçants accueillant une clientèle étrangère.

De manière générale, il est possible de demander à l'application de paiement la communication d'informations déduites de données de la carte, informations ne permettant pas d'identifier l'utilisateur pour ne pas compromettre la confidentialité et la sécurité, mais permettant d'ajuster la question posée à l'utilisateur. Ces données que nous appellerons « non- identifiantes » comprennent : la langue (pour ajuster la langue dans laquelle est exprimée la question), le sexe (pour les accords grammaticaux), etc.

Afin de permettre la prise en compte de telles séquences dynamiques de questions, le procédé comporte :

• par le serveur de consolidation, permettre à la personne demandant l'enquête d'exprimer ces séquences dynamiques ;

• par le serveur de consolidation, exprimer ces séquences dans une représentation informatique (c'est-à-dire opérations caractérisées par une balise) permettant à l'interprète résidant sur le terminal d'exécuter correctement ces séquences.

• Par l'application de paiement, communiquer certaines informations ne permettant pas d'identifier l'utilisateur, à l'interprète présentant les questions, afin de lui permettre d'ajuster l'expression de la question.

• Par l'interprète résidant sur le terminal, exécuter chaque opération l'une après l'autre, accéder aux informations externes comme internes pour, à titre illustratif, sélectionner les questions suivantes, recueillir le vote de l'utilisateur et en stocker le résultat. En particulier, évaluer des critères comprenant la date, l'heure, la langue parlée par l'acheteur, ou les réponses données aux questions précédentes.

La Figure 4 est un ordinogramme d'un mode de réalisation du procédé d'acquisition ci-dessus utilisant les moyens décrits en relation avec la figure 1. C'est donc une variante du procédé décrit en relation avec la Figure

2 permettant à la personne qui commande l'enquête de spécifier des listes de questions à poser lors d'une transaction de vote, et la prise en compte de paramètre internes (durée de la transaction, valeurs précédentes, ...) ou externes (date, heure, langue parlée par le porteur, rang du client). Comme dans la Figure 2, chaque moyen réalisant une étape est indiqué sur une ligne en haut de la figure, les étapes réalisées par un moyen donné se trouvant à la verticale de celui-ci.

Les étapes 24, 26, 28, 30, 36, et A sont identiques à celles de la Figure 2. L'étape 20 est remplacée par l'étape 21. L'étape 32 est remplacée par les étapes 31 , 33 et 35. L'étape 34 est renumérotée en étape 37.

Par rapport à la Figure 2, les étapes suivantes ont été ajoutées :

• Fin de transaction et transfert d'informations anonymes sur le porteur, étape 21 ; • Sélection de la question à poser, étape 25, selon la programmation voulue par la personne demandant l'enquête, et, selon cette programmation, la prise en compte de paramètre externes (date, heure, rang du client, langue parlé par le client), et, s'il ne s'agit pas de la première question, la prise en compte de paramètres internes (tels que l'historique de la liste de questions, la durée passée à répondre à cette liste, les votes précédents dans la liste de questions) ;

• Enregistrement du vote, étape 31 ;

• Détermination, étape 33, selon la programmation voulue par la personne demandant l'enquête, de l'existence d'une autre question à poser ;

• Fin de la transaction, étape 35 ; et

Remontée des votes, étape 37, vers le serveur de consolidation. Quand les réponses sont horodatées, cela permet également de rapprocher les réponses d'autres informations, anonymes comme les achats réalisés, ou non anonymes comme les coordonnées de l'acheteur.

Il peut être particulièrement avantageux pour un commerce d'effectuer ce rapprochement pour approfondir leurs études statistiques. Cette méthode permet notamment d'effectuer des études d'une grande précision tout en conservant l'anonymat de l'acheteur.

La figure 5 est un ordinogramme d'un mode de réalisation d'un procédé de rapprochement de données qui peuvent rester anonymes et permettre d'approfondir les enquêtes réalisés. Pour permettre une visualisation des différents flux, chaque moyen réalisant une étape est indiquée sur une ligne en haut de la figure, les étapes réalisées par un moyen donné se trouvant à la verticale de celui-ci, le système comprenant notamment les différents serveurs de la figure 1. Le procédé de rapprochement des données comporte :

• Extraction, étape 46, des données de vote horodatées issues de la remontée des votes après l'étape 34 suivant la figure 2 ou l'étape 37 suivant la figure 4 ;

• Tri des données de vote par date et heure croissantes, étape 48;

• Extraction des données qui doivent être rapprochées des résultats de votes, comme les listes des achats réalisés, étape 50 ;

• Tri des données à rapprocher par date croissante, étape 52 ; • Vérification de la concordance des heures, et ajustement des heures si nécessaire selon les différences de réglage des horloges des différents calculateurs, étape 54 ; et

• Appairage des données ayant le même horodatage après ajustement, étape 56. II est à noter également que l'installation du produit programme d'ordinateur dans le terminal de paiement nécessite que des serveurs, classiquement les serveurs de maintenance des terminaux, soient adaptés pour qu'ils procèdent à l'installation du programme correspondant sur le terminal de paiement. Ces opérations peuvent se faire dans certains cas lors des opérations de télémaintenance et de mise à niveau des logiciels du terminal de paiement.

Les procédés techniques informatiques propres à assurer la communication entre le serveur de consolidation et les terminaux pour permettre le fonctionnement pour procédé décrit ci-dessus sur le terminal doivent prendre en compte les paramètres suivants ;

• Les terminaux sont dispersés géographiquement.

• Les terminaux sont de type très divers ; • Leur capacité de calcul et de mémoire est limitée ;

• Leur mode de connexion à des réseaux est parfois lente et épisodique, comme dans des lieux reculés par exemple ;

• Les terminaux doivent rester disponibles étant donné le caractère essentiel du paiement pour un commerce ; • La sécurité des données et des programmes servant à la transaction de paiement ne doit pas être compromise ;

• Le nombre de terminaux à desservir par un serveur de consolidation est plus important que le nombre de terminaux desservis par un système monétique, étant donné que l'application de vote peut être installée sur l'ensemble des terminaux, quel que soit le système monétique associés

• La sécurité des données personnelles du porteur de carte doit être préservée : en particulier toute possibilité de « phishing » ou « hameçonnage », consistant à obtenir par ruse les données confidentielles de l'utilisateur (PIN), doit être interdite.

Dans ces conditions, les procédés connus peuvent être renforcés sur les points suivants.

L'état de l'art pour la réalisation de la partie de logiciel résidant sur le terminal et en charge de l'exécution de la séquence de questions (étapes 33 et 25 sur l'ordinogramme de la figure 4) consiste en la réalisation d'un interprète d'un langage de script, ou bien d'une machine virtuelle exécutant une séquence d'instructions obtenues par pré compilation. Ces deux approches, dans leur généralité, ne garantissent ni la terminaison de l'exécution, ni l'absence de « hameçonnage ». De fait, si un terminal incorpore un interprète général de scripts, ou une machine virtuelle interprétant un langage de programmation général, il est possible :

• De transmettre un script à un terminal et que l'exécution dudit script ne termine jamais. Cela aura un effet négatif sur la disponibilité du terminal de paiement.

• De transmettre un script à un terminal et que l'exécution dudit script demande le code PIN de l'utilisateur, le recueille et le transmette en retour au propriétaire du script à l'insu du titulaire de la carte.

Par ailleurs, les protocoles connus pour collecter les données des terminaux ont des caractéristiques de sécurité (pour éviter de compromettre des informations sensibles), de fiabilité (pour éviter de perdre des données de transaction), qui entraînent une certaine complexité dans les échanges. En particulier, plusieurs échanges de messages, en sus des échanges de connexion et de libération de connexion, sont nécessaires pour assurer ces caractéristiques. Cette sécurité, fiabilité et complexité ne sont pas compatibles ou nécessaires compte tenu des besoins suivants :

• Le nombre de terminaux à desservir par un serveur de consolidation pour le vote est éventuellement plus important que le nombre de terminaux desservis par un système monétique, étant donné que l'application de vote peut être installée sur l'ensemble des terminaux, quel que soit le système monétique associé ; • Le caractère statistique et purement informationnel des votes ne nécessite pas une fiabilité totale de la transmission ; et

• Le caractère anonyme des votes ne nécessite pas à une sécurisation de données personnelles.

Afin d'assurer que l'exécution se termine systématiquement, le terminal de paiement comporte avantageusement :

• Une machine virtuelle capable d'interpréter une séquence d'instructions, chaque instruction étant caractérisée, par exemple, par une balise et contenant, par exemple, un test et une opération : o Le test est limité à des tests simples, par exemple, la vérification de valeurs booléennes ou à la comparaison de deux valeurs ; ces valeurs peuvent être des constantes, ou prises au sein d'une liste limitée de données externes telles l'heure, la date, la langue ; si le test échoue, l'opération n'est pas exécutée, l'opération suivante est considérée ; o Les opérations sont limitées à : o Une opération d'affichage de l'écran spécifié dans l'instruction et de collecte de la donnée,; o Une opération de saut, permettant de sauter un nombre positif d'instructions. Ce nombre ne peut être que positif, interdisant de revenir en arrière dans la séquence ; o Diverses opérations de manipulation de valeurs : incrément, changement de valeur de booléen, copie.

• Un module séparé de la machine virtuelle, et invoqué par l'instruction d'affichage et de collecte de cette machine virtuelle exécute l'opération d'affichage d'écran et de collecte d'une seule donnée instructions. La capacité du serveur de consolidation de paramétrer l'exécution de ce module est contrainte de part sa séparation avec la machine virtuelle : o Le module ne peut collecter qu'une donnée o cette donnée ne comporte qu'un seul chiffre ou caractère ;

Ces séquences d'instructions sont générées par le serveur de consolidation à partir des programmations de questions et de séquences de questions exprimées par les personnes demandant des campagnes. Il est facile de se convaincre que :

• II est impossible de générer une séquence finie d'instructions dont l'exécution ne terminera pas ; • II est impossible de collecter le code confidentiel d'un utilisateur au travers d'une seule exécution du module d'affichage et de collecte de la donnée ;

• La limitation du nombre d'exécutions du module d'affichage d'écran et de collecte de vote, pour que ce nombre soit strictement inférieur au nombre de chiffres ou de caractères dans les codes secrets (souvent 4), permet d'interdire la collecte du code confidentiel de la carte.

Ainsi, même si les échanges entre le terminal et le serveur d'échange étaient compromis par une attaque malveillante, il serait impossible à l'attaquant de faire exécuter au terminal une question ou une liste de questions induisant l'utilisateur à entrer le code confidentiel de sa carte.

Une variante de cette approche consiste à ne permettre l'exécution de séquences dynamiques de questions pour recueillir une pluralité de données, qu'après le retrait de la carte, de manière à clairement signifier à l'utilisateur que le contexte n'est plus un contexte de paiement et d'utilisation de la carte.

A titre d'illustration, La figure 6 illustre quelques étapes sélectionnées d'une séquence d'instruction. A la première étape 61 , le test, s'il réussit, conduit l'interprète à considérer directement la troisième étape, ignorant l'étape 62. Si le test de l'étape 61 échoue, alors l'opération de l'étape 62 est exécutée. Cette opération inclut un appel au module séparé permettant l'affichage d'écran et le capture de la donnée. L'affichage de l'écran et le capture du vote ne sont pas permis directement à partir de l'interprète, permettant de ne pas accepter des séquences d'instructions réalisant des affichages et des captures non contrôlés. Un saut d'instructions, tel celui éventuellement réalisé de l'étape 61 à l'étape 63, n'est permis qu' «en avant » garantissant ainsi la terminaison de toute séquence finie d'instructions.

Afin d'assurer la distribution des programmations de terminaux et la collecte des votes tout en tenant compte du nombre très important de terminaux et du caractère anonyme, statistique et purement informationnel des résultats, le protocole de transmission de données comporte les caractéristiques suivantes :

• Un échange standard entre un terminal et le serveur de consolidation se limitant aux échanges suivants (figure 7a) : o Une demande d'établissement de connexion par le terminal et une acceptation .par le serveur de consolidation. Cet échange se limite à établir les paramètres d'échange. o Un message de demande par le terminal, message qui inclut la transmission des résultats de vote au serveur. o Un message de réponse par le serveur, message qui inclut une nouvelle programmation du terminal, si nécessaire. o Une demande de libération de la connexion par le terminal, suivi par une acceptation par le serveur. • En cas d'échec lors d'un appel, le terminal se contente de répéter sa tentative, par exemple à intervalles réguliers comme indiqué par le paramètre « DuréeEntreEssais » sur la figure 7c, soit jusqu'à ce que l'appel réussisse soit jusqu'à un nombre prédéfini d'appels (paramètre « NombreD'Essais » sur la figure 7c).

• Les échanges standards sont répétés, par exemple à intervalles réguliers déterminés par un nombre de jours entre deux échanges standards (« DuréeEntreAppels » sur la figure 7b) et l'heure prévue pour un tel échange (« HeureD'Appel » sur la figure 7b).

• Le grand nombre de terminaux exige que le serveur consacre un temps minimal au traitement de chaque requête. Il ne lui est donc pas possible de valider totalement la correction des données à la réception d'un message de demande, avant d'émettre le message de retour. Or le terminal est invité à effacer de sa mémoire les données transmises dès réception d'un message de réponse normal. Il est donc possible que des données soient perdues.

• Le serveur de consolidation continue de garantir la validité statistique des résultats, en compensant la perte éventuelle de résultats de la manière suivante : o Les votes ne sont pas pris en compte dans le calcul des moyennes, écart type, ou autres valeurs statistiques ; o Les transactions de vote ne sont pas comptées dans le nombre de transactions servant à calculer les moyennes, écart type, ou autre valeurs statistiques.

Le protocole décrit ci-dessus optimise donc la durée de traitement de chaque requête afin d'accroître le nombre de terminaux desservis de manière efficiente par le serveur de consolidation. Cette optimisation est réalisée au risque d'une perte de données. Cependant, cette perte de données n'entraîne pas l'invalidation statistique des résultats qui prennent en compte la totalité des données. L'invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d'exemple et non comme limitant l'invention a cette seule description. De nombreuses variantes de réalisation sont possibles.

Par exemple, le serveur de paiement, le serveur de consolidation et le serveur de maintenance du terminal peuvent être regroupés dans deux voire une même machine, à l'inverse les différentes fonctions du terminal de paiement, traitement de données, affichage, clavier, interface, peuvent être dissociés dans des appareils distincts, de même que les différentes fonctions du serveur de consolidation. De nombreuses autres variantes de réalisation sont possibles.

Dans les revendications, le mot « comprenant » n'exclut pas d'autres éléments et l'article indéfini « un/une » n'exclut pas une pluralité.