ITTO20130459A1 - PROCEDURE FOR ACQUIRING AND VALIDATING A TITLE, ITS MOBILE DEVICE, PAYMENT SYSTEM AND IT PRODUCT - Google Patents

Description

â € œProcedure for acquiring and validating a security, related mobile device, payment system and IT productâ €

TEXT OF THE DESCRIPTION

Field of invention

The present invention relates to techniques for purchasing and validating a security, such as an electronic ticket, via mobile devices, such as cell phones.

Technological background

Figure 1 shows a generic architecture of a system for purchasing via mobile devices.

In the example considered, a merchant 1 offers certain products or services and a user wishes to buy some of these products via his mobile device 2.

Typically, this payment is not made directly through the telephone operator on the telephone bill or on the residual traffic of a prepaid card, but the payment is managed through a payment operator 3, such as the banking service that manages the current account or the user's credit card.

Consequently, it is of considerable importance how the various communications are carried out between these participants in the sale, so that the operation is simple and safe. In fact, in the field of payments via mobile devices it is essential to authenticate the telephone number of mobile device 2. However, even if the current mobile communication standards, such as Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS), provide mechanisms for authenticating the telephone number of a mobile device 2, these mechanisms are not made available to users, for example to merchant 1 or the payment operator, by mobile operators.

Figure 2 shows a typical solution of a payment system that is able to manage a plurality of merchants 1 offering products and / or services and a plurality of payment operators 3, such as banking institutions. For example, in Figure 2, two merchants 1a and 1b are shown, and two payment operators 3a and 3b.

In the example considered, the system also comprises a payment management system 4 which interfaces the plurality of merchants 1 with the plurality of payment operators 3.

The skilled in the art will appreciate that some of these aspects of the payment system can be achieved through dedicated hardware or software. For example, the operations of the payment management system can be implemented through portions of software code that are performed through a computer or a computing system with distributed architecture (called cloud computing).

In the example considered, the management system 4 is responsible for converting the communications received from the various merchants 1 and sending them to the respective payment operators 3. In this way, it is not necessary that each merchant 1 must be compatible with the various communication protocols of payment operators 3, but it is sufficient for merchants 1 to implement only a single communication protocol, i.e. the communication protocol of the management system 4.

In the example considered, the operator is not necessarily directly the user's bank, but could also be another authorized payment operator that allows registration and the consequent use of the service to customers of non-member banks. For example, the user could register his credit card details and the payment service could use the credit card payment circuit.

Consequently, in the example considered, the mobile device 2 sends, for example via an SMS service message, a purchase request to a merchant 1. Subsequently, the merchant 1 forwards this request to the management system 4 which convert the request and forward the converted request to the correct payment operator 3.

For example, to identify the payment operator associated with a specific mobile device or user 2, the management system 4 can comprise a database 40 which contains data that associate a respective payment operator with each mobile device or user.

Consequently, in the example considered, the management system 4 receives a payment request from a merchant 1 that contains data that make it possible to identify the device or user requesting a purchase. For example, this data that allows the user to be identified may be the number of the cell phone or mobile device 2 that sent the SMS with the purchase request, or his IMEI (International Mobile Equipment Identity) code. Once the respective payment operator 3 has been identified through the database 40, the management system 4 can send the payment request to the respective payment operator 3.

The payment operator 3 in turn can then authorize or deny the payment. For example, payment operator 3 can check if the user has enough credit. Consequently, the payment operator 3 sends to the merchant 1 through the management system 4 a message that confirms or denies the payment and the merchant 1 can eventually deliver / supply the requested product / service. Furthermore, the payment operator 3 can also send a confirmation of payment to user 2. For example, operator 3 can send a message from the SMS service or an e-mail to user 2 for this purpose. e-mail containing a summary of the amount charged and the details of the merchant who requested the payment.

As previously mentioned, the management system 4 typically comprises a database 40 which contains data that allow the respective payment operators 3 to be associated with the various mobile devices or users 2. For example, this association can be created through a registration to the payment service. For example, this registration could be made at the payment operator 3 who communicates the registration data to the management system 4.

In general, to increase the security of the system, it can also be envisaged that the user must authorize each payment by entering a security code. For example, this mechanism can be useful to avoid payments in case of theft of the mobile device 2 or requests for unwanted payments. For example, the user could specify to receive this security code when registering with the payment operator 3. In this case, the user enters the same security code to authorize the payment, and the code is forwarded together with the purchase message to merchant 1. In a similar way, merchant 1 sends this code together with the debit request through the management system 4 to payment operator 3, which verifies the correctness of the security code. In general, this security code could also be sent in encrypted form, for example using the MD5 algorithm, AES or other symmetric or asymmetric encryption codes.

Therefore, in the example considered, user 2 sends a purchase request to merchant 1 to request a desired product or service, and merchant 1 confirms the purchase by means of a confirmation message. Consequently, device 2 must know the electronic address, such as an IP address, an e-mail address, a website address or another address that allows the merchant to be contacted electronically, or the number telephone to send the purchase request.

For example, this problem is typically solved through specific applications. For example, each merchant 1 could develop a specific application for this purpose that knows the electronic address or telephone number of merchant 1. On the one hand, this requires that user 2 must download the applications in advance on his mobile and each merchant 1 is required to develop applications for the main mobile operating systems, such as Symbian, iOS, Android, or a generic Java application. Each user must download a specific application for each merchant 1.

On the other hand, this approach improves the security of the system. In fact, as mentioned above, the payment is normally authorized through a security code. However, it is often not possible to encrypt this code together with a transaction code, for example to allow the use of different mobile devices. Therefore, the merchant receives a security code (possibly also encrypted) which could potentially be reusable for other payments. Consequently, there is a need to prevent unauthorized individuals from gaining access to these security codes. However, it is precisely in this context that the fact that the user has to download the application on his mobile device helps, because the user can immediately verify the trustworthiness of the merchant. Furthermore, modern mobile phones are usually configured to only allow the installation of certified applications and therefore the merchant must be a trusted entity.

In this context, the Italian patent applications TO2011A000575 and TO2011A000861, the contents of which are incorporated herein by reference, describe other possible procedures for authorizing payments via a mobile device.

For example, document TO2011A000575 describes a solution, in which mobile device 2 can select the product or service to be purchased through a one-dimensional or two-dimensional barcode, such as a QR code (Quick Response code) or a Data Matrix. In particular, the mobile device 2 detects, for example by means of a camera, a bar code which identifies a merchant 1 and a product / service sold. Subsequently, to verify the reliability of the codes detected, the mobile device 2 sends the code of the merchant 1 and of the product detected to the management system 4 to verify the existence and / or validity of the seller and of the product object of the sale. In particular, the management system 4 returns some control data that allow to identify the merchant and the product / service sold and the electronic address, such as an IP address or a telephone number, to which to send the request. of purchase. Consequently, the mobile device and / or the user are able to verify the correctness of the sales offer and authorize payment only if the product offered matches the desired one.

Instead, the document TO2011A000861 describes a â € œweb-basedâ € solution, in which user 2 selects the desired products on a merchant website 1. Subsequently, to start the payment and be recognized as a customer registered in the payment service , user 2 enters in a special field not his security code but a code that identifies user 2, such as his telephone number or another code associated with user 2 during registration to the ™ sales service. Consequently, merchant 1 or user 2 sends a payment request to management system 4 containing the code of merchant 1 and the code of user 2, i.e. the management system 4 receives a request of payment containing the merchant code and the user code. Once the validity of the codes has been verified, the management system 4 generates an electronic message, preferably an SMS service message that contains a unique link to a site managed by the management system 4. For example, in one embodiment, the system management sends user 2 an SMS service message containing a link to a website, in which the link includes a unique code. Therefore, user 2 receives this message containing the link to the management system site and by opening the link indicated in the electronic message, the browser of the mobile device 2 opens a web page that contains the summary of the expense in which the entering the security code. Furthermore, by opening the link indicated in the SMS service message, user 2 implicitly authenticates the telephone number of mobile device 2. Consequently, the management system 4 receives from user 2 a request for access to the website identified through the link sent to user 2, and check if the access request includes the unique code. Furthermore, if the access request includes the unique code, the management system 4 transmits to the user a web page that contains the summary of the payment to be authorized and a field for entering the security code of the ™ user. User 2 then authorizes the purchase by entering his security code. Consequently, the management system 4 receives the security code of user 2 via the web page and can transmit the request for authorization of the payment to the payment operator of user 2. Consequently, in this solution, the merchant does not get access to the user's security code but only receives a message from the management system confirming or denying payment.

The solutions described above therefore make it possible to easily purchase products or services offered by a plurality of merchants. Basically, the solutions described above have in common that typically one of the messages that are exchanged between the mobile device 2 and the merchant 1 and / or the management system 4 is an SMS message which therefore contains the number of the mobile device as a sender or as a recipient. Therefore, only the user who is in possession of the mobile device 2 can make a payment.

However, the inventor observed that the solutions described above do not solve satisfactorily the sale and validation of tickets, such as public transport tickets, as well as fail to solve the problems related to fraud, evasion and social control. For example, public transport tickets are often only valid for a single journey or for a certain area of the entire network. For example, traditionally, this problem is tackled through a ticket validation operation, for example by means of a machine mounted in a known place, for example inside a subway station or directly on board a vehicle.

Purpose and summary of the invention

The purpose of the invention is to create an architecture that addresses the problems related to the sale and validation of tickets, in particular transport tickets.

In order to achieve the aforementioned object, the invention relates to a process for purchasing and validating an electronic ticket using a mobile device equipped with the characteristics specified in the attached claim 1. The invention also relates to a related mobile device and payment system, as well as a computer product, which can be loaded into the memory of at least one computer and comprising parts of software code capable of carrying out the steps of the procedure when the product is executed on at least one computer. As used herein, the reference to such a computer product is intended to be equivalent to the reference to a computer readable medium containing instructions for controlling the computer system to coordinate the implementation of the process according to the invention. The reference to "at least one computer" is evidently intended to highlight the possibility that the present invention is implemented in a modular and / or distributed form.

Further advantageous characteristics of the invention form the subject of the attached dependent claims.

All the attached claims are to be understood as an integral part of the technical teaching provided herein in relation to the invention.

As previously mentioned, this description provides solutions that address the problems related to the sale and validation of securities that authorize access to a good / service.

In various embodiments, this problem is substantially solved by means of a mobile device, for example by means of an application installed on the mobile device, which manages both the purchase and the validation of the access title / legitimation to a good / service.

In various embodiments, the mobile device allows to select at least one security from a list of securities that can be purchased by a merchant. In various embodiments, the mobile device can also manage a plurality of merchants, and the list of merchants and the list of purchasable titles could be upgradeable.

In various embodiments, once at least one security has been selected, the mobile device sends an electronic message containing a request to purchase the security to a server of the merchant.

In various forms of implementation, the merchant's server processes the purchase request and, in the event that the payment request is confirmed, the merchant's server sends an electronic message to the mobile device containing a purchase confirmation. For example, as described above, to make the payment, the merchant's server could calculate the total amount of the securities requested and send a payment request to a payment management system which in turn forwards the request for payment. payment to the user's payment operator. In the event that these amounts are low, the user may not be required to enter a security code. Therefore, in the event that the payment is approved, the mobile device receives an electronic message from the merchantâ € ™ s server containing a confirmation of the purchase. For example, in various embodiments, once the purchase confirmation is received, the device saves the purchased titles in a list of non-validated titles.

Subsequently, the mobile device allows you to validate a security by selecting a non-validated security from the purchased securities. For example, the mobile device may show titles that are stored in the list of non-validated titles for this purpose.

In various forms of implementation, the validation operation is also reported to the merchantâ € ™ s server, for example to check the availability of the security. For example, the mobile device can send for this purpose an electronic message containing a validation request to the merchant's server containing information that identifies the security to be validated, and the merchant's server, once the availability of the security has been verified. for the user, it can send an electronic message containing a validation confirmation message. For example, this confirmation message may include a unique code that identifies the validated title.

In various embodiments, information is collected which makes it possible to identify the user's position at the time of validation. For example, the mobile device can detect the user's position by means of a GPS receiver, or it can detect an identifier of a wireless transmitter installed in a known place, or preferably it can detect a two-dimensional barcode using the camera of the mobile device. which identifies a known place, such as a subway station or a means of transport. Preferably, this position or identifier indicating a known place is also sent to the merchant's server together with the validation request.

In various embodiments, once a title has been validated, that title is removed from the list of non-validated titles and saved in a list of validated titles. Furthermore, once a title has been validated, a visual and / or acoustic effect can be reproduced.

Brief description of the drawings

The present invention will now be described in detail with reference to the attached drawings, given purely by way of non-limiting example, in which:

- Figures 1 and 2 have been previously described;

- Figure 3 is a block diagram illustrating the general architecture of a payment system according to this description;

Figures 4 to 6 illustrate various details of the operation of a mobile device which is used in the system of Figure 3.

Detailed description of embodiments The following description illustrates various specific details aimed at an in-depth understanding of the embodiments. The embodiments can be made without one or more of the specific details, or with other methods, components, materials, etc. In other cases, known structures, materials or operations are not shown or described in detail to avoid obscuring various aspects of the embodiments.

Reference to â € œan embodimentâ € in the context of this description indicates that a particular configuration, structure or feature described in relation to the embodiment is included in at least one embodiment. Thus, phrases such as â € œin one embodimentâ €, possibly present in different places of this description, do not necessarily refer to the same embodiment. Furthermore, particular conformations, structures or features can be combined in a suitable way in one or more embodiments.

The references used here are for convenience only and therefore do not define the scope of protection or the scope of the forms of implementation.

As previously mentioned, this description provides solutions that address the problems related to the sale and validation of tickets or other securities that authorize access to a good / service.

Figure 3 shows a possible embodiment of an architecture according to the present description.

In the embodiment considered, the mobile device 20 has installed an application 20 which allows to purchase an electronic ticket, or a title to access / legitimize a good / service.

Basically, this application allows you to manage the purchase of the security and the validation of the security.

Figure 4 shows the main steps that are managed by the application 20.

After an initial step 2000, application 20 shows at a step 2002 an initial page that allows you to select the operating mode of application 20.

For example, Figure 5a shows a possible screen 24 of the home page that includes three possible keys 2402, 2404 and 2406 with respective scripts â € œBUYâ €, â € œVALIDâ € and â € œEXITâ €. For example, in the embodiment considered, by pressing key 2402 the user can select a mode for purchasing a new title and by pressing key 2404 the user can select a validation mode of a previously acquired title.

Instead, the 2406 key closes the application and therefore will not be explicitly described.

Therefore, at a 2004 verification step, application 20 can verify the user's choice.

For example, if the user wants to buy a new title (â € œBUYâ € exit of the 2004 verification step), the application shows at a 2008 step the list of titles that can be acquired.

For example, Figure 5b shows a possible screenshot 24 of the page that allows you to select different titles. For example, in the embodiment considered, the screen may include a title 2408 showing the name (â € œNAMEâ €) and / or the logo of the merchant. Furthermore, the page can include a plurality of keys 2410, 2412 and 2414 that identify the respective titles that can be purchased, for example â € œTICKET 1â €, â € œTICKET 2â € and â € œTICKET 3â €, and which allow you to select one of the titles . For example, keys 2410, 2412 and 2414 can correspond respectively to a single ticket, a weekly ticket, a monthly ticket. In various embodiments, the page may also include a 2414 key that returns to the previous screen.

In various embodiments, the list of purchasable titles is stored locally, ie directly in the application 20. However, this list can be updatable, for example by downloading this information through a data connection from a remote server, such as a merchant server 1 or management system server 4. Instead in other embodiments, the list is only stored on a remote server, and the application accesses that remote server.

In general, application 20 may also be able to manage a plurality of merchants 1. For this reason, the application can select a merchant 1 at one step 2006, and application 20 can show at step 2008 only the securities of that merchant.

For example, in various embodiments, the application shows at step 2006 a list of merchants and the user can select one of the merchants. For example, substantially the same screen shown in Figure 5b could also be used for the selection of the merchant (s).

In general, the application may also automatically select the merchant (s) that are most appropriate. For example, the application could detect the position of the user, for example by using a GPS receiver or based on the identifications of the base stations of the mobile radio network. Therefore, knowing the position of the user, the application could directly select the merchant responsible for the respective area or show only the list of merchants serving the respective area. In general, also the list of merchants 1 and / or the respective contact data used to initiate the payment could be updated, for example by downloading this list from a server of the management system 4. In fact, this solution allows new merchants they can also be added later and guarantees that only trusted merchants can offer their products / services.

Therefore, the user can select at one step 2010 through the application 20 one or possibly even more titles he wishes to purchase.

Finally, the user acquires the selected titles one step away from 2016. For example, this payment could be managed directly through the application 20 or the application could behave like a web browser that allows payment to be made on a remote merchant site.

For example, in various forms of implementation, the application could send the payment request directly to merchant 1 by essentially following the flow chart shown in Figure 6 of document TO2011A000575. Therefore, the related description in document TO2011A000575 will not be repeated here for simplicity, but is intended to be incorporated herein by reference.

Instead, in other forms of implementation, the purchase could be web-based and the application could function as a simple web browser that follows the operation described in the document TO2011A000861.

In general, once the purchase is completed, the application 20 receives at one step 2018 from the merchant (or possibly from the management system 4) a message confirming or denying the purchase (for example the messages â € œERR1..ERR5â € and â € œOK1â € shown in Figure 6 of document TO2011A000575).

In various embodiments, application 20 stores at step 2020 the acquired titles in a list of non-validated TNV titles, the function of which will be described later, and returns to the initial screen, that is to step 2002. For example, also in this case the screen shown in Figure 5b could basically be used.

On the other hand, if the user wants to validate a previously acquired title (exit â € œVALIDâ € of the 2004 verification step), the application shows at a step 2022 the list of titles that the user acquired previously and which are not yet validated.

For example, the application could show for this purpose the titles that were stored in step 2020 stored in the TNV non-validated title list.

However, as explained above, local storage is only optional and this list could only be stored remotely, for example on a merchant 1 server. In this case, application 20 could connect to the server of merchant 1. Merchant, authorizing himself for example through an identification code of the user and / or application 20, and download this list of non-validated securities. However, in general it is preferable that the list of non-validated securities and the list of validated securities are stored both in application 20 and on the merchant's server.

At a step 2024, the user can select a title from the list shown in step 2022, ie the application 20 detects the selection of one of the titles in the list of non-validated titles.

Once a title has been selected from the list of non-validated titles, the application validates this title at a step 2026.

As explained above, the inventor noted that this validation operation should be tied to the current location of the user.

For this reason, the application can detect information at a step 2028 that allows identifying the position of the user at the time of validation of the title. For example, in one embodiment, the application 20 detects the user's position by means of a GPS receiver.

In general, the application may also only detect a code that identifies the current location of the user. For example, this code could correspond to the identification of the base station of the mobile radio network to which the mobile device is associated, or an identifier of another wireless transmitter installed in a known place, such as a WiFi transmitter, RF- ID (Radio Frequency IDentification) or Bluetooth which is installed in the subway station or on board a coach or other means of transport.

Instead, in a currently preferred embodiment, this code is stored inside a two-dimensional bar code 100, such as for example a QR code or a Datamatrix.

For example, as also shown in Figure 3, in one embodiment, a barcode 100 is fixed in a known place 10, such as for example at the entrance to a subway station or on board a coach, for example near the port of entry. In this case, the application connects to a camera 22 of the mobile device 2 and processes the image to detect a barcode. For example, once a barcode has been detected, the application can also process the barcode and determine the code that identifies the position. In particular, the code can univocally identify a position, but also only an area, or identify a number of the means of transport or the code of the line. In fact, even a plurality of identical bar codes could be installed in the same place, for example in the same bus, or at the bus stop.

Therefore, once the user's position has been detected, or the code that identifies the user's position, the application 20 validates the title.

For example, the application can send a message to the server of merchant 1 at step 2030, indicating that a security has been validated. Subsequently, merchant 1 server processes the message and confirms the validation by sending a confirmation message. Preferably, the application 20 also sends at step 2030 the position and / or the unique code that identifies the position of the user to the server of merchant 1.

Therefore, at a step 2032, application 20 can receive the validation confirmation message from the merchant 1 server. For example, the confirmation message can be an SMS message and / or the message can contain a unique code which identifies the validated title. For example, this validation confirmation message could be shown in case of checks.

In various embodiments, in the event that the list of non-validated TNV titles is stored in the application, application 20 can identify the title as validated, for example by removing the title from the list of titles not TVC validated and store the validated title in a list of TV validated titles. The application can also store the position and / or the unique code that identifies the user's position in this list of validated titles. In addition, the application could also save the validation confirmation message in that TV list and associate it with the respective validated title. For example, such a validated list of titles could be shown in case of controls.

Finally, application 20 can inform the user that the title has been validated, for example by reproducing a visual and / or acoustic effect at step 2036, and return to the initial screen, or step 2002. For example playback of an acoustic effect is particularly useful for highlighting to other users the effective validation of a valid ticket, thus triggering social control mechanisms.

Therefore, in general, the purchase of a security is initiated through the application 20 installed on the user's mobile device 2 (steps 2006-2016). Instead, the server of merchant 1 sends a message indicating the purchase of the security (step 2018) and records the information of the security, for example in a database. Preferably, application 2 also records the acquired titles in parallel in a list of non-validated TNV titles (step 2020).

Subsequently, the user can validate a non-validated title (steps 2022-2026). Preferably, application 20 detects the position of the user and also sends a validation message for a security to merchant 1 (steps 2028-2030). Therefore, the merchant 1 server receives a message, for example via a data flow from application 2, which indicates the request for validation of a given security, identified for example by a code that identifies the user and a code that identifies the type of security, or a unique code associated with the security at the time of purchase.

Preferably, the merchant 1's server also receives information that identifies the user's position, for example the two-dimensional barcode aimed at validation. Therefore, the merchant 1's server can receive a plurality of information, such as the identification code of the access / legitimation title, the code stored inside the two-dimensional barcode that indicates a vehicle, a line or a location as well as GPS coordinates and other available information. The merchant 1 server can process this information, for example by checking the presence of the security in the list of non-validated securities and, if available, report it as validated and send a confirmation message, such as an SMS or data stream, to the mobile device 2 (step 2032). This message may also contain a code that uniquely identifies the validated title and therefore cannot be reused. This unique code can also have only a temporal validity.

A possible use of the solution described above will now be described in the example of a purchase of a bus ticket.

Initially, the user opens the application 20 to select a security to purchase (steps 2006-2010). In this context, the application could detect the position of the user and show only the tickets that can be purchased in that specific geographical area for a specific local public transport company.

Subsequently, the user purchases the security of his interest and the server of merchant 1 confirms the purchase by sending the purchase receipt of the security to application 20 which stores the confirmation in the list of non-validated securities (steps 2016 -2020).

Later, the user gets on the bus and selects the ticket to be validated from the list of non-validated tickets and clicks on a button to validate the ticket (steps 2022-2024). To validate the title, the application is configured as a two-dimensional barcode reader and possibly also performs a geolocation to detect the exact position of the user (step 2028). The user reads the two-dimensional validation barcode which should be available in predetermined and easily accessible locations, such as inside the bus. Once the barcode has been detected, application 20 sends a data stream to the server of merchant 1 containing the identification of the ticket to be validated, the code stored in the two-dimensional barcode, for example the bus code on you have climbed, possibly the geo-location information and any other information requested by the local public transport company (step 2030). The merchantâ € ™ s server, in turn, checks for the presence of information relating to the identification of the security and, if available, validates the userâ € ™ s security. Finally, the merchantâ € ™ s server sends a message, for example an SMS or a data stream, which contains the duly validated access title to the user, possibly also in terms of time validity, such as a unique code. In turn, the mobile device receives the message with the validated title that can be shown to any controller in case of step control (2034-2034).

Figure 6 illustrates an embodiment which also includes a method of revalidating a security. Therefore, the purchase (â € œBUYâ €) and validation (â € œVALIDâ €) methods will not be repeated but the operation described with reference to Figure 4 will be applied. the user has to change the means of transport and should check that the title is still valid.

For example, in this case, the screen shown in step 2002 can include an additional key 2418, for example with the writing â € œCHECKâ €, which allows you to check the validity of a title.

Therefore, in case the user wants to revalidate a title that has been previously validated (exit â € œCHECKâ € of the 2004 verification step), the application can automatically search for the last validated title. For example, if the list of validated titles is also stored locally, the application can retrieve this title from the TV list, otherwise application 20 can contact the server of merchant 1 is request information on the last validated title, possibly authorizing through an identification code of the user and / or application.

Subsequently, the application 20 can revalidate the title to one step 2042 substantially following the steps that are performed for the validation of a non-validated title.

For example, also in this case, the application can detect information at a step 2044 that allows to identify the position of the user at the moment of the re-validation of the title. For example, the application can connect to the camera 22 of the mobile device 2 and process the image to detect a barcode that identifies, for example, the means of transport.

Subsequently, the application can send a message to the server of merchant 1 at step 2046, signaling the fact that a security must be revalidated and the server of merchant 1 can process the message and confirm the revalidation by sending a message which confirms or denies the revalidation. For example, the merchant can check if the security continues to have validity characteristics, such as, for example, it is still within the time validity period. Preferably, application 20 also sends at step 2046 the position and / or the unique code that identifies the position of the user to the server of merchant 1. Therefore, at step 2048, application 20 can receive the message confirming the revalidation from the server of the merchant 1. The application 20 can signal at a step 2050 the result of the revalidation also to the user, for example by reproducing visual and / or acoustic effects that are different for the cases confirmation and refusal of revalidation.

Finally, application 20 can return to the initial screen, that is to step 2002.

Naturally, the principle of the invention remaining the same, the construction details and the embodiments may be widely varied with respect to what is described and illustrated purely by way of example, without thereby departing from the scope of the present invention, as well as defined by the following claims.

Claims (11)

CLAIMS 1. Procedure for purchasing and validating an electronic ticket, or an access ticket to a good / service, via a mobile device (2) comprising the steps of: - select (2006-2010) at least one security from a list of securities that can be purchased by a merchant (1); - send (2016) an electronic message containing a purchase request for said at least one security to a server of said merchant (1); - receive (2018) from said server of said merchant (1) an electronic message containing a confirmation of the purchase of said at least one security; - select (2022-2024) a non-validated security among the purchased securities; And - validate (2026) said non-validated title. Method according to claim 1, comprising managing (2020) in a memory of said mobile device (2) a list of non-validated titles (TNV) and a list of validated titles (TV); wherein said at least one purchased security is saved in said non-validated security list (TNV); and wherein said validating (2026) said non-validated title comprises removing (2034) the respective title from said list of non-validated titles (TNV) and saving the respective title in the list of validated titles (TV). The method according to claim 2, wherein said selecting (2022-2024) a non-validated security among the purchased securities comprises displaying (2022) the securities which are saved in said non-validated security list (TNV). Method according to one of the preceding claims, wherein said validating (2026) a non-validated security comprises detecting (2028) information which allows to identify the position of the mobile device. Method according to claim 4, wherein said detecting (2028) information that allows identifying the position of the mobile device comprises at least one of: - detect the position of the mobile device by means of a GPS receiver; - detect an identifier of a wireless transmitter installed in a known place, such as the identification of the base station of the mobile radio network to which the mobile device is associated, or the identifier of a WiFi transmitter, RF-ID o Bluetooth; and / or - detect through a camera (22) of the mobile device (2) a two-dimensional barcode (100), such as for example a QR code or a Datamatrix, in which the code identified by said two-dimensional barcode (100) identifies a place known. Method according to one of the preceding claims, wherein said validate (2026) a non-validated title comprises: - send (2030) an electronic message containing a validation request to said server of said merchant (1) which contains information identifying the security to be validated; - receive (2032) from said server of said merchant (1) an electronic message containing a validation confirmation message. 7. A method according to claim 6, wherein said electronic message containing a validation confirmation message comprises a unique code which identifies the validated title. Method according to one of the preceding claims, comprising, in case a title has been validated, reproducing (2036) a visual and / or acoustic effect. A mobile device, characterized in that said mobile device (2) is configured to implement the method according to one of claims 1 to 8. A payment system comprising at least one merchant server (1) and a mobile device according to claim 9. 11. Computer product that can be loaded into a memory of at least one processor and comprises portions of software code for implementing the method according to one of claims 1 to 8.