EP2438564A1 - Procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement. - Google Patents

Procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement.

Info

Publication number
EP2438564A1
EP2438564A1 EP10737956A EP10737956A EP2438564A1 EP 2438564 A1 EP2438564 A1 EP 2438564A1 EP 10737956 A EP10737956 A EP 10737956A EP 10737956 A EP10737956 A EP 10737956A EP 2438564 A1 EP2438564 A1 EP 2438564A1
Authority
EP
European Patent Office
Prior art keywords
data
terminal
payment
server
consolidation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP10737956A
Other languages
German (de)
English (en)
Inventor
Bernard David Levy
Laurent Bernard Marie Vieille
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jade-I
JADE I
Original Assignee
Jade-I
JADE I
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jade-I, JADE I filed Critical Jade-I
Publication of EP2438564A1 publication Critical patent/EP2438564A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0203—Market surveys; Market polls

Definitions

  • the present invention relates to a method of acquiring data from a user during a card payment with a payment terminal and a computer program product for implementing the method.
  • the latter can send an e-mail to the merchant. buyer some time after purchase to encourage him to complete an online questionnaire on his satisfaction with the purchase.
  • Another way is to encourage buyers to leave ratings on specialized sites, assessments that will be freely available to other users of the site. For example, there are sites that list the restaurants in a city or region and that offer in addition to a fact sheet restaurants and, possibly comments by site managers, a forum area where consumers can leave comments related to the restaurant (s) listed.
  • This type of comment may be accompanied by a sort of consolidated classification composed of the average of a rating given by the different users.
  • a method of acquiring data from a user during a payment by card with a payment terminal comprises:
  • This method advantageously allows to collect a reliable opinion of customers in that it is acquired in a systematic and fast and without the merchant can easily intervene to change the vote.
  • the payment transaction is a smart card payment transaction, it includes a validation step based on the presence of the card.
  • the acquisition request and its presentation on the screen of the payment terminal are personalized by the consolidation server and then transmitted by the consolidation server to the payment terminal.
  • the transmission of the data from the terminal to the consolidation server is deemed completed by the terminal upon receipt of a response message sent by the consolidation server, said message being sent by the server before validation by the server of the data. .
  • the customization takes into account non-identifying parameters associated with the user from the consolidation server or the user's card.
  • the acquisition request is adapted to collect a plurality of data consecutively.
  • the payment terminal comprising an interpreter of a sequence of instructions for displaying the acquisition request or a plurality of acquisition requests on the terminal and collecting the data or the plurality of data, said interpreter blocks the Jump back instructions and limit the execution time so that no sequence of instructions can lead to an unfinished execution over time.
  • the interpreter forbids the entry of more NP data, with P greater than or equal to 1, so as to prevent a sequence of instructions maliciously loaded into the terminal may lead the user to enter the secret code of the bank card.
  • the consolidation server associates the acquired data with non-identifying data and qualifying the user via the acquisition time of the acquired data.
  • a computer program product includes program code instructions recorded on a medium readable by a payment terminal type mobile device calculator for implementing the steps of a method. previous.
  • a statistical information collection system comprises a consolidation server.
  • the consolidation server is connected to one or more payment terminals performing a plurality of payment transactions, and comprises:
  • a calculator of an interrogation plan for the plurality of payment terminals the said plan defining for each payment transaction a subset of the list of questions;
  • Communication interfaces with each payment terminal for transmitting to each terminal the subsets of questions in the form of acquisition requests and for collecting data corresponding to the questions assigned to this terminal, the terminal or terminals being adapted to implement implement the acquisition method described above;
  • FIG. 1 is a schematic view of an acquisition system according to one embodiment of the invention.
  • FIGS. 2 and 3 are a flow diagram of an acquisition method according to one embodiment of the invention.
  • FIG. 4 is a flow diagram of a variant of the method of FIG. 2;
  • FIG. 5 is a flow diagram of a consolidation method according to one embodiment of the invention.
  • FIG. 6 is a partial illustration of the operation of instructions of a virtual machine on a payment terminal according to one embodiment of the invention.
  • FIG. 7 is a schematic view of certain aspects of a communication protocol according to one embodiment of the invention.
  • a payment terminal 1 comprises a connection support 3 of a smart card 5, a screen 7 and a keyboard 9 as well as means 11 of communication to a data network 13. All these elements can be linked in a one-piece terminal, or can be separated or duplicated; for example there may be several keyboards and several screens.
  • the payment terminal 1 is connected to a payment server 15, to a consolidation server 17 and to a remote maintenance server 19.
  • the smart card 5, the payment terminal 1 and the payment server 15 are preferably in accordance with the latest standard in force, for example standard EMV (Eurocard / Mastercard / Visa) 4.2 available for download on the site .
  • the payment server is, for example, a secure server managed by a banking or financial institution.
  • the maintenance server and the consolidation server are server-type computer machines.
  • a maintenance server is managed by an IT service company in charge of terminal maintenance.
  • the consolidation server allows the preparation of the question campaigns, the collection and the statistical consolidation of the answers. It is used, for example, by a marketing service company, a specialist in satisfaction analysis campaigns or by a merchant wishing to constantly know the satisfaction of his customers on the service rendered.
  • step 2 The questions to be asked following one or more survey campaigns are defined and stored in step 2 in the consolidation server 17, this server has a calculator which defines in step 4, for each terminal and each client, the question or subset of questions that will be asked to the customer based on parameters such as date, time, client's order number.
  • This question plan is transmitted to step 8, through the interface 6 to the network 13, then to step 10 to the payment terminals concerned.
  • the terminals return the responses in step 12 to the network 13. In step 14 these responses are returned to the consolidation server 17.
  • This server has a statistical calculator which establishes in step 16 the results of the all surveys based on responses received from payment terminals, and presents the full results of the investigations at Step 18.
  • FIG. 2 is a flow chart of an embodiment of an acquisition method using the means described with reference to FIG. 1.
  • each means performing a step is indicated on a line at the top. of the figure, the steps performed by a given means being located vertically thereto, the system comprising in particular the different servers of FIG. 1.
  • the data acquisition method comprises:
  • step 20 of payment following the agreement given by the card 5, step 22.
  • This corresponds, for example, to the step "10.1 1 Completion" of the EMV 4.2 standard; this is often translated by a "Payment accepted” message on the display screen of the terminal; in other cases, for example in the case of a track map, the agreement can be given by the system; • start of the acquisition transaction, step 24;
  • step 26 of a request for the acquisition of personalized data on the screen 7 of the payment terminal
  • step 32 the data
  • step 34 of the data by the payment terminal to the consolidation server 17 and 3. presentation, step 36, to the user of an end-of-validation message, which may be the authorization removal of the card on the screen 7 of the terminal in the case of a smart card;
  • step 38 4. recording, step 38, of the failure; 5. transmission, step 40, of the failure by the payment terminal to the consolidation server 17 and
  • step 42 to the user an authorization message to remove the card on the screen 7 of the terminal in the case of a smart card;
  • the acquisition step 28 includes a maximum duration for entering the data. Beyond this duration, the data is considered invalid and the terminal will be able to end the session. This is particularly advantageous in the context of a payment. Indeed, at this moment, both the customer and the merchant want the whole transaction to proceed quickly. However, not giving maximum duration to the entry could block the terminal in input waiting mode. In addition, this can also leave an opportunity to give a false answer by allowing for example the trader to recover the terminal and respond himself to the the question.
  • a maximum duration of a few seconds, for example between 5 and 10 seconds is a good compromise to allow the reading time and assimilation of the question and then entering the response almost spontaneously.
  • the duration of entry can be limited by the mandatory presence of the card in the payment terminal. Indeed, as long as the card is present in the terminal, it is reasonable to make the assumption that the customer is still in possession or near the terminal.
  • all acquisition steps is advantageously carried out between these two messages.
  • the described method may advantageously be implemented in the form of a computer program product, for example a script, formed of instructions.
  • This computer program product is then installed in the control means of the payment terminal to control the various means of the payment terminal in the execution of the described method.
  • the consolidation server also comprises a computer program product for firstly preparing and sending the questions to the payment terminals, and secondly collecting the information sent by the terminals, transmitting them or summarizing them. This summary can then be presented to consumers in the form of a merchant rating and comparison website.
  • the data acquisition request may take the form of a custom question.
  • the customization is done through the consolidation server according to the requests received by this server.
  • the question itself can thus vary according to the time, the place, the trade itself, or other parameters.
  • Other messages that appear on the screen as well as the display can also be customized and are a customization of the acquisition request.
  • the acquisition request can advantageously take into account the purchases made by the client, and known to the consolidation server, to customize the question to ask.
  • the validation of the data makes it possible to ensure with a sufficient degree of confidence that the data has been entered by the client, in order to have sufficiently reliable data.
  • This limitation could also prevent several inquiries at the same time from different people or companies.
  • To eliminate this limitation and to obtain results having statistically the same qualities as the "classic" campaigns it is proposed to use the statistical law of large numbers thus making it possible to obtain statistically valid results to know the evolution of the opinion users, or compare the opinion of these users, for example on the services provided by different businesses but the comparable activity, or the opinion of users on the service rendered at different periods of time, for example in the morning and in the afternoon, or during the week and during the weekend.
  • a T1 terminal asks a question 30 times to its customers for a day, gets an average score of 5 for this question, and also asks 470 customers more questions in the same day. So the average 30 marks are representative of 500 users;
  • a T2 terminal asks customers 30 times the same question for one day, gets an average rating of 3, and otherwise has no other customer;
  • the average 5 obtained by a sample of 30 questions on the terminal T1 is then representative of the opinion of 500 clients;
  • the average 3 obtained by a sample of 30 questions on the terminal T2 is then representative of the opinion of 30 customers.
  • the average representative of the opinion of the 530 customers can not be calculated by averaging 3 and 5, even if the representative samples are of the same size.
  • the said average must be calculated by weighting according to the population represented by each separate average. In this case, (5 * 500 + 3 * 30) / 530, or about 4.89.
  • the method comprises:
  • the method makes it possible to collect the client's opinion on a sequence of questions, rather than on a single question, in the same context of the payment terminal.
  • certain contexts of use of the payment terminals make it possible to request the user's opinion not only on a question, but on such a sequence of questions. These contexts include cases where the context allows, elicits, or requires prolonged interaction with the client.
  • the person who orders such an inquiry usually seeks to ask different questions to the client, not only external criteria such as date, time, language, but also according to its answers to previous questions.
  • this data can be obtained from the data present in the payment card of the user.
  • the language in which a question is presented is usually the usual language of the country where the terminal is operated.
  • non-identifying data include: language (to adjust the language in which the question is expressed), sex (for grammar chords), etc.
  • the method comprises:
  • FIG. 4 is a flowchart of an embodiment of the above acquisition method using the means described with reference to FIG. 1. It is therefore a variant of the method described in connection with FIG.
  • each means performing a step is indicated on a line at the top of the figure, the steps performed by a given means being vertical to it.
  • Steps 24, 26, 28, 30, 36, and A are identical to those of FIG. 2.
  • Step 20 is replaced by step 21.
  • Step 32 is replaced by steps 31, 33 and 35.
  • Step 34 is renumbered in step 37.
  • step 21 • End of transaction and transfer of anonymous information on the bearer, step 21; • Selection of the question to be asked, step 25, according to the programming desired by the person requesting the survey, and, according to this programming, taking into account external parameters (date, time, client rank, language spoken by the client ), and, if it is not the first question, taking into account internal parameters (such as the history of the list of questions, the time spent answering this list, the previous votes in the list of questions);
  • step 33 according to the programming desired by the person requesting the investigation, of the existence of another question to ask;
  • Vote feedback to the consolidation server.
  • the answers are time stamped, it also allows to reconcile the answers of other information, anonymous as purchases made, or not anonymous as the buyer's details.
  • FIG. 5 is a flowchart of an embodiment of a data reconciliation method that can remain anonymous and allow for further investigation. To allow a visualization of the different flows, each means performing a step is indicated on a line at the top of the figure, the steps performed by a given means being vertical to it, the system comprising in particular the various servers of the Figure 1.
  • the data reconciliation process includes:
  • step 46 Extracting, step 46, the timestamped voting data from the feedback of votes after step 34 in Figure 2 or step 37 in Figure 4;
  • step 52 Sorting the data to be reconciled by increasing date, step 52; • Check the concordance of the hours, and adjustment of the hours if necessary according to the differences of setting of the clocks of the different computers, step 54; and
  • step 56 Pairing of data having the same timestamp after adjustment, step 56.
  • servers conventionally the terminal maintenance servers, are adapted to that they proceed to the installation of the corresponding program on the payment terminal. These operations can be done in some cases during remote maintenance and upgrade of the payment terminal software.
  • the technical computer processes suitable for ensuring the communication between the consolidation server and the terminals to enable operation for the method described above on the terminal must take into account the following parameters;
  • the terminals are geographically dispersed.
  • Terminals must remain available given the essential nature of the payment for a business; • The security of data and programs used for the payment transaction must not be compromised;
  • the number of terminals to be served by a consolidation server is greater than the number of terminals served by a payment system, since the voting application can be installed on all terminals, regardless of the electronic payment system.
  • the state of the art for carrying out the portion of software residing on the terminal and in charge of executing the sequence of questions consists of the realization of an interpreter of a scripting language, or of a virtual machine executing a sequence of instructions obtained by pre-compilation. These two approaches, in their generality, do not guarantee the termination of execution, nor the absence of "phishing". In fact, if a terminal incorporates a general script interpreter, or a virtual machine interpreting a general programming language, it is possible:
  • the number of terminals to be served by a consolidation server for voting may be greater than the number of terminals served by a payment system, since the voting application can be installed on all terminals, regardless of the associated electronic payment system; • The statistical and purely informational nature of the votes does not require a total reliability of the transmission; and
  • the payment terminal advantageously comprises:
  • a virtual machine capable of interpreting a sequence of instructions, each instruction being characterized by For example, by a tag and containing, for example, a test and an operation: o
  • the test is limited to simple tests, for example, the verification of Boolean values or the comparison of two values; these values can be constants, or taken from a limited list of external data such as time, date, language; if the test fails, the operation is not executed, the next operation is considered; o Operations are limited to: o A screen display operation specified in the instruction and data collection ,; o A jump operation, allowing you to skip a positive number of instructions. This number can only be positive, forbidding to go back in the sequence; o Various operations of manipulation of values: increment, change of value of boolean, copy.
  • a separate module of the virtual machine, and invoked by the display and collection instruction of this virtual machine performs the screen display operation and collection of a single data instructions.
  • the ability of the consolidation server to configure the execution of this module is constrained by its separation from the virtual machine: o
  • the module can only collect data where this data has only one number or character;
  • a variant of this approach is to allow the execution of dynamic sequences of questions to collect a plurality of data, only after the withdrawal of the card, so as to clearly indicate to the user that the context is no longer a context of payment and use of the card.
  • Figure 6 illustrates some selected steps of an instruction sequence.
  • the test if successful, leads the interpreter to directly consider the third step, ignoring step 62. If the test of step 61 fails, then the operation of step 62 is executed. This operation includes a separate module call for screen display and data capture. The display of the screen and the capture of the vote are not allowed directly from the interpreter, making it possible not to accept sequences of instructions realizing displays and uncontrolled captures.
  • An instruction hop such as that possibly performed from step 61 to step 63, is only allowed "forward" thus guaranteeing the termination of any finite sequence of instructions.
  • the data transmission protocol has the following characteristics:
  • a standard exchange between a terminal and the consolidation server is limited to the following exchanges ( Figure 7a): o A request for connection establishment by the terminal and acceptance by the consolidation server. This exchange is limited to establishing exchange parameters. o A request message by the terminal, message that includes the transmission of voting results to the server. o A response message by the server, message that includes a new programming of the terminal, if necessary. o A request to release the connection by the terminal, followed by an acceptance by the server. • In case of failure during a call, the terminal simply repeats its attempt, for example at regular intervals as indicated by the parameter "Duration Between Tests" in Figure 7c, or until the call succeeds. up to a predefined number of calls (parameter “Number of Tests" in Figure 7c).
  • the standard exchanges are repeated, for example at regular intervals determined by a number of days between two standard exchanges ("CallList" in FIG. 7b) and the scheduled time for such an exchange ("CallTime” in FIG. 7b). ).
  • the consolidation server continues to guarantee the statistical validity of the results, compensating for the possible loss of results as follows: o Votes are not taken into account in the calculation of means, standard deviation, or other statistical values; o Voting transactions are not counted in the number of transactions used to calculate averages, standard deviations, or other statistical values.
  • the protocol described above therefore optimizes the processing time of each request to increase the number of terminals served efficiently by the consolidation server. This optimization is done at the risk of data loss. However, this loss of data does not result in the statistical invalidation of the results that take into account all the data.
  • the invention has been illustrated and described in detail in the drawings and the foregoing description. This must be considered as illustrative and given by way of example and not as limiting the invention to this description alone. Many alternative embodiments are possible.
  • the payment server, the consolidation server and the terminal maintenance server can be grouped into two or even the same machine, unlike the different functions of the payment terminal, data processing, display, keyboard, interface , can be dissociated in separate devices, as well as the different functions of the consolidation server. Many other embodiments are possible.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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 (26) une requête d'acquisition de donnée sur un écran du terminal de paiement; • acquérir (28) la donnée par le terminal de paiement; • valider (30) dans le terminal la donnée acquise; • si la donnée est valide, transmettre (34 ou 37) la donnée par le terminal de paiement vers un serveur de consolidation et présenter (36) à l’utilisateur un message d’autorisation d'enlèvement de la carte 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, et/ou l'acquisition de la donnée est réalisée en l'absence de la carte à puce dans le terminal de paiement.

Description

PROCEDE D'ACQUISITION D'UNE DONNEE EN PROVENANCE D'UN UTILISATEUR LORS D'UN PAIEMENT PAR CARTE AVEC UN TERMINAL
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é.

Claims

REVENDICATIONS
1. Procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'une transaction de paiement par carte avec un terminal de paiement, ledit procédé comportant :
• suite à la clôture de la transaction de paiement (20), présenter (26) une requête d'acquisition de la donnée sur un écran du terminal de paiement ;
• acquérir (28) la donnée par le terminal de paiement ; • valider (30) dans le terminal la donnée acquise ;
• si la donnée est valide, transmettre (34 ou 37) la donnée par le terminal de paiement vers un serveur de consolidation et présenter (36) à l'utilisateur un message de fin de validation sur l'écran du terminal, caractérisé en ce que 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.
2. Procédé selon la revendication 1 , caractérisé en ce qu'il comporte en outre, si la donnée est invalide : • transmettre (40) une information d'échec par le terminal de paiement vers le serveur de consolidation et
• présenter (42) à l'utilisateur un message de fin de validation sur l'écran du terminal.
3. Procédé selon la revendication 1 , caractérisé en ce que, 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.
4. Procédé selon la revendication 1 , caractérisé en ce que la requête d'acquisition et sa présentation sur l'écran du terminal de paiement sont personnalisés par le serveur de consolidation puis transmises par le serveur de consolidation au terminal de paiement.
5. Procédé selon la revendication l'une quelconque des revendications 1 à 4, caractérisé en ce que 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 .
6. Procédé selon la revendication 5, caractérisé en ce que, 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.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que 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.
8. Procédé selon la revendication 4, caractérisé en ce que 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.
9. Procédé selon la revendication 4, caractérisé en ce que la requête d'acquisition est adaptée pour recueillir une pluralité de données consécutivement.
10. Procédé selon la revendication 9, caractérisé en ce que 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.
1 1. Procédé selon la revendication 1 , caractérisé en ce que 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.
12. Procédé selon la revendication 1 1 , caractérisé en ce que, 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.
13. Procédé selon la revendication 1 , caractérisé en ce que 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.
14. Produit programme d'ordinateur comportant des instructions de code de programme enregistrées sur un support lisible par un calculateur d'appareil mobile, pour mettre en œuvre les étapes d'un procédé selon l'une quelconque des revendications 1 à 13.
15. Système de recueil statistique d'informations comportant un serveur de consolidation, ledit serveur de consolidation étant connecté à un ou plusieurs terminaux de paiement effectuant une pluralité de transactions de paiement, caractérisé en ce que le serveur de consolidation 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 lesdits 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 lesdits terminaux étant adaptés pour mettre en œuvre le procédé d'acquisition selon l'une des revendications 1 à 1 1 ; • 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.
EP10737956A 2009-06-05 2010-06-07 Procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement. Withdrawn EP2438564A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0902715A FR2946445B1 (fr) 2009-06-05 2009-06-05 Procede d'acquisition d'une donnee en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement
PCT/FR2010/051122 WO2010139915A1 (fr) 2009-06-05 2010-06-07 Procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement.

Publications (1)

Publication Number Publication Date
EP2438564A1 true EP2438564A1 (fr) 2012-04-11

Family

ID=41490331

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10737956A Withdrawn EP2438564A1 (fr) 2009-06-05 2010-06-07 Procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement.

Country Status (8)

Country Link
US (1) US8510193B2 (fr)
EP (1) EP2438564A1 (fr)
JP (1) JP5479583B2 (fr)
CN (1) CN102460492A (fr)
AU (1) AU2010255590A1 (fr)
BR (1) BRPI1011078A2 (fr)
FR (1) FR2946445B1 (fr)
WO (1) WO2010139915A1 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104113411B (zh) * 2013-04-22 2017-09-29 中国银联股份有限公司 一种ic卡脱机pin验证方法以及ic卡脱机验证系统
GB2517213B (en) * 2013-08-16 2021-08-11 Trurating Ltd A payment device, a system and a method for collecting consumer ratings
GB2534342A (en) * 2014-11-03 2016-07-27 Trurating Ltd Improved system for collecting customer ratings from a PIN entry device
GB2534116A (en) 2014-11-03 2016-07-20 Trurating Ltd PIN entry device
US10171585B2 (en) 2015-12-07 2019-01-01 International Business Machines Corporation Method, system, and computer program product for distributed storage of data in a heterogeneous cloud
US10122832B2 (en) * 2015-12-07 2018-11-06 International Business Machines Corporation Communications of usernames and passwords to a plurality of cloud storages via a plurality of communications protocols that change over time
US10013181B2 (en) 2015-12-07 2018-07-03 International Business Machines Corporation Distributed storage of data in a local storage and a heterogeneous cloud
CN108076102B (zh) * 2016-11-18 2019-12-10 腾讯科技（深圳）有限公司 一种转账处理方法和装置
CN112669177A (zh) * 2019-10-16 2021-04-16 北京三好互动教育科技有限公司 一种提问人数统计方法和装置
CN112990911B (zh) * 2021-02-08 2024-05-28 北京智芯微电子科技有限公司 灰锁交易方法及安全芯片

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5700149A (en) * 1994-06-03 1997-12-23 Johnson, Iii; Oscar R. Method of personal verification for an in-resident system for administrating course material
US5717745A (en) * 1995-04-24 1998-02-10 Mci Communications Corporation System and method of efficiently evaluating different messages by a server in a telecommunications environment
US5790664A (en) * 1996-02-26 1998-08-04 Network Engineering Software, Inc. Automated system for management of licensed software
US7729988B1 (en) * 1997-03-21 2010-06-01 Walker Digital, Llc Method and apparatus for processing credit card transactions
US7980462B1 (en) * 1998-11-27 2011-07-19 Diebold Self-Service Systems Division Of Diebold, Incorporated Automated transaction machine with card reader that can read unique magnetic characteristic of a magnetic stripe
US20020029200A1 (en) * 1999-09-10 2002-03-07 Charles Dulin System and method for providing certificate validation and other services
US20010037206A1 (en) * 2000-03-02 2001-11-01 Vivonet, Inc. Method and system for automatically generating questions and receiving customer feedback for each transaction
US7593901B2 (en) * 2004-06-30 2009-09-22 Ats S.R.L. System and method for improving reliability of distributed electronic transactions
US7970673B2 (en) * 2004-10-29 2011-06-28 American Express Travel Related Services Company, Inc. Method, apparatus, and computer program product for repository data maximization
US8170897B1 (en) * 2004-11-16 2012-05-01 Amazon Technologies, Inc. Automated validation of results of human performance of tasks
US7650388B2 (en) * 2005-01-13 2010-01-19 Xerox Corporation Wireless identification protocol with confirmation of successful transmission
US7281652B2 (en) * 2005-05-18 2007-10-16 Foss Jonathan G Point-of-sale provider evaluation
US20070239516A1 (en) * 2006-03-30 2007-10-11 Smith Nigel G Systems and methods for administering survey questionnaires
WO2009050529A2 (fr) * 2007-10-15 2009-04-23 Global Customer Satisfaction System, Llc Système global de satisfaction client
US20090132813A1 (en) * 2007-11-08 2009-05-21 Suridx, Inc. Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones
US20090254531A1 (en) * 2008-04-03 2009-10-08 Walker Jay S Method and apparatus for collecting and categorizing data at a terminal
EP2465082A4 (fr) * 2009-08-14 2015-04-01 Payfone Inc Système et procédé pour payer un commerçant à l'aide d'un compte de téléphone cellulaire
US8473394B2 (en) * 2010-11-22 2013-06-25 American Express Travel Related Services Company, Inc. System, method, and computer program product for issuing automatic payments linked transaction account

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2010139915A1 *

Also Published As

Publication number Publication date
JP5479583B2 (ja) 2014-04-23
FR2946445A1 (fr) 2010-12-10
WO2010139915A1 (fr) 2010-12-09
JP2012529095A (ja) 2012-11-15
US20120116846A1 (en) 2012-05-10
US8510193B2 (en) 2013-08-13
FR2946445B1 (fr) 2015-10-30
CN102460492A (zh) 2012-05-16
AU2010255590A1 (en) 2012-01-12
BRPI1011078A2 (pt) 2016-04-12

Similar Documents

Publication Publication Date Title
EP2438564A1 (fr) Procédé d'acquisition d'une donnée en provenance d'un utilisateur lors d'un paiement par carte avec un terminal de paiement.
JP5650113B2 (ja) オンライン評価システムおよび方法
US10290007B2 (en) Method and system for turning virtual world participants into real life leads
US20030191695A1 (en) Information processing apparatus, information processing method, and program
WO2006055491A2 (fr) Utilisation des qualifications d'utilisateurs pour faciliter l'execution de taches par des utilisateurs
Sarbabidya et al. Role of chatbot in customer service: A study from the perspectives of the banking industry of Bangladesh
CN108460627A (zh) 营销活动方案推送方法、装置、计算机设备及存储介质
JP6487091B1 (ja) Ｉｃｏ管理方法、通信デバイス、ｉｃｏ管理システム及びプログラム
CN116109351A (zh) 多平台的积分兑换方法及装置、电子设备、存储介质
EP1164529A1 (fr) Système et procédé de couponnage électronique
WO2016139536A1 (fr) Appareil, système et procédé associés à des applications à incitations
S Anwar et al. Customer perceptions on internet services in kurdistan region of Iraq
KR102440532B1 (ko) 블록체인 기반의 콘텐츠 활동 보상 플랫폼 장치 및 이를 이용한 콘텐츠 활동 보상 방법
KR100856823B1 (ko) 인기투표를 통한 공연 기획 시스템
WO2001090895A2 (fr) Procede pour la realisation de tests de performances d'equipements informatiques accessibles via un reseau de telecommunication
KR20080095122A (ko) 신규 회원등록에 따른 인센티브 증가에 의한 회원관리시스템 및 그 방법
FR3093225A1 (fr) Procédé de gestion d’accès d’un utilisateur à un service vocal, dispositif, système et programmes correspondants
JP6518359B1 (ja) 顔認証技術による与信管理及び自動決済システム
KR20120079773A (ko) 온라인 이벤트 광고 방법 및 그 시스템
WO2001088780A1 (fr) Dispositif electronique portatif, methode et systeme d'analyse et/ou de prediction de comportement utilisant ledit dispositif
CN116611931A (zh) 消息推送方法、装置、存储介质及电子设备
Lal et al. A STUDY OF CONSUMER BEHAVIOUR OF DIGITAL MARKETING--WITH SPECIEL REFERENCE TO CHENNAI CITY.
CN115905665A (zh) 一种基于私域流量的发卡引流方法、系统、设备及介质
CN114881701A (zh) 一种用户引流方法、装置、电子设备及存储介质
AU2022282520A1 (en) Smart contract system and method for managing digital user engagement

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20111124

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20130103

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20151113