EP2924661A1

EP2924661A1 - Method for managing issue of an electronic ticket and corresponding system

Info

Publication number: EP2924661A1
Application number: EP15160605.0A
Authority: EP
Inventors: Enrico Sponza
Original assignee: Movincom Servizi SpA
Current assignee: Movincom Servizi SpA
Priority date: 2014-03-25
Filing date: 2015-03-24
Publication date: 2015-09-30

Abstract

A method for managing issue of an electronic ticket comprising the steps of:
- receiving from a first mobile device (2) a request for issuing an electronic ticket; and
- processing the request and verifying whether the electronic ticket can be issued.

In particular, the request comprises data that enable identification of the position of the user who requests issue of an electronic ticket, and the method comprises:
- receiving from at least one second mobile device (4) an electronic message that identifies start or end of a check made by a person responsible for carrying out the check, wherein the electronic message comprises the position of the respective check;
- processing each electronic message that identifies start or end of a check and saving in a data base (10) data that enable identification of the checks that are in progress and their positions;
- processing the position of the user and the positions of the checks, and verifying whether the user is in the vicinity of at least one of the checks; and
- in the case where the user is not in the vicinity of any check, sending to the first mobile device an electronic message that indicates correct issue of the electronic ticket.

Description

Field of the invention

The present invention relates to techniques for issue and verification of an electronic ticket using mobile devices, such as for example cellphones.

Technological background

Figure 1 shows a generic architecture of a purchasing system using mobile devices.
In the example considered, at least one dealer or, as referred to hereinafter, vendor 1 (for example two vendors 1a and 1b are shown in Figure 1) offers certain products or services and a user wishes to buy some of these products using his own mobile device 2.
In general, payment is managed via at least one payment operator 3, such as for example the user's telephone operator 3a or the banking service 3a that manages the user's current account or credit card. In addition, the payment operator 3 could even be an authorized payment operator that enables subscription of and consequent use of the service by customers of banks that belong to the purchasing system. For instance, the user could register the data of his credit or debit card, and the payment service could use the payment circuit of the credit or debit card.
Typically, the system moreover comprises a payment-management system 4 that interfaces the plurality of vendors 1 with the plurality of payment operators 3.
The person skilled in the art will appreciate that some of these aspects of the payment system can be obtained by dedicated hardware and/or software. For instance, the operations of the vendor 1 and/or of the payment-management system 4 can be implemented via portions of software code that are executed by a computer or a processing system with distributed architecture (cloud computing).
In the example considered, the management system 4 is responsible for converting the communications received from the various vendors 1 and sending them to the respective payment operators 3. In this way, it is not necessary for each vendor 1 to be compatible with the various communication protocols of the payment operators 3, but it is sufficient for the vendors 1 to implement just a single communication protocol, i.e., the communication protocol of the management system 4.
For instance, in the architecture illustrated in Figure 1, the mobile device or user 2 could send, for example via an SMS (Short Message Service) message, a purchasing request to a vendor 1. Then, the vendor 1 forwards this request to the management system 4, which converts the request and forwards the converted request to the right payment operator 3.
For example, to identify the payment operator associated to a specific mobile device or user 2, the management system 4 may comprise a data base 40 that contains data that associate a respective payment operator to each mobile device or user.
Consequently, in the example considered, the management system 4 receives from a vendor 1 a payment request that contains data that enable identification of the device or the user who requests a purchase. For instance, the datum that enables identification of the user can be the number of the cellphone or mobile device 2 that has sent the SMS with the purchasing request, or its IMEI (International Mobile Equipment Identity) code. Once the respective payment operator 3 has been identified via the data base 40, the management system 4 can send the payment request to the respective payment operator 3.
The payment operator 3 can in turn then authorise or refuse the payment. For instance, the payment operator 3 can verify whether the user has sufficient credit. Consequently, the payment operator 3 sends to the vendor 1, through the management system 4, a message that confirms or refuses the payment, and the vendor 1 can possibly deliver/supply the product/service requested. Furthermore, also the payment operator 3 can send to the user 2 a confirmation that payment has gone through. For instance, the operator 3 can for this purpose send to the user 2 an SMS message or an e-mail that contains a summary on the amount debited and the account details of the vendor who has requested the payment.
As mentioned previously, the management system 4 typically comprises a data base 40, which contains data that enables association of the respective payment operators 3 to the various mobile devices or users 2. For instance, this association can be created via subscription to the payment service. For example, subscription could be made at the payment operator 3, which communicates the subscription date to the management system 4.
In general, to increase safety of the system, it may also be envisaged that the user has to authorise each payment via entry of a security code. For instance, this mechanism may be useful for preventing payments in the case of theft of the mobile device 2 or undesired requests for payments. For example, the user could specify or receive this security code during subscription at the payment operator 3. In this case, the user enters the same security code for authorising the payment, and the code is forwarded together with the purchasing message to the vendor 1. In a similar way, the vendor 1 sends this code, together with the debit request, through the management system 4 to the payment operator 3, which checks the correctness of the security code. In general, this security code could be sent also in encrypted form, for example using the MD5 algorithm, the AES algorithm, or other symmetrical or asymmetrical encryption codes.
Purchasing or payment systems as illustrated in Figure 1 can be used, for example, for the purchase and/or validation of tickets for public transport.
For instance, the document No. TO2011A000575 , the contents of which are incorporated herein for reference, describes a solution in which the mobile device 2 can select the product or service to be purchased via a one-dimensional or two-dimensional bar code, such as for example a QR (Quick Response) code or a Datamatrix code. In particular, the mobile device 2 detects, for example via a camera, a bar code that identifies a vendor 1 and a product/service sold. Next, to verify reliability of the codes detected, the mobile device 2 sends the code of the vendor 1 and of the product detected to the management system 4 for verifying the existence and/or validity of the seller and of the product being sold. In particular, the management system 4 returns some control data that enable identification of the vendor and of the product/service sold, and the electronic address, such as for example an IP address or a telephone number, to which to send the purchasing request. Consequently, the mobile device and/or the user are able to check the correctness of the sales offer and authorise the payment only if the product offered corresponds to the desired one. Consequently, by applying similar bar codes at the stops in the case of public transport, the user could purchase a ticket that is immediately validated.
Instead, the document No. TO2011A000861, the contents of which are incorporated herein for reference, describes a web-based solution, in which the user 2 selects the desired products on an Internet site of a vendor 1. Next, to proceed to payment and be recognized as customer subscribing to the payment service, the user 2 enters in a purposely provided field, not his security code, but a code that identifies the user 2, such as for example his telephone number or some other code associated to the user 2 during subscription to the sales service. Consequently, the vendor 1 or the user 2 sends to the management system 4 a payment request containing the code of the vendor 1 and the code of the user 2; i.e., the management system 4 receives a payment request containing the vendor 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 message that contains a unique link to a site managed by the management system 4. Consequently, the user 2 receives this message containing the link to the site of the management system and by accessing the link indicated in the electronic message, the browser of the mobile device 2 opens a webpage that contains the summary of the purchase, where the user 2 is required to enter his security code. The user 2 hence authorises purchase by entering his security code. Consequently, in this solution, the vendor does not obtain access to the security code of the user but receives from the management system only a message that confirms or refuses the payment. Consequently, using the solution described in the document No. TO2011A000861 , the user could also purchase a validated ticket for the desired public means of transport.
Finally, the document No. TO2013A000459 describes a solution in which the user can use his mobile device, for example by means of an application installed on the mobile device, which manages both purchase and validation of the ticket for access or entitlement to a good, amenity or service. In this case, the mobile device enables selection of at least one ticket from a list of tickets that can be purchased from a vendor, and once at least one ticket has been selected, the mobile device sends an electronic message containing a request for purchase of the ticket to a server of the vendor (using, for example, the solutions described in the documents Nos. TO2011A00057 and TO2011A000861) The vendor's server processes the purchasing request and, in the case where the payment request is confirmed, the vendor's server sends to the mobile device an electronic message containing a confirmation of purchase. For instance, as described previously, for the payment to be made, the server of the vendor 1 could calculate the total amount of the tickets requested and send a payment request to a payment-management system, which in turn forwards the payment request to the payment operator of the user. Consequently, in the case where the payment is approved, the mobile device receives from the vendor's server an electronic message containing a confirmation of the purchase, and the device saves the tickets purchased in a list of non-validated tickets. Then, the mobile device enables validation of a ticket by selecting a non-validated ticket from among the tickets purchased, thus guaranteeing that a ticket is validated only once.
However, the inventor has noted that the solutions described previously do not solve in a satisfactory way the sale and validation of tickets for public transport.

Object and summary of the invention

The object of the invention is to provide an architecture that tackles the problems linked to issue and verification of electronic tickets, in particular tickets for transport.
In order to achieve the aforesaid purpose, the subject of the invention is a method for managing issue of an electronic ticket that presents the characteristics specified in the annexed Claim 1. The invention also relates to a corresponding system, as well as a computer program product, that can be loaded into the memory of at least one computer and comprises portions of software code that can execute the steps of the method when the product is run on at least one computer. As used herein, reference to such a computer program product is understood as being equivalent to reference to a computer-readable means containing instructions for control of the computer system in order to co-ordinate implementation of the method according to the invention. Reference to "at least one computer" is evidently intended to highlight the possibility of the present invention being implemented in modular and/or distributed form.
Further advantageous characteristics of the invention form the subject of the annexed dependent claims.
All the annexed claims are to be understood as forming an integral part of the technical teaching provided herein in relation to the invention.
As mentioned previously, the present description provides solutions that tackle the problems linked to issue and verification of electronic tickets.
In various embodiments, this problem is basically solved via a system that handles issue of electronic tickets, such as for example a server that runs an appropriate software application.
In various embodiments, the system receives from a mobile device of a user an electronic message that contains a request for issuing an electronic ticket, i.e. a request for purchase of a validated ticket or a request for validation of a non-validated ticket, and the system processes the request.
In particular, in various embodiments, the request for issuing the electronic ticket comprises data that enable identification of the position of the user who requests issue of the aforesaid electronic ticket.
In various embodiments, the system may also receive from a second mobile device, such as the mobile device of a ticket collector, an electronic message that identifies start/end of a ticket check and the position of the respective check.
In various embodiments, the system processes these messages and saves data that enable identification in a data base of the checks that are in progress and their positions.
Consequently, knowing the position of the user who requests issue of the electronic ticket and the positions of the checks in progress, the system can determine whether the user is in the vicinity of at least one of the checks. For instance, in one embodiment, the system determines the means of transport that the user has taken or the means of transport that the user could take. In a similar way, the system can also determine the means of transport on which a ticket check is in progress or the means on which check could be carried out. Finally, the system can determine whether the user could take a means on which a check is in progress.
In various embodiments, in the case where the user is not in the vicinity of any check, the system can confirm issue, for example by sending to the mobile device of the user an electronic message that indicates proper issue of the electronic ticket.
Instead, in the case where the user is in the vicinity of at least one of the checks, the system can refuse issue of the ticket, for example by sending to the user an electronic message that indicates refusal to issue the electronic ticket. Instead, in various embodiments, the system does not refuse issue, but signals the fact that this ticket has been issued while a check was in progress. For instance, in various embodiments, the system sends to the user a confirmation message and saves for the electronic ticket data identifying the checks that were in progress in the vicinity of the user.
The distinction of these operating modes may be made, for example, on the basis of the time that has elapsed between start of the check and the request of emission of the electronic ticket. For instance, in one embodiment, the system can also issue the ticket normally if this time is short.
In various embodiments, the system can also take into consideration the number of the means of transport that the user could take and on which a check could be made in a given position. For example, in the case where in a position just one means of transport passes in a given time interval, the system can assume that the user will take that means.
In various embodiments, the ticket collector is able to verify the validity of an electronic ticket directly on the user's device. For this purpose, the system can receive from the mobile device of the user an electronic message that contains a request for checking an electronic ticket. In particular, also in this case, the request comprises data that enable identification of the position of the user.
In various embodiments, the system processes these data and the data saved in the data base that enable identification of the positions of the checks to verify whether the user is actually in the vicinity of at least one check.
Consequently, only in the case where there are checks in the vicinity, the system could determine the validity of the electronic ticket and send the result of the check to the mobile device of the user.
However, as mentioned previously, in some cases the ticket could have been issued while a check was in progress. In this case, the system (once it has detected that there are additional data for the electronic ticket) sends to the mobile device of the user also the data identifying the checks that were in progress in the vicinity of the user at the moment of issue of the electronic ticket.
Consequently, thanks to this additional information, the staff responsible for carrying out checks is able to assess whether the user has requested issue while a check was already in progress on the means of transport.

Brief description of the drawings

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

Figure 1 has already been described previously;
Figures 2 to 5 show solutions that enable purchase and/or validation of an electronic ticket according to the present description;
Figure 6 shows an architecture of a system for issuing electronic tickets according to the present description; and
Figures 7 to 9 show various details of operation of the system illustrated in Figure 6.

Detailed description of embodiments

Illustrated in the ensuing description are various specific details aimed at providing an in-depth understanding of the embodiments. The embodiments may be obtained 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 illustrated or described in detail so that various aspects of the embodiments will not be obscured.
Reference to "an embodiment" or "one embodiment" in the framework of the present description is intended to indicate that a particular configuration, structure, or characteristic described in relation to the embodiment is comprised in at least one embodiment. Hence, phrases such as "in an embodiment" or "in one embodiment" that may be present in various points of this description do not necessarily refer to one and the same embodiment. Furthermore, particular conformations, structures, or characteristics may be combined in any adequate way in one or more embodiments.
The references used herein are only provided for convenience and hence do not define the sphere of protection or the scope of the embodiments.
As mentioned previously, the present description provides solutions that tackle the problems linked to issue and verification of electronic tickets for public transport.
Figure 2 shows a possible embodiment of an architecture according to the present description.
In the embodiment considered, installed on the mobile device 2 is an application 20 that enables purchase of an electronic ticket, i.e., a ticket for access or entitlement to a good, amenity or service.
Basically, this application enables management of purchase of the ticket and/or validation of the ticket.
Figure 3 shows a possible embodiment of a method that enables purchase of a ticket for public transport.
After an initial step 2000, the application 20 displays in a step 2002 an initial page that enables selection of the operating mode of the application 20.
For instance, Figure 4a shows a possible screenful 24 of the initial page that comprises at least two keys 2402 and 2406 with respective wordings "BUY" and "EXIT". For example, in the embodiment considered, by pressing the key 2402 the user can select a mode of purchase of a new ticket. Instead, the key 2406 closes the application and consequently will not be described explicitly.
Consequently, in a verification step 2004, the application 20 can verify the choice of the user.
For instance, in the case where the user wishes to purchase a new ticket (output "BUY" from the verification step 2004), the application shows in a step 2008 the list of tickets that can be bought.
For example, Figure 4b shows a possible screenful 24 of the page that enables selection of different tickets. For instance, in the embodiment considered, the screenful may comprise a ticket 2408 that shows the name ("NAME") and/or the logo of the vendor. Furthermore, the page may comprise a plurality of keys 2410, 2412, and 2414 that identify the respective tickets that can be purchased, for example "TICKET 1", "TICKET 2", and "TICKET 3", and that enable selection of one of the tickets. For instance, the keys 2410, 2412, and 2414 may correspond, respectively, to a single ticket, a weekly ticket, and a monthly ticket. In various embodiments, the page may also comprise a key 2414 that returns the user to the previous screenful.
In various embodiments, the list of tickets that can be purchased is stored locally, i.e., directly in the application 20. However, this list can be updated, for example by downloading the information through a data connection from a remote server, such as for example the server of a vendor 1 or a server of the management system 4. Instead, in other embodiments, the list is only stored on a remote server, and the application accesses this remote server.
In general, the application 20 may also be able to handle a plurality of vendors 1. For this reason, the application can select in a step 2006 a vendor 1, and the application 20 can show in step 2008 only the tickets of this vendor.
For example, in various embodiments, the application shows in step 2006 a list of vendors, and the user can select one of the vendors. For instance, substantially the same screenful as the one appearing in Figure 4b could be used also for selection of the vendor or vendors.
In general, the application could also select automatically the vendor or vendors that are most appropriate. For instance, the application could detect the position of the user, for example using a GPS receiver, or another satellite receiver, or on the basis of the identifications of the base stations of the mobile-radio network. Consequently, knowing the position of the user, the application could select directly the vendor responsible for the respective area or show only the list of the vendors that serve the respective area. In general, also the list of the vendors 1 and/or the respective data of contacts that are necessary for starting payment procedure could be updateable, for example by downloading this list from a server of the management system 4. In fact, this solution enables new vendors to be added also subsequently and guarantees that only reliable vendors can offer their products/services.
Consequently, in a step 2010, the user can select through the application 20, a ticket, or possibly even more than one ticket, that he wishes to purchase.
Finally, in a step 2016, the user purchases the tickets selected. For instance, the payment could be handled directly via the application 20, or the application could behave like a web browser that enables the payment to be made on a remote site of the vendor. For instance, in various embodiments, the application could send the payment request directly to the vendor 1 by following substantially the flowchart illustrated in Figure 6 of the document No. TO2011A000575 . Consequently, the corresponding description of the document No. TO2011A000575 will not be repeated here for simplicity, but it is understood as being incorporated herein by reference. Instead, in other embodiments, the purchase could be web-based, and the application could function as a simple web browser that follows the operation described in the document No. T02011A000861 .
In general, once the purchase is completed, in a step 2018, the application 20 receives from the vendor (or possibly from the management system 4), a message that confirms or refuses the purchase (for example, the messages "ERR1...ERR5" and "OK1" appearing in Figure 6 of the document No. TO2011A000575 ).
In the embodiment considered, the ticket is a validated ticket. By "validation of a ticket" it is meant that the ticket is in some way stamped, typically with the date and preferably also the time of validation. Consequently, at the moment of validation information is associated to the ticket that enables identification of the fact that the ticket has been used. This information may include at least one of the following:

the date and/or time of validation, i.e., information identifying the start of validity of the ticket;
information identifying the duration of validity of the ticket; and
information identifying the end of validity of use of the ticket.

In one embodiment, this information also includes information that enables identification of the position of the mobile device 2, i.e., of the user at the moment of validation. For this reason, the application can detect, in a step 2014, information that enables identification of the position of the user at the moment of validation of the ticket, such as for example the position of the user that is detected by means of a satellite receiver, such as a GPS receiver of the mobile device.
In general, the application 20 could even detect just a code that enables identification of the position of the user. For example, this code could correspond to 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 for example a WiFi transmitter, an RF-ID (Radio Frequency IDentification) transmitter, or a Bluetooth transmitter that is installed in an underground station or on board a coach or other means of transport.
In one embodiment, this code can be stored within a two-dimensional bar code, such as for example a QR code or a Datamatrix code 10. For instance, this bar code could be fixed in a known place 100, such as at the entrance of an underground station or on board a coach or bus, for example close to the entry door. In this case, the application connects up to a camera 22 of the mobile device 2 and processes the image to detect a bar code. For instance, once a bar code is detected, the application also processes the bar code and determines the code that identifies the position. In particular, the code can identify uniquely a position, but even just an area, or identify a number of the means of transport, i.e., the unique code of the vehicle, or the code of the line. In fact, also a plurality of identical bar codes could be installed in the same place, for example in the same bus, or at the bus stop.
Consequently, once the position of the user or the code that identifies the position of the user is detected, the application 20 sends, in step 2016, the request for purchase of the ticket to the vendor. In the embodiment considered, in step 2018 the vendor 1 returns a unique code that identifies a validated ticket, and the vendor could associate, i.e., store on the server side and/or transmit to the application 20, the information mentioned previously that enables identification of validity of the ticket.
In various embodiments, the application 20 stores (in step 2020) the tickets purchased in a list of validated tickets TV and returns to the initial screenful, i.e., to step 2002.
Instead, Figure 5 shows an embodiment in which the ticket purchased is not yet validated; i.e., the vendor returns (in step 2018) a unique code that identifies a non-validated ticket, and the application stores (in step 2020) a list of non-validated tickets TNV.
In this case, the screenful 24 of the initial page could comprise a further key 2404 with the wording "VALID" that enables validation of a ticket previously purchased.
Consequently, in the case where the user wishes to validate a ticket purchased previously (output "VALID" from the verification step 2004), the application displays (in a step 2022) the list of tickets that the user has purchased previously and that have not yet been validated.
For instance, the application 20 could show for this purpose the tickets that have been stored in step 2020 in the list of non-validated tickets TNV. As explained previously, local storage is only optional, and this list TNV could also be stored only remotely, for example on a server of the vendor 1. In this case, the application 20 could connect up to the server of the vendor 1, logging in, for example, by using an identification code of the user and/or of the application 20, and downloading the above list of non-validated tickets. However, in general it is preferable for the list of non-validated tickets and the list of the validated tickets to be stored both in the application 20 and in the server of the vendor 1.
In a step 2024, the user can select a ticket from the list displayed in step 2022; i.e., the application 20 detects that one of the tickets of the list of non-validated tickets has been selected.
Once a ticket of the list of non-validated tickets has been selected, the application validates this ticket in a step 2026.
In one embodiment, as described with reference to the purchase of a validated ticket, the above operation of validation is linked to the position of the user. For this reason, the application can detect (in a step 2028) information that enables identification of the position of the user at the moment of validation of the ticket (see also step 2014 described previously).
Consequently, once the position of the user or the code that identifies the position of the user has been detected, the application 20 validates the ticket.
For instance, the application can send (in a step 2030) an electronic message to the server of the vendor 1 that notifies the fact that a ticket (identified via the respective unique code or a code that identifies the type of the ticket to be validated) has been validated, where the application 20 may preferably send to the server of the vendor 1 (in step 2030) also the position and/or the unique code that identifies the position of the user.
Next, the server of the vendor 1 processes the message and confirms validation by sending a confirmation message.
Consequently, in a step 2032, the application 20 can receive the message of confirmation of validation from the server of the vendor 1. For instance, the confirmation message may be an SMS message, and the message may contain a unique code that identifies the validated ticket.
In various embodiments, in the case where the list of non-validated tickets TNV is stored in the application 20, the application 20 can identify the ticket as validated, for example by removing the ticket from the list of non-validated tickets TNV, and store the validated ticket in a list of validated tickets TV. The application can also store the position and/or the unique code that identifies the position of the user in the list of validated tickets. Furthermore, the application could also save the message of confirmation of validation in the aforesaid list TV and associate it to the respective validated ticket.
Finally, the application 20 can inform the user that the ticket has been validated, for example via a visual and/or acoustic effect (step 2036), and return to the initial screenful, i.e., to step 2002.
Consequently, in general, the application 20 installed on the user's mobile device 2 makes it possible to request issue of an electronic ticket, namely:

to purchase a ticket already validated; and/or
to purchase a non-validated ticket that is validated subsequently.

The inventor has noted that the solutions described previously provides an insufficient solution to the problem of issuing a ticket for public transport, above all as regards the possibility of verifying the authenticity of the validated tickets by the ticket-collecting staff.
As mentioned previously, typically a unique code identifies a specific validated ticket and its validity (start, duration and/or end of validity). This unique code is saved in a list of validated tickets TV, which is in turn stored in the application 20 of the mobile device 2 and/or in a data base of the server of the vendor 1.
However, the list stored in the application 20 is not reliable because a counterfeit application could display a similar screenful. Instead, to gain access to the list stored in the data base of the server of the vendor 1, each ticket collector should have his own mobile device with a data connection enabled.
Furthermore, whereas validation of a traditional ticket is only possible through mechanical/electronic validators fixed in given places, validation by means of the mobile device 2 can be requested at any moment. Consequently, a user could get on a public means of transport and request issue of a ticket only when a check is in progress.
Figure 6 shows a possible embodiment of an architecture according to the present description.
As before, installed on the mobile device 2 is an application 20 that enables request for issue of an electronic ticket. For this purpose, the mobile device 2 communicates, as before, with the server of the vendor 1, and possibly with the payment-management system 4, to request issue of a validated ticket (see, for example, Figures 3 and 5).
However, in the embodiment considered, each ticket collector or group of ticket collectors has a respective mobile device 4, such as for example a cellphone. In various embodiments, the above mobile device 4 is used only for communicating start and end of a check on a given public means of transport. Consequently, when a check is in progress on the passengers to see whether they are in possession of a ticket, the subject responsible for carrying out the check communicates, through the mobile device 4, start of the check and provides references on the means of transport on which the check is in progress (for example the number of the bus and the bus stop).
In general, these communications by the ticket collector may be made in different ways, which prevalently depend upon the characteristics of the device 4.
For instance, in one embodiment, the ticket collector makes, via the device 4, a call to a so-called "Interactive Voice Response" (IVR) system, where the ticket collector can communicate start and end of a check by sending DTMF (Dual-Tone Multi-Frequency) signals via the keypad of the mobile device.
In one embodiment, the ticket collector can make a so-called "drop call", where he calls a specific telephone number that indicates, for example, the number of the bus stop.
In one embodiment, the ticket collector can send to the server of the vendor 1 an electronic message, for example an SMS message or a data flow that is managed via a dedicated application or a web browser installed on the device 4.
As mentioned previously, the ticket collector also supplies references on the unit on which check is in progress. In general, these references regarding the unit on which check is in progress can be typed directly by the person responsible for making the check and/or be detected at least partially in an automatic way. In general, it is possible to use all the systems that have been described with reference to Figures 3 and 5 (steps 2014 and 2028) for detecting the position of a user, such as for example the GPS position or detection of a bar code via the camera of the mobile device 4. For instance, the position of the mobile device 4, i.e., of the ticket collector, could be detected automatically and the line number could be entered manually.
Consequently, at the end of the procedure, the server of the vendor 1 receives an electronic message that contains information identifying the start of the check and the unit on which the check is in progress. This information can also be combined with other information regarding the public means of transport, for example, with the data coming from a so-called "Automatic Vehicle Monitoring" (AVM) system that monitors the positions of the public means of transport. For instance, the server of the vendor 1 can determine the means of transport that will be checked on the basis of the position of the ticket collector (and/or the stop indicated by the ticket collector), the number of the line indicated by the ticket collector, and the positions of the means that form part of the line.
In the embodiment considered, the server of the vendor 1 stores the above information in a data base 10.
In a similar way, once the check has been made, the server of the vendor 1 receives an electronic message that contains information identifying end of the check. Also in this case, the server of the vendor 1 stores this information in the data base 10.
The person skilled in the art will appreciate that this information can be stored in different ways in the data base 10. For instance, in one embodiment, the server of the vendor 1 stores consecutively all the checks made in the data base 10, in which a new data element is created when a ticket collector communicates start of a check. For instance, this data element could comprise information that enables identification of the number of the ticket collector, the time of start of the check, the means of transport on which the check is in progress and, once end of the check has been communicated, the time of end of check.
Instead, in another embodiment, the server of the vendor 1 can associate to each ticket collector a data element, in which:

when start of a check is communicated, the server of the vendor 1 stores in the data element associated to the respective ticket collector the time of start of the check and the means of transport on which the check is in progress; and
when end of a check is communicated, the server of the vendor 1 identifies the check as being completed, for example storing the time of end of the check or erasing the contents of the data element.

Consequently, in general, the data base 10 contains information that enables identification of all the checks that are in progress. Preferably, these data enable identification also of the means of transport that are undergoing a check and start of the respective check and preferably also the number of the ticket collector who has communicated the check.
Consequently, the information stored in the data base 10 can be used during issue and verification of a ticket.
For instance, Figure 7 shows a flowchart of a possible embodiment of the application installed on the server of the vendor 1 that is responsible for issuing a ticket.
Once the mobile device 2 has sent a request for issuing an electronic ticket, i.e., a request for purchase of a validated ticket (see, for example, step 2016 of Figure 3) or a request for validation of a non-validated ticket (see, for example, step 2030 of Figure 5), the vendor's application receives this request in a step 1002. In particular, as described previously, this request contains data that enable identification of the position of the user at the moment of purchase or validation, such as for example the GPS position or the number of the stop.
In a step 1004, the application of the vendor 1 accesses the data base 10 and detects the checks that are currently active in the vicinity of the user. In fact, as mentioned previously, the data base 10 comprises information that indicates the positions of the ticket collectors that are currently making a check. In this way, by correlating the information on the position of the user and on the position of the ticket collectors, the application of the vendor 1 can determine whether the user 2 is attempting to purchase or validate a ticket only when the check has already started.
For example, in the case where the user communicates only a position that identifies a point, such as a GPS position or a number of a stop that in turn identifies a specific position, the application can compare the position of the user directly with the positions of the checks. For instance, the application of the vendor 1 could detect (in step 1004) all the active checks within a predetermined radius around the position of the user.
In addition or as an alternative, the application can also take into consideration information on the public-transport network, in particular with reference to the public means of transport that circulate on the network. In fact, typically each means or vehicle is identified via a unique number, and the route of each means and its position is typically well known through an AVM system.
For instance, in one embodiment, the application can determine, in a step 1042, the means of transport used by the user. For example, as mentioned previously, the above number could be encoded within a two-dimensional bar code that could be detected via the mobile device 2 during validation. Instead, in the case where this information is not directly available, the application of the vendor 1 could even just estimate the most likely means of transport. For instance, in the case where the user has sent his position, for example a GPS position or the number of a stop (i.e., a unique number that identifies a specific stop within the network), the application of the vendor 1 can determine all the means that pass or will pass shortly through this position or stop.
In a similar way, also the number of a means undergoing a check can be determined in a step 1044 as a function of the data that are communicated by the ticket collectors. For instance, in one embodiment, the ticket collector transmits the number of the line on which a check will be carried out and his position, identified, for example, by the number of a stop. In fact, knowing the route and the positions of the public means of transport that are available via the AVM system, the application of the vendor 1 can determine the means of a given line that is arriving at a given stop.
Consequently, knowing the means that are undergoing a check and knowing the means that the user has taken or the means that the user could take, the application of the vendor 1 can detect (in a step 1046) only the data elements in the data base 10 that correspond to means undergoing checks that are potentially relevant for the user.
In a verification step 1006, the vendor's application verifies whether at least one data element has been found in step 1004.
In the case where no data element has been found (output "N" from the verification step 1006), the application issues the ticket, as before, in a step 1008. For instance, in the case where the user requests purchase of a validated ticket, the application of the vendor 1 can return a unique code that identifies the above electronic ticket. Instead, in the case where the user requests validation of a ticket, typically identified via a unique code, the server of the vendor 1 can verify whether the user 2 has previously purchased a ticket, for example by verifying the unique code that identifies the ticket, record the ticket as validated, and send to the user a confirmation message "OK1".
Instead, in the case where at least one data element has been found in the data base 10 (output "Y" from the verification step 1006), the application can answer in different ways.
In the embodiment considered, the application of the vendor 1 verifies (in a step 1010) whether the user has communicated information that uniquely enables identification of a specific means, or in general just one means. For instance, in the case where the user explicitly communicates the number of the means that he has taken (for example via detection of a QR code that identifies the means), this number intrinsically identifies a specific means. However, also in the case where the user has communicated only a position, for example a GPS position or the number of a stop, the application could determine, through the information supplied by the AVM system, that in this position or at this stop just one means will pass in a certain time interval, for example in the next five minutes. Consequently, in this case step 1042 would supply just one number of a means of transport.
Consequently, since also the ticket collector communicates data that typically enable identification of just one means, the application of the vendor 1 can be certain that the user 2 is trying to validate a ticket on a means where a check is in progress. In general, the application of the vendor 1 could also verify (in step 1010) whether the information communicated by the ticket collector enables identification of just one means; for example, the application can verify whether just one means has been detected in step 1044.
Consequently, in the case where the user has communicated information that enables identification of just one means (output "Y" from the verification step 1010), for example in the case where just one means has been detected in step 1042, the application of the vendor 1 can inhibit issue or validation of the ticket. For example, in the embodiment considered, the application sends (in a step 1014) an electronic error message "ERR1" to the mobile device 2, such as an SMS message or a data flow that is handled via the application 20 installed on the device 2 of the user.
In one embodiment, the application of the vendor 1 can also take into consideration the time that has elapsed between communication of start of check by the ticket collector and the request for purchase/validation by the user. In fact, typically the ticket collector communicates start of a check before getting on the respective means.
For instance, in one embodiment, the application of the vendor 1 verifies (in a verification step 1012) whether the time that has elapsed between communication of the start of check and the request for issuing the electronic ticket is longer than a given threshold, which may for example be between 5 and 30 seconds, preferably between 10 and 15 seconds.
Consequently, in the embodiment considered, the application of the vendor 1 refuses to issue or validate a ticket (step 1014) only in the case where the time that has elapsed exceeds the threshold (output "Y" from the verification step 1012).
Instead, in the case where the time that has elapsed is less than the threshold (output "N" from the verification step 1012), probably the check has not yet started. In this case, the application of the vendor 1 can issue or validate the ticket in a step 1016 and send an electronic confirmation message "OK2" to the user's mobile device 2.
In one embodiment, the application of the vendor 1 can also manage two thresholds: a lower threshold and an upper threshold. In this case, the application can refuse issue/validation (in step 1014) if the time that has elapsed is longer than the upper threshold and confirm issue/validation (in step 1016) if the time that has elapsed is shorter than the lower threshold. Instead, in the case where the time that has elapsed is shorter than the upper threshold and longer than the lower threshold (output "W" from the verification step 1012), the application could go to a step 1018. In particular, in the embodiment considered, the application of the vendor 1 issues/validates the ticket and sends an electronic confirmation message "OK3" to the user's mobile device 2. However, in this case, the application associates some additional information to the electronic ticket. For instance, in one embodiment the application stores for this ticket at least:

data identifying the check that has been detected, such as for example the number of the ticket collector that has communicated start of the respective check and preferably also the time of start of check; and
data identifying the time of issue/validation of the electronic ticket.

The person skilled in the art will appreciate that this information regarding the electronic tickets can be saved in an appropriate data base, such as for example the data base 10, in which the codes and data of all the electronic tickets issued are stored.
In general, the step 1012 is only optional, and the application of the vendor 1 could always carry out just the step 1014 or just the step 1018. Furthermore, in the case where only one threshold is envisaged, the application could carry out the step 1018 instead of the step 1014 or of the step 1016.
Instead, in the case where the application is not able to identify a single means of transport for the user and/or the ticket collector (output "N" from the verification step 1010), the application of the vendor 1 issues/validates (in a step 1020) the ticket and sends an electronic confirmation message "OK4" to the user's mobile device 2. However, also in this case, the application associates additional information to the ticket (see the description of step 1018).
In general, also in this case the application could refuse issue/validation of the ticket, as occurs in step 1014. However, this is not preferable because the user could try to purchase/validate a ticket for a means that is not undergoing a check.
Finally, following upon steps 1008, 1014, 1016, 1018 or 1020, the procedure of issue/validation of the ticket terminates and the procedure continues in step 2018 of Figure 3 or step 2032 of Figure 5.
Consequently, in the embodiment considered, step 1014 activates a block for issuing tickets for those requests coming from users that have got on means where, at that precise moment, a check of the tickets is in progress, and the user receives an error message on account of the check being in progress.
Instead, in steps 1018 and 1020 operativeness of the platform in terms of issue of tickets is left intact but, as compared to the standard situation (step 1008), it is notified that the ticket has been purchased after declaration of start of check by the person responsible for ticket collection, adding further data/information similar to a token that identify the fact that a check was in progress. In various embodiments, this information identifies all the means that are undergoing a check detected in step 1004, i.e., the respective numbers of the means, and/or other information identifying the respective checks, such as for example the code of the ticket collector and/or code of the driver. The person skilled in the art will appreciate that this information of verification, which the user cannot know but which is known by the computer ticket-vending system and by the staff responsible for carrying out checks, enables a visual check to be made by the staff responsible for ticket collection that is extremely reliable and effective.
When it is necessary to check the ticket, the person responsible for carrying out the check (who may, for example, be a ticket collector during a random check or a driver who has the function of checking all the tickets of the users as the latter are getting on the means of transport through the front door) can ask the user to show his electronic ticket on the user device 2.
Figure 8 shows a flowchart of a possible embodiment of the application 20 installed on the user's mobile device 2. This flowchart is essentially based upon the flowcharts of Figures 3 and 5 and also comprises a ticket-checking modality. Consequently, description of the modalities of purchase ("BUY") and validation ("VALID") will not be repeated in so far as what has been described with reference to Figures 3 or 5 applies.
In this case, the screenful illustrated in step 2002 may comprise a further key 2418, for example with the wording "CONTROL", which makes it possible to check whether a ticket is valid (see Figure 4a).
Consequently, in the case where the ticket collector asks the user whether he can check a ticket that has been previously validated (output "CONTROL" from the verification step 2004), the user can select (in a step 2040) a valid ticket, for example using the list of validated tickets TV and a screenful similar to the one appearing in Figure 4b. The application can also automatically look for the last validated ticket in step 2040. For instance, in the case where the list of validated tickets TV is stored also locally, the application can retrieve the ticket from the list TV; otherwise, the application 20 can contact the server of the vendor 1 or request the information on the last validated ticket, possibly logging in using an identification code of the user and/or of the application.
Next, the application 20 can check the validity of the ticket in a step 2042. For instance, also in this case, the application can detect, in a step 2044, information that enables identification of the position of the user when the ticket is being checked (see, for example, the description of step 2014 of Figure 3). For instance, in one embodiment the application detects the GPS position of the user, or the application can connect up to the camera 22 of the mobile device 2 and processing the image for detection of a bar code 10 that identifies, for example, the means of transport.
In general, the device can also detect other information identifying in some way the position of the user or the means of transport on which a check is in progress, such as for example the code of the driver or the code of the ticket collector. For instance, the camera could also detect a bar code 10 that is printed on the badge of the ticket collector or another medium presented by the ticket collector. In fact, this code could identify uniquely a given ticket collector and hence a respective check, i.e., a data element in the data base 10.
Instead of automatic detection via sensors of the mobile device 2 there could also be provided a screenful in which manual entry of one of the codes mentioned previously is required, such as for example the code of the ticket collector, of the stop and/or of the means of transport.
Finally, to increase further the reliability of the check, there could also be envisaged use of a temporary security code, the so-called "One Time Password" (OTP), for example provided through an purposely provided "O-KEY" electronic device or via an application installed on the device 4 of the ticket collector. The ticket collector, at the moment of the check, thus generates the code and communicates it to the user who is being checked. The user enters it possibly together with the other information mentioned previously.
Next, the application 20 can send (in a step 2046) an electronic message to the server of the vendor 1, signalling the fact that a ticket has to be checked, and the server of the vendor 1 can process the message and send a message that confirms or refuses the check. For instance, the vendor 1 can verify whether the ticket continues to have characteristics of validity, for example, whether it is still within the period of validity. As mentioned previously, the application 20 preferably sends to the server of the vendor 1 (in step 2046) also the position and/or a code that identifies the means of transport where a check is in progress and possibly also a security code. Next, the vendor checks the data received, and the application 20 receives (in a step 2048) the electronic message that indicates the result of the check from the server of the vendor 1.
The application 20 can notify (in a step 2050) the result of the check also to the user, for example with visual and/or acoustic effects that are different in the two cases of confirmation and refusal of the check.
Finally, the application 20 can return to the initial screenful, i.e., to step 2002.
Figure 9 shows a flowchart of a possible embodiment of the application installed on the server of the vendor 1 that is responsible for checking an electronic ticket.
Once the mobile device 2 has sent all the verification data, the application of the vendor 1 receives (in a step 1202) the verification request. For instance, typically this request contains the unique code of a ticket previously validated. Furthermore, as described previously, the request contains information that enables identification of the means of transport on which a check is in progress and possibly a temporary security code.
In the embodiment considered, the application of the vendor 1 accesses the data base 10 to detect (in a step 1204) all the data elements that correspond to checks that are compatible with the data sent by the user. For instance, in the case where the mobile device 2 has sent the code of the ticket collector, the respective data element in the data base 10 can be retrieved directly. Instead, in the case where the user has sent only data identifying the means of transport on which a check is in progress, the vendor's application can use one of the procedures described with reference to step 1004 of Figure 7, in particular the steps 1042 and 1044.
Furthermore, the vendor's application can also verify whether the security code is right. In fact, once the data element that corresponds to the check communicated by the user has been identified in the data base and, consequently, also the identifier of the ticket collector that is in turn uniquely associated to a device that creates the respective security code, the application can verify immediately whether the temporary security code sent is right for that particular ticket collector. For instance, in the case where the security code is wrong, the application of the vendor 1 can reject the corresponding data element.
In a verification step 1206, the application of the vendor 1 verifies whether at least one data element has been found in step 1204.
In the case where no data element has been found (output "N" from the verification step 1206), the application returns an error message "ERR2" that indicates the fact that the verification cannot be completed.
Instead, in the case where at least one data element has been found (output "Y" from the verification step 1206), the application determines in a step 1210 the state of the electronic ticket indicated by the user, and the application verifies the state of the ticket in a verification step 1212.
In particular, in the case where the ticket has been correctly validated and is still valid (output "Y" from the verification step 1212), the application sends to the user's mobile device 2 an electronic message "OK5" that indicates the fact that the ticket is valid.
Instead, in the case where the ticket does not exist, has expired, or is not validated (output "N" from the verification step 1212), the application sends to the user's mobile device 2 an electronic message "ERR3" that indicates the fact that the ticket is not valid.
Finally, as described with reference to steps 1018 and 1020, the application that manages issue/validation of the tickets can associate some additional information to a ticket if issue/validation has been carried out while a check was in progress. Consequently, in the case where the ticket is valid and this additional information is also associated to the ticket (output "W" from the verification step 1212), the application sends to the user's mobile device 2 an electronic message "WARN1" that indicates the fact that the ticket was validated while the check had already started. For instance, in one embodiment, the application in this case also sends:

data identifying the check that has been detected, such as for example the number of the ticket collector who has communicated start of the respective check and preferably also the time of start of check; and
data identifying the time of issue/validation of the ticket.

Consequently, on the basis of the data returned, the ticket collector is able to check the validity of the ticket directly on the user's mobile device.
To increase further the reliability of the result of the check displayed on the user's mobile device 2, it may also be envisaged that the vendor's server returns, at least for the steps 1214 and 1218, a token known only by the staff responsible for carrying out checks.
In general, this token may be a graphic, acoustic, and/or visual element, such as for example a word, a number, an alphanumeric sequence, an image, a sound, and/or a video sequence. Preferably, this element is displayed and/or reproduced on the mobile device 2 when the response is received from the server of the vendor 1, for example in step 2050.
For instance, in a currently preferred embodiment, the application of the vendor 1 returns the code of the ticket collector who is currently making the check for the position specified by the user. In the case where there are more than one checks in progress in the same area, the server could also return a number of ticket-collector codes. In general, the vehicle code could also be used, or else the driver code or some other dynamic datum not known to the user.
Consequently, the server of the vendor 1, thanks to the data sent by the mobile device 2, is able to identify the respective check and respond with a token that reliably certifies the ticket.
Of course, without prejudice to the principle of the invention, the details of construction and the embodiments may vary widely with respect to what has been described and illustrated herein purely by way of example, without thereby departing from the scope of the present invention, as defined by the ensuing claims.

Claims

A method for managing issue of an electronic ticket comprising the steps of:
- receiving from a first mobile device (2) an electronic message that contains data identifying a request for issuing an electronic ticket; and

- processing (1004) said data identifying a request for issuing an electronic ticket and verifying (1006, 1010, 1012) whether said electronic ticket can be issued;
characterized in that said data identifying a request for issuing an electronic ticket comprise data that enable identification of the position of the user who requests issue of said electronic ticket, and wherein said method comprises:

- receiving from at least one second mobile device (4) of a plurality of mobile devices (4) an electronic message that contains data identifying start or end of a check made by a person responsible for carrying out the check, wherein said data identifying the start of a check comprise data that enable identification of the position of the respective check;

- processing each electronic message that contains data identifying start or end of a check and saving in a data base (10) data that enable identification of the checks in progress and the positions of said checks in progress;

- processing (1004) said data that enable identification of the position of said user and said data saved in said data base (10) that enable identification of the positions of said checks in progress, and verifying (1006) whether said user who requests issue of said electronic ticket is in the vicinity of at least one of said checks in progress; and

- in the case where said user who requests issue of said electronic ticket is not in the vicinity of any of said checks in progress, sending (1008) to said first mobile device (2) an electronic message (OK1) that contains data indicating correct issuing of said electronic ticket.
The method according to Claim 1, comprising:
- in the case (1006) where said user who requests issue of said electronic ticket is in the vicinity of at least one of said checks in progress:
- sending (1014) to said first mobile device (2) an electronic message (ERR1) that contains data indicating refusal to issue said electronic ticket; or

- sending (1018) to said first mobile device (2) an electronic message (OK3, OK4) that contains data indicating correct issue of said electronic ticket, and saving, for said electronic ticket, additional data, wherein said additional data comprise data identifying said checks in progress that are in the vicinity of said user who requests issue of said electronic ticket.
The method according to Claim 1 or Claim 2, wherein said data that enable identification of the checks that are in progress comprise data that enable identification of the time of start of the respective check, and wherein the method comprises:
- in the case (1010) where said user who requests issue of said electronic ticket is in the vicinity of just one check in progress, determining (1012) the time that has elapsed between reception of said electronic message that contains data identifying a request for issue of an electronic ticket and the time of start of said single check in progress that is in the vicinity of said user; and

- according to (1012) said time that has elapsed:
- sending (1014) to said first mobile device (2) an electronic message (ERR1) that contains data indicating refusal to issue said electronic ticket;

- sending (1016) to said first mobile device (2) an electronic message (OK2) that contains data indicating correct issue of said electronic ticket; or

- sending (1018) to said first mobile device (2) an electronic message (OK3) that contains data indicating correct issue of said electronic ticket and saving, for said electronic ticket, additional data identifying said single check.
The method according to any one of the preceding claims, comprising:
- in the case (1010) where said user who requests issue of said electronic ticket is in the vicinity of a plurality of checks in progress:
- sending (1020) to said first mobile device (2) an electronic message (OK4) that contains data indicating correct issue of said electronic ticket, and saving, for said electronic ticket, additional data, wherein said additional data comprise data identifying said checks in progress that are in the vicinity of said user who requests issue of said electronic ticket.
The method according to any one of the preceding claims, wherein said step of processing (1004) said data that enable identification of the position of said user who requests issue of said electronic ticket and said data saved in said data base (10) that enable identification of the positions of said checks in progress comprises:
- processing (1042) said data that enable identification of the position of said user who requests issue of said electronic ticket for determining the means of transport that said user has taken or the means that said user could take; and

- processing (1044) said data saved in said data base (10) that enable identification of the positions of said checks in progress for determining the respective means of transport with check in progress or the respective means of transport where a check can be made.
The method according to Claim 5, wherein said step of verifying (1006) whether said user who requests issue of said electronic ticket is in the vicinity of at least one of said checks in progress comprises:
- determining (1046, 1006) whether said means of transport that said user has taken or at least one of said means of transport that said user could take corresponds to said means of transport where check is in progress or to at least one of said means where a check can be made.
The method according to any one of the preceding claims, comprising:
- receiving (1202) from said first mobile device (2) an electronic message that contains data identifying a request for checking an electronic ticket, wherein said data identifying a request for checking an electronic ticket comprise data that enable identification of the position of a user during a check;

- processing (1204) said data that enable identification of the position of said user during said check and said data saved in said data base (10) that enable identification of the positions of said checks in progress and verifying (1206) whether said user during said check is in the vicinity of at least one of said checks in progress; and

- in the case where said user during said check is in the vicinity of at least one of said checks in progress, determining (1210) the validity of said electronic ticket and sending (1214-1218) to said first mobile device (2) an electronic message (OK5, ERR3, WARN1) that contains data identifying the validity of said electronic ticket.
The method according to Claim 7, wherein said step of sending (1214-1218) to said first mobile device (2) an electronic message (OK5, ERR3, WARN1) that contains data identifying the validity of said electronic ticket comprises:
- verifying (1212) whether said additional data for said electronic ticket are saved; and

- in the case where said additional data for said electronic ticket are saved, sending (1218) to said first mobile device (2) said data identifying said checks that were in progress in the vicinity of said user at the moment of issue of said electronic ticket.
The method according to Claim 7 or Claim 8, comprising:
- receiving (1202) from said first mobile device (2) a temporary security code; and

- in the case where said user during said check is in the vicinity of at least one of said checks in progress, verifying (1204) whether said temporary security code is valid for at least one of said checks in progress that are in the vicinity of said user during said check.
The method according to any one of Claims 7 to 9, comprising:
- in the case where said electronic ticket is valid, sending (1214, 1218) to said first mobile device (2) an electronic message (OK5, WARN1) that contains a verification element, wherein said verification element may be a graphic, acoustic, and/or visual element, such as for example a word, a number, an alphanumeric sequence, an image, a sound, and/or a video sequence.
A system (1) for managing issue of an electronic ticket, characterized in that said system (1) is configured for implementing the method according to any one of Claims 1 to 10.
A computer program product that can be loaded into a memory of at least one computer and comprises portions of software code for implementing the method according to any one of Claims 1 to 10.