Patent Application
20180204273
The present technique relates to the management of non-monitored devices for supplying goods and services. Such devices are also called unattended devices. More particularly, the present invention relates to a method for transmitting messages by means of such devices. More particularly again, a method is presented for transmitting messages addressed to a communications terminal (of a user) as well as a device configured to implement such a method.
There are known devices, the purpose of which is to enable a user to make a purchase of goods and services independently, i.e. without supervision by a merchant. Such devices are also called unattended (i.e. non-monitored) devices. Examples are gas-station pumps and kiosks for issuing cinema tickets. These kiosks, which are classic devices, are small sized and enable payments to be made by using a payment terminal that accepts several forms of payment, namely smartcard payment and magnetic card payment.
More recently, large-sized kiosks have appeared. These are generally multimedia kiosks comprising large screens (generally 46-inch-diagonal screens) which may also be touch screens. Apart from being relatively costly, these kiosks present numerous technical problems. The first is that these multimedia kiosks are proprietary type kiosks. This implies that a multimedia kiosk comprises a set of components (screen, central processing unit, presence sensor, operating system, kiosk management application) that are arranged relative to each other to form the kiosk. Even more recently, multimedia kiosks embedding payment functions have been developed. These multimedia kiosks on the whole comprise the same components as classic multimedia kiosks but additionally embed a payment terminal which is generally contactless.
Such a multimedia kiosk, also called a payment kiosk with reference to the smaller sized kiosks presented here above, uses for example an NFC (Near Field Communication) type of payment terminal. Concretely, to make payment with such a payment kiosk, the user places his NFC-compatible payment means on a very precise place on the kiosk to make payment for what is displayed on the screen. This may be, for example, payment for an item or a service. It may be for example payment for seats at a show or again a donation to an association. In such certain cases, it may be payment for an item or article (which is then delivered to an agreed address).
This type of kiosk is complicated to build and implement. Indeed, as a rule, the products or services on sale that are displayed on the kiosk are more or less pre-programmed. Besides, apart from the fact that such kiosks are relatively impersonal, they also have the disadvantage of not being able to interact intensively with customer users; in particular, although the purchase can be made in a fluid manner by the use of the contactless terminal, the user's “after-sales” experience is often disappointing. For example, when the purchase relates to an article that must be delivered to a given delivery address, it may require the entry, using a touchscreen, of the delivery address and this has to be done by the user himself. Apart from the fact that the requirement of having to enter this address can be complicated for the user, it raises problems of security and confidentiality because, by definition, since the payment kiosk is in a public place, the information entered by the user can be seen by anyone and everyone, and this is not desirable. This example of post-payment entry is representative of the lack of fluidity of the operations to be carried out after purchase. Such situations can also be encountered prior to the purchase and also raise problems.
There is therefore a need to provide a simple, efficient and widely useable solution for simplifying the implementation of such kiosks and for the interaction of these kiosks with the user. More generally, there is a need to facilitate the interaction between an electronic device and a user's communications terminal, especially when there is a programmable electronic device available.
The invention does not raise these problems of the prior art. More particularly, the invention provides a simpler solution to the problems and issues identified here above. Indeed, the present technique can be used to provide a solution to the problem of making data exchanges between the vendor and the customer more fluid after the purchase is made.
More specifically, the present technique relates to a method of data transmission, a method implemented by an autonomous electronic device for the processing of payment transactions, called a payment kiosk, said payment kiosk comprising a processor connected to at least one rendering means for rendering offers of items or services being vended and to at least one communications interface and to at least one contactless payment terminal.
Such a method comprises:
Thus the autonomous electronic device for the processing of payment transactions is capable of transmitting messages, contained in the HTML content that it receives from the server, to users and/or customers who have used their communications terminals to receive such a message.
According to one particular characteristic, the request for obtaining content comprises at least one piece of data for identifying a payment kiosk.
Thus, the server is capable of identifying the contents intended for this payment kiosk. The invention thus greatly facilitates the customizing of the content transmitted by the contents server to the autonomous electronic device. Thus, the payment kiosk can, with full discretion, transmit its data in the form of a message to the user. The user's communications terminal receives this data through its contactless interface and carries out the action or actions pertaining to this data. More particularly, the data transmitted by the payment kiosk can for example include a URL to which the communications terminal can link up to carry out a certain number of tasks such as displaying an entry page directly on the user's communications terminal.
According to one particular characteristic, the step for processing said HTML content comprises a step for the determining, within the view to be rendered, of a location of a piece of data representing the exchange tag as a function of a position of a contactless antenna of said at least one payment terminal within said payment kiosk.
According to one particular characteristic, said exchange tag comprises at least one attribute defining a message to be transmitted.
According to one particular characteristic, such attribute for defining the message to be transmitted is a locating address for locating a message in a transaction server, said locating address comprising a parameter for identifying a message and at least one identifier of a payment terminal belonging to said payment kiosk.
According to one particular embodiment, the method comprises a step for cancelling said at least one message transmission, said step for cancelling step being implemented when a duration of display of a message is equal to a determined time parameter and when no transmission has been made during the time period starting after the preparation of the transmission and finishing at the time defined by said time parameter.
According to one particular embodiment, the method comprises the following steps, prior to the step of reception by the browser of the content comprising said at least one exchange tag, at the contents server:
According to one particular embodiment, prior to the step of reception by the browser of the content comprising said at least one exchange tag, the method comprises the following at the contents server:
The invention also relates to an autonomous electronic device for the processing of payment transactions, called a payment kiosk, said payment kiosk comprising a processing server connected to at least one rendering means for rendering offers of items or services being vended and linked to at least one communications interface and to at least one contactless payment terminal. Such a device comprises:
According to a preferred implementation, the different steps of the methods of the invention are implemented by one or more software programs or computer program comprising software instructions to be executed by a data processor of a relay module according to the invention and designed to command the execution of different steps of the methods.
The invention is therefore also aimed at providing a program, capable of being executed by a computer or by a data processor, this program comprising instructions to command the execution of the steps of a method as mentioned here above.
This program can use any programming language whatsoever and be in the form of source code, object code or intermediate code between source code and object code such as in a partially compiled form or in any other desirable form whatsoever.
The invention is also aimed at providing an information carrier readable by a data processor and comprising instructions of a program as mentioned here above.
The information carrier can be any entity or communications terminal whatsoever capable of storing the program. For example, the carrier can comprise a storage means such as a ROM, for example, a CD ROM or microelectronic circuit ROM or again a magnetic recording means, for example a floppy disk or a hard disk drive.
Furthermore, the information carrier can be a transmissible carrier such as an electrical or optical signal that can be conveyed via an electrical or optical cable, by radio or by other means. The program according to the proposed technique can especially be uploaded to an Internet type network.
As an alternative, the information carrier can be an integrated circuit into which the program is incorporated, the circuit being adapted to executing or to being used in the execution of the method in question.
According to one embodiment, the proposed technique is implemented by means of software and/or hardware components. In this respect, the term “module” can correspond in this document equally well to a software component and to a hardware component or to a set of hardware and software components.
A software component corresponds to one or more software module programs, one or more sub-programs of a program or more generally to any element of a program or a piece of software capable of implementing a function or a set of functions according to what is described here below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router etc) and is capable of accessing hardware resources of this physical entity (memories, recording media, communications buses, input/output electronic boards, user interfaces etc.).
In the same way, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions according to what is described here below for the module concerned. It can be a programmable hardware component or a component with an integrated processor for the execution of software, for example, an integrated circuit, a smart card, a memory card, an electronic board for the execution of firmware etc.
Each component of the system described here above implements of course its own software modules.
The different embodiments mentioned here above can be combined with one another to implement the invention.
Other features and advantages of the invention shall appear more clearly from the following description of a preferred embodiment, given by way of a simple illustratory and non-exhaustive example and from the appended drawings, of which:
As explained here above, the technique generally proposes the replacement of the “proprietary” application for implementing the payment kiosk. The application in question is replaced by a browser. This replacement makes it possible to have only a limited number of types of payment kiosk management applications. Essentially, assuming that a payment kiosk can implement a Windows' or a Linux™ system, only two browser versions are needed, one for the Windows' environment and one for the Linux™ environment.
Another advantage is that it leaves the server with the responsibility for displaying offers on the kiosk. Indeed, since the “classic” management application is replaced by a browser, the browser limits itself to displaying data transmitted to it in to a format that is also transmitted to it. Thus, according to the present invention the browser receives an HTML type document from the server to which it attaches one or m*ore style-sheets and one or more Javascript code libraries. The adjoining of this data can be achieved by inserting a link to the resources or directly by inserting data into the “HTML” type document.
However, although such an implementation is promising from the technical and economic viewpoint, it cannot resolve all the problems posed. Beyond the problems related to the management of the platform there is also the management of post-payment or pre-payment made through the kiosk. It may be recalled indeed that the kiosk is capable of making payments through one or more payment terminals directly integrated into the kiosk. The use of a “proprietary” application in a “controlled” environment has the advantage of equally controlled management of the payment terminal. The replacement of this “proprietary” application by a browser brings up problems to be resolved, especially the problem of control over payment terminals and that of way in which pre-payment or post-payment is transmitted to the user (the customer).
To resolve this problem, the present technique implements a novel tag, called an exchange tag. This tag, which is known to the browser, comprises data on the pre-payment or post-payment processing to be done by the kiosk. The working of this tag is described in detail here below. When the kiosk browser receives the HTML type document (coming from the server), it displays this document on the kiosk screen embellished with styles from the style sheets and comprising javascript type code. At least one exchange tag is present within this document. This is an exchange tag that the browser interprets in order to carry out the actions required by this tag, in connection with the payment terminal or terminals of the kiosk, with the goal of transmitting data for example subsequently to the payment itself (the payment being managed, besides, by means of a payment tag). The transmission of messages subsequently to the payment is not obligatory. The data can also be transmitted prior to the payment, depending on the requirement of interaction with the user. In other words, the data-exchanging tag is used for the transmission to the user of data that can be used to foster interaction between the user and the merchant (i.e. the one selling the product or the service proposed at the kiosk). In particular, the exchange tag modifies the mode of communication between the merchant and the user (the customer). If we take up the example of data entry, which the user had to carry out on the big screen of the payment kiosk, the use of the data-exchange tag enables the transmission, to the user's communications terminal, of a message (comprising for example a URL generated by the merchant), that is processed by the communications terminal that receives it and that, for example, links up to a server dedicated to data entry by using this communications terminal. This is is far more discreet, secured and does not oblige the user to remain before the kiosk to make this entry.
Other messages can also be transmitted, such as digital cash receipts, digital purchase vouchers, data enabling the execution of a specific application installed on the user's communications terminal, proof of purchase and promotions. A promotion can for example consist of pieces of data representing a reduction on a product to be purchased (and therefore transmitted before purchase). This is also the case when launching a specific application which can be carried out before the purchase (and the payment) made on the kiosk. Examples are described in detail here below.
Be that as it may, according to the invention, the message containing the data is transmitted by the payment kiosk to the user's communications terminal by means of an NFC interface which is present within the payment kiosk. As explained here below, the use of this NFC interface for transmitting data to the payment terminal has many advantages.
Besides, the invention has a major effect related to the merchant's capacity (i.e. the merchant whose products are displayed on the kiosk) to interact with the customer (the one who purchases the product) through the payment kiosk, which is itself operated by a payment kiosk operator (for example a transport authority or the like).
Referring to
Referring to
Depending on the intended environment of the payment kiosk (BM), this kiosk must also include a sound-rendering module (MSon): the sound-rendering module is intended for the production of sounds that may accompany the advertisement messages issued, when such sounds can be perceived by the users.
The screen (Scr) and the sound-rendering module (if it is present) are connected by one or more data-transport buses to a processor (Proc). Such a processor (Proc) has sufficient processing capacity to carry out various multimedia processing tasks such as for example the display of high-quality video and/or the display of higher-resolution images. The processor (Proc) is furthermore capable of receiving data by means of data transportation buses connecting the processor (Proc) to the NFC module (if it is not directly managed by the integrated payment terminals) or again to the wireless communications modules (such as for example the Wi-Fi module or the Bluetooth BLE module).
The processor (Proc) is furthermore connected optionally by means of a data bus to sensors (ultrasound (US) sensors, infrared (IR) sensors or again a camera (CAM)) to receive signals sent by these sensors in order to detect, as the case may be, the presence of one or more users. These signals are converted by the processor and given to the operating system (OS). The processor also has a random-access memory (RAM) and a mass storage memory (MAS).
The operating system takes sees to the execution of the browser and the managing of the data exchanges between the different components and the browser. In other embodiments, the payment kiosk can take the form of a computer, tablet or smartphone type of terminal that embeds components identical or similar in their functions and capable of implementing the methods described herein, in which case the term ‘payment kiosk’ will be replaced by a more suitable expression.
Referring to
In a complementary way, the content of the HTML type document also comprises a piece of data representing a time of display of the content. When this time of display has elapsed, the above method is again executed in order to display a new content on the screen. The object of this last step is twofold: it makes it possible not to allow the permanent display of “static” content which would have the consequence, on the one hand, of reducing the service life of the display device and, on the other hand, of having a relatively disappointing effect (due essentially to the fact that a fixed display does not attract attention and therefore does not highlight the value of the goods and services on offer as displayed on the kiosk).
In a second stage, subsequently to or at the same time as the display of the content on the screen, the payment terminal prepares (40), in advance (by anticipation), the message or messages to be transmitted. The number of message transmissions depends firstly on the number of payment terminals installed in the kiosk and secondly on the number of tags present in the content. For example, if there are four payment terminals and only three tags, only three message transmissions are prepared. Conversely, if three payment terminals are installed in the kiosk and four message-transmission tags are present, only three message transmissions are prepared (and sorted in order of appearance or location of the payment terminal).
The preparation of a transmission of messages is also conditional: either this preparation is done independently of a payment and is therefore carried out in advance, i.e. before a user has revealed his intention to purchase an article or a service (independently of the preparation of a payment transaction), or the transmission of data is conditional on a purchase (and is therefore done subsequently to the payment transaction). In the latter case, either the data exchange tag is conditional, and the data transmission is not necessarily prepared in advance (it can be prepared in advanced but the transmission in itself takes place only after the validation of the payment transaction) or the data exchange tag is received after payment, during an updating of the HTML content, in which case the method implemented is independent and all that it requires, from the server which transmits the tag, is a confirmation of payment for the article or service.
The preparation of a transmission of messages (in advance, i.e. before a user has revealed his intention to purchase an item or a service) has two purposes: firstly not having to detect the presence of the user (to initiate the transmission) and secondly, enabling immediate transmission of the message.
The preparation of a transmission of messages intended for a communications terminal is essentially done through the exchange tag (or tags) contained in the HTML document.
An exchange tag according to the present invention is essentially an instruction intended for the browser enabling the browser to prepare the transmission of a message and to do so whatever the nature of this message because the message to be transmitted is recorded as an attribute of the tag. An exchange tag is so to speak a universal interface between the server that transmits the content and the payment terminal. The exchange tag is implemented in conjunction with the browser. The exchange tag on the whole takes the following form and represents the message to be transmitted to a communications terminal:
<dataexchange></dataexchange>
The exchange tag comprises a plurality of attributes, including the usual attributes of identification (“id”, “name”, “image”) and styles enabling the display of a content of the tag when necessary. The exchange tag also has specific attributes used to prepare the transmission of the message to the communications terminal. Essentially two methods, either mutually exclusive or complementing each other depending on the implementation, are used to prepare the transaction.
The following are the possible attributes of the tag:
Should the message (for example an NDEF recording) be transmitted after a payment transaction, the data of the HTML content are displayed and the payment terminals of the kiosk prepare the transactions (by anticipation), in order to enable the users to make payment by placing their NFC communications terminals at positions the indicated by the payment tag, of which at least certain data elements (for example the price and/or a contactless payment logo) are displayed on the screen.
Two events can occur following the preparation of the transaction: either the payment is carried out by a user for one of the offers displayed (and the message is transmitted at the end of the transaction to the user's communications terminal) or no payment is made (within a given period of time). In this case, the method comprises a step for cancelling payment transactions initiated in advance, the cancellation being implemented when a duration of display of the offer is greater than or equal to a determined time parameter and when no payment has been made during the time period starting at the end of the preparation of the transaction and ending at the time defined by said time parameter. If this cancellation occurs, the method previously described (steps 10 to 40) is again implemented, leading to the display of “new” information and the preparation of new payment transactions and new messages to be transmitted by anticipation.
Should the data be transmitted independently of the performance of a transaction, the data of the HTML content is displayed and the payment terminals of the kiosk prepare the transmission of the messages contained in the data exchange tags.
There are mainly two methods for implementing this exchange tag: one uses the link attribute and the other uses the descriptive attributes. The distinction between the implementing of the first method and that of the second method can take account of the physical parameters of the payment kiosk but also of the parameters related to the messages to be transmitted or again parameters proper to the managing operator of the payment kiosks (who manages a set of payment kiosks). Thus, the implementing of either of these two methods is often pre-defined. Implementing the exchange tag enables the payment terminal to transmit messages associated with the offers present in the content and/or with the purchases made by the user.
In a first method, the payment terminal is provided with messages to be transmitted by means of an URL. In this case, the tag uses the “link” attribute which, if it has a value attached to it, comprises a link (a URL) towards a secured resource comprising the message to be transmitted. This URL can be an address towards either the contents server (the one that delivers the HTML content to be displayed) or a third-party server (a server of a merchant who is vending the item, different from the operator of the payment kiosk).
This URL enables for example the kiosk browser (depending on the cryptographic hardware that it embeds) to know the messages to be transmitted and configure the payment terminal to prepare the transmission of these messages by means of its NFC interface. However, more efficiently, this URL directly enables the selected payment terminal to know the messages to be transmitted and to configure itself accordingly and get authenticated with a server accordingly: the utility of this is that it makes sure that the messages transmitted are not compromised by an undesired modification of the browser.
Thus, to implement such a method, using the <link> tag according to the present invention, in at least one embodiment, described with reference to
This embodiment has the advantage of not requiring the supply of “secret” data to the browser. Indeed, with this method, the browser does not know which are the messages to be exchanged with the communications terminal. These messages are encrypted and transmitted directly by the browser (and the corresponding API) to the payment terminal, the identifier of which is present in the URL. Thus, even if the browser is compromised (i.e. if it is being monitored in order to impair its operation or to degrade the payment operations), it is not possible to modify the data contained in the messages to be exchanged with the communications terminal, these being messages that are encrypted and that can be decrypted only by the payment terminal (vxi) designated for this piece of data to be exchanged. However, this embodiment has the drawback of making it necessary for the browser to obtain data of the message to be transmitted from the payment terminal and of therefore requiring additional exchanges between the payment terminal and the browser (exchanges that are of course secured). Thus, this embodiment is more efficient in terms of security but entails greater constraints in terms of implementation.
Advantageously, when the message is transmitted following the effective implementation of a transaction by the transaction server (CTO), the server of the merchant from whom the item or service has been purchased is capable, having knowledge of a transaction identifier (and/or an order number), of linking the transaction to the type of message to be transmitted to the customer user, for example in order to enable complementary entry and/or provide proof of purchase etc. This is also valid for the second embodiment described here below.
A second method of implementing the exchange tag consists in providing the payment terminal with data for transmitting messages by means of the attributes of the exchange tag. In this case, the link attribute is not necessarily used. Besides, the obtaining of data from the contents server (SrvCnt) is different from that of the previous method.
To implement such a method, using exchange tags, according to the present invention in at least one embodiment described with reference to
This embodiment has the advantage of enabling the browser to directly integrate the messages to be transmitted into the view without requiring any decoding. This implementation is less secure than the first one but also more flexible. Indeed, the browser directly obtains knowledge of the data of the messages to be transmitted without having to call upon the payment terminal and can therefore prepare the view more speedily. The payment terminal also receives the messages intended for it (the recording) from the browser. Using the data received, the terminal sends a request to the transaction server and a series of exchanges takes place in order to enable the authentication of the terminal, the transaction server, data to be transmitted. The method implemented comprises the following steps:
Thus, only an authentic payment terminal and an authentic transaction server are capable of preparing the transmission of messages that are equally authentic. It can be noted that the use of the exchange tag advantageously makes it possible to “pass” data to the payment terminal transparently for the contents server. This makes it possible to have far simpler management of the contents to be transmitted to the payment kiosk: it is no longer necessary to have a “proprietary” content and standardized contents can be used without its having any impact on the security of all the data transmissions carried out by the payment kiosk.
The first method for preparing transmissions of messages comprises, as explained here above, the use of an address in the “link” tag. This embodiment is implemented rather when the payment terminal has its own communications resources for communications towards the payment and/or merchant servers, for example its own network interface, but this is in no way obligatory. In this embodiment, the payment terminal retrieves the data to be transmitted from a URL of the tag, this URL (a secured URL of the https://type) being transmitted by the browser. The payment terminal transmits a request to the server which identifies it (for example through the user agent or another parameter added by the terminal to the URL) and verifies (or even provides) the data to be transmitted.
Using this information, the terminal prepares the transmission, i.e. it initiates the transmission and then waits for the presentation of a communications terminal. In other words, the terminal acts as if the merchant had already identified a user to which this data would be transmitted. The difference is that, in principle, neither the merchant nor the terminal has any information whatsoever on the presence or non-presence of a user. The transmission of the message therefore remains “open” for a pre-determined period of time. As explained, if a customer presents his communications terminal before the contactless antenna of the payment terminal, the transmission of a message is validated by the payment terminal of the kiosk. The advantage of this procedure is that the message is transmitted rapidly, that there is no need to detect the presence of the user (the client) since it is he who reveals his presence by presenting his contactless communications terminal before the terminal. Thus, this tag and this manner of transmission resolve one of the problems explained here above with the prior-art payment kiosks, namely the need to detect the presence of the user with presence sensors.
In the second transmission-preparing method, the browser configures the payment terminal so that it can prepare the transmission. This embodiment is implemented rather when the payment terminal does not have its own communications resources and when the operating system of the kiosk acts as a gateway towards the servers (payment and/or merchant servers) but this is in no way obligatory. In this embodiment, the browser retrieves the data on the exchange tag (record, type, merchant's parameters, date, challenge) and forwards this information to the payment terminal by means of an API of the payment terminal, this API being used by the operating system to exchange information with the payment terminal. Otherwise, the method of initializing the transmission is the same as here above and the advantages obtained are identical.
When the transmission has been prepared, its finalizing is simple. It is enough, to this end, for the user to place his communications terminal at the place indicated so that the payment terminal can transmit the recording (“record” data of the exchange tag, for example an NDEF recording). To this end, just after the initialization of transmission, the payment terminal sends out a transmission request. The sending of this request is done cyclically, for as long as the display of the indication of transmission lasts on the screen. When the user places his communications terminal at the place indicated, the recording is immediately obtained by the communications terminal, which carries out the operations required by the recording (depending on the type and on the data contained in the NDEF recording).
| Number | Date | Country | Kind |
|---|---|---|---|
| 1750356 | Jan 2017 | FR | national |
