EP2924661A1 - Verfahren zum ausgeben eines elektronischen tickets und entsprechendes system - Google Patents

Verfahren zum ausgeben eines elektronischen tickets und entsprechendes system Download PDF

Info

Publication number
EP2924661A1
EP2924661A1 EP15160605.0A EP15160605A EP2924661A1 EP 2924661 A1 EP2924661 A1 EP 2924661A1 EP 15160605 A EP15160605 A EP 15160605A EP 2924661 A1 EP2924661 A1 EP 2924661A1
Authority
EP
European Patent Office
Prior art keywords
user
ticket
electronic ticket
check
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP15160605.0A
Other languages
English (en)
French (fr)
Inventor
Enrico Sponza
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Movincom Servizi SpA
Original Assignee
Movincom Servizi SpA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Movincom Servizi SpA filed Critical Movincom Servizi SpA
Publication of EP2924661A1 publication Critical patent/EP2924661A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points

Definitions

  • the present invention relates to techniques for issue and verification of an electronic ticket using mobile devices, such as for example cellphones.
  • Figure 1 shows a generic architecture of a purchasing system using mobile devices.
  • At least one dealer or, as referred to hereinafter, vendor 1 offers certain products or services and a user wishes to buy some of these products using his own mobile device 2.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • SMS Short Message Service
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the user has to authorise each payment via entry of a security code.
  • this mechanism may be useful for preventing payments in the case of theft of the mobile device 2 or undesired requests for payments.
  • the user could specify or receive this security code during subscription at the payment operator 3.
  • 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.
  • 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.
  • 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.
  • the document No. TO2011A000575 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.
  • the mobile device 2 detects, for example via a camera, a bar code that identifies a vendor 1 and a product/service sold.
  • 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.
  • 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.
  • the document No. TO2011A000861 describes a web-based solution, in which the user 2 selects the desired products on an Internet site of a vendor 1.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • a second mobile device such as the mobile device of a ticket collector
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the ticket collector is able to verify the validity of an electronic ticket directly on the user's device.
  • the system can receive from the mobile device of the user an electronic message that contains a request for checking an electronic ticket.
  • the request comprises data that enable identification of the position of the user.
  • 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.
  • the system could determine the validity of the electronic ticket and send the result of the check to the mobile device of the user.
  • 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.
  • 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.
  • Figure 2 shows a possible embodiment of an architecture according to the present description.
  • an application 20 that enables purchase of an electronic ticket, i.e., a ticket for access or entitlement to a good, amenity or service.
  • 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.
  • the application 20 displays in a step 2002 an initial page that enables selection of the operating mode of the application 20.
  • 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".
  • keys 2402 and 2406 with respective wordings "BUY" and "EXIT".
  • the key 2406 closes the application and consequently will not be described explicitly.
  • the application 20 can verify the choice of the user.
  • the application shows in a step 2008 the list of tickets that can be bought.
  • Figure 4b shows a possible screenful 24 of the page that enables selection of different tickets.
  • the screenful may comprise a ticket 2408 that shows the name ("NAME") and/or the logo of the vendor.
  • 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.
  • the keys 2410, 2412, and 2414 may correspond, respectively, to a single ticket, a weekly ticket, and a monthly ticket.
  • the page may also comprise a key 2414 that returns the user to the previous screenful.
  • the list of tickets that can be purchased is stored locally, i.e., directly in the application 20.
  • 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.
  • a remote server such as for example the server of a vendor 1 or a server of the management system 4.
  • the list is only stored on a remote server, and the application accesses this remote server.
  • 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.
  • the application shows in step 2006 a list of vendors, and the user can select one of the vendors.
  • the user can select one of the vendors.
  • substantially the same screenful as the one appearing in Figure 4b could be used also for selection of the vendor or vendors.
  • 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.
  • 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.
  • the user purchases the tickets selected.
  • 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.
  • 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.
  • 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 .
  • 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 ).
  • the ticket is a validated ticket.
  • 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:
  • 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.
  • 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.
  • the application 20 could even detect just a code that enables identification of the position of the user.
  • 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.
  • this code can be stored within a two-dimensional bar code, such as for example a QR code or a Datamatrix code 10.
  • 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.
  • 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.
  • 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.
  • a plurality of identical bar codes could be installed in the same place, for example in the same bus, or at the bus stop.
  • the application 20 sends, in step 2016, the request for purchase of the ticket to the vendor.
  • 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.
  • 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.
  • 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.
  • 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.
  • the application displays (in a step 2022) the list of tickets that the user has purchased previously and that have not yet been validated.
  • 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.
  • this list TNV could also be stored only remotely, for example on a server of the vendor 1.
  • 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.
  • 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.
  • 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.
  • the application validates this ticket in a step 2026.
  • 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).
  • the application 20 validates the ticket.
  • 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.
  • the server of the vendor 1 processes the message and confirms validation by sending a confirmation message.
  • the application 20 can receive the message of confirmation of validation from the server of the vendor 1.
  • the confirmation message may be an SMS message, and the message may contain a unique code that identifies the validated ticket.
  • 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.
  • the application could also save the message of confirmation of validation in the aforesaid list TV and associate it to the respective validated ticket.
  • 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.
  • the application 20 installed on the user's mobile device 2 makes it possible to request issue of an electronic ticket, namely:
  • 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.
  • each ticket collector should have his own mobile device with a data connection enabled.
  • 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.
  • the mobile device 2 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 ).
  • each ticket collector or group of ticket collectors has a respective mobile device 4, such as for example a cellphone.
  • 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).
  • these communications by the ticket collector may be made in different ways, which prevalently depend upon the characteristics of the device 4.
  • 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.
  • IVR Interactive Voice Response
  • 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.
  • 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.
  • 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.
  • the ticket collector also supplies references on the unit on which check is in progress.
  • 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.
  • 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.
  • 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.
  • AVM Automatic Vehicle Monitoring
  • 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.
  • the server of the vendor 1 stores the above information in a data base 10.
  • 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 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.
  • 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.
  • the server of the vendor 1 can associate to each ticket collector a data element, in which:
  • the data base 10 contains information that enables identification of all the checks that are in progress.
  • 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.
  • the information stored in the data base 10 can be used during issue and verification of a ticket.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the application can determine, in a step 1042, the means of transport used by the user.
  • the above number could be encoded within a two-dimensional bar code that could be detected via the mobile device 2 during validation.
  • 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.
  • 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.
  • 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.
  • a verification step 1006 the vendor's application verifies whether at least one data element has been found in step 1004.
  • the application issues the ticket, as before, in a step 1008.
  • the application of the vendor 1 can return a unique code that identifies the above electronic ticket.
  • 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".
  • the application can answer in different ways.
  • 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.
  • 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.
  • 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.
  • the application of the vendor 1 can inhibit issue or validation of the ticket.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the application of the vendor 1 can also manage two thresholds: a lower threshold and an upper threshold.
  • 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.
  • the application could go to a step 1018.
  • the application of the vendor 1 issues/validates the ticket and sends an electronic confirmation message "OK3" to the user's mobile device 2.
  • the application associates some additional information to the electronic ticket. For instance, in one embodiment the application stores for this ticket at least:
  • 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.
  • 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.
  • the application associates additional information to the ticket (see the description of step 1018).
  • the application could refuse issue/validation of the ticket, as occurs in step 1014.
  • this is not preferable because the user could try to purchase/validate a ticket for a means that is not undergoing a check.
  • 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.
  • step 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.
  • 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 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.
  • BUY modalities of purchase
  • VALID validation
  • 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 ).
  • 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.
  • the application 20 can check the validity of the ticket in a step 2042.
  • 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 ).
  • 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.
  • 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.
  • 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.
  • OTP One Time Password
  • 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.
  • 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.
  • 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.
  • 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.
  • the application of the vendor 1 receives (in a step 1202) the verification request.
  • this request contains the unique code of a ticket previously validated.
  • 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.
  • 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.
  • the vendor's application can also verify whether the security code is right.
  • 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.
  • a verification step 1206 the application of the vendor 1 verifies whether at least one data element has been found in step 1204.
  • 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.
  • the application sends to the user's mobile device 2 an electronic message "OK5" that indicates the fact that the ticket is valid.
  • the application sends to the user's mobile device 2 an electronic message "ERR3" that indicates the fact that the ticket is not valid.
  • 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:
  • the ticket collector is able to check the validity of the ticket directly on the user's mobile device.
  • 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.
  • 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.
  • 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.
  • 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.
  • the server could also return a number of ticket-collector codes.
  • the vehicle code could also be used, or else the driver code or some other dynamic datum not known to the user.
  • the server of the vendor 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
EP15160605.0A 2014-03-25 2015-03-24 Verfahren zum ausgeben eines elektronischen tickets und entsprechendes system Withdrawn EP2924661A1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ITTO20140245 2014-03-25

Publications (1)

Publication Number Publication Date
EP2924661A1 true EP2924661A1 (de) 2015-09-30

Family

ID=50943480

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15160605.0A Withdrawn EP2924661A1 (de) 2014-03-25 2015-03-24 Verfahren zum ausgeben eines elektronischen tickets und entsprechendes system

Country Status (1)

Country Link
EP (1) EP2924661A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3174014A1 (de) * 2015-11-30 2017-05-31 NCR Corporation Ortsbasierte ticketrücknahme
CN111539869A (zh) * 2019-12-04 2020-08-14 中国科学院信息工程研究所 一种车票请求方法和装置及计算机可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110153495A1 (en) * 2009-11-25 2011-06-23 Cubic Corporation Mobile wireless payment and access
US20120296828A1 (en) * 2011-03-11 2012-11-22 Bytemark, Inc. Method and System for Distributing Electronic Tickets with Visual Display
ITTO20110575A1 (it) 2011-06-30 2012-12-31 Movincom Servizi S P A Procedimento per autorizzare un pagamento tramite un dispositivo mobile, relativo procedimento per gestire un pagamento, dispositivo mobile, sistema per gestire un pagamento e prodotto informatico
US20130030964A1 (en) * 2011-07-26 2013-01-31 Ebay, Inc. Location-based payer charging system
ITTO20110861A1 (it) 2011-09-28 2013-03-29 Movincom Servizi S P A Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico
ITTO20130459A1 (it) 2013-06-04 2014-12-05 Movincom Servizi S P A Procedimento per acquisire e validare un titolo, relativo dispositivo mobile, sistema di pagamento e prodotto informatico

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110153495A1 (en) * 2009-11-25 2011-06-23 Cubic Corporation Mobile wireless payment and access
US20120296828A1 (en) * 2011-03-11 2012-11-22 Bytemark, Inc. Method and System for Distributing Electronic Tickets with Visual Display
ITTO20110575A1 (it) 2011-06-30 2012-12-31 Movincom Servizi S P A Procedimento per autorizzare un pagamento tramite un dispositivo mobile, relativo procedimento per gestire un pagamento, dispositivo mobile, sistema per gestire un pagamento e prodotto informatico
US20130030964A1 (en) * 2011-07-26 2013-01-31 Ebay, Inc. Location-based payer charging system
ITTO20110861A1 (it) 2011-09-28 2013-03-29 Movincom Servizi S P A Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico
EP2575098A1 (de) * 2011-09-28 2013-04-03 Movincom Servizi S.p.A. Verfahren zum Verwalten von Zahlungen zwischen einer Vielzahl von Händlern und einer Vielzahl von Benutzern, entsprechendes System zur Verwaltung von Zahlungen und Computerprogrammprodukt
ITTO20130459A1 (it) 2013-06-04 2014-12-05 Movincom Servizi S P A Procedimento per acquisire e validare un titolo, relativo dispositivo mobile, sistema di pagamento e prodotto informatico

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3174014A1 (de) * 2015-11-30 2017-05-31 NCR Corporation Ortsbasierte ticketrücknahme
US10990905B2 (en) 2015-11-30 2021-04-27 Ncr Corporation Location-based ticket redemption
CN111539869A (zh) * 2019-12-04 2020-08-14 中国科学院信息工程研究所 一种车票请求方法和装置及计算机可读存储介质
CN111539869B (zh) * 2019-12-04 2023-07-07 中国科学院信息工程研究所 一种车票请求方法和装置及计算机可读存储介质

Similar Documents

Publication Publication Date Title
US11024104B2 (en) Vehicle-based identification and access
JP6174116B2 (ja) 商品の供給のための装置
US10762733B2 (en) Method and system for electronic ticket validation using proximity detection
US8751395B2 (en) Verification methods for fraud prevention in money transfer receive transactions
US20120296818A1 (en) Method for authorizing the activation of a spending card
EP1772832A1 (de) Verfahren zur durchführung von sicheren zahlungen und inkassotransaktionen unter verwendung von programmierbaren mobiltelefonen
JP7525623B2 (ja) 無人販売機を用いた販売と購入仲介方法
EP1696626A1 (de) Vorrichtung und Verfahren zur Verbesserung der Sicherheit durch platzbasierte drahtlose Authentifizierung
CN101072384A (zh) 一种基于手机银行的手机支付方法及系统
TR201808160T4 (tr) Açık iletişim ağları üzerinden iletime yönelik ödeme verilerinin güvence altına alınmasına yönelik yöntem, cihaz ve sistem.
US20140344157A1 (en) Method and device for carrying out cashless payment
CN101588577A (zh) 用于银行交易系统的安全系统与方法
JP2009289063A (ja) 電子決済装置および電子決済方法
US20160125407A1 (en) Systems and Methods for Secure Remote Payments
EP1455317A2 (de) Verfahren zur Sicherung von Kartentransaktionen durch Verwendung eines mobilen Gerätes
WO2008015637A2 (en) Mobile payment method and system
WO2015008075A1 (en) Providing a new user with access to an account
EP2924661A1 (de) Verfahren zum ausgeben eines elektronischen tickets und entsprechendes system
KR20170139332A (ko) 결제를 처리하는 방법 및 시스템
US20120078752A1 (en) Transaction identified handling system
JP2004038843A (ja) 自動販売機システム
EP3175408A1 (de) Elektronisches bezahlsystem für kraftstoff
KR101772358B1 (ko) 결제수단 등록을 위한 타사 앱 자동 식별 방법
AU2015268598B2 (en) Method for avoiding the misuse of access authorisations of an ID-based access control system
KR20140089733A (ko) 결제 처리를 위한 제휴사 앱 인증 방법

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

17P Request for examination filed

Effective date: 20160325

RBV Designated contracting states (corrected)

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

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20180319