Open loop transit system with a backend system

Abstract

A backend system of an open loop transit system, includes at least one billing module configured to bill a completed trip at least based on a received start data set, a received end data set and a fixed preset tariff datum, wherein the start data set and the end data set each contains the same medium identification reference determined from the electronic medium identification of a ticket medium detected by at least one validator device and at least one transport information datum, at least one dynamic tariff determination module configured to determine a current tariff datum based on a requested trip datum and at least one tariff criterion, at least one output module configured to output the current tariff datum, and at least one storage module configured to store a journey data set containing the requested trip datum, the outputted current tariff datum and a medium identification reference.

Claims

1. A backend system (102, 303) of an open loop transit system (100), comprising: at least one billing module (110) configured to bill a completed trip at least based on a received start data set, a received end data set and a fixed preset tariff datum, wherein the start data set and the end data set each contains the same medium identification reference determined from the electronic medium identification of a ticket medium (124) detected by at least one validator device (126, 302) of the transit system (100) and at least one transport information datum; at least one dynamic tariff determination module (112) configured to determine a current tariff datum based on a requested trip datum and at least one tariff criterion, wherein the current tariff datum differs from the fixed preset tariff datum; at least one output module (106) configured to output a current tariff datum determined for the requested trip datum; and at least one storage module (114) configured to store a trip data set containing the requested trip datum, the outputted current tariff datum and a medium identification reference, upon receipt of a confirmation data set in response to the outputted current tariff datum for the requested trip datum, wherein the billing module (110) is configured to bill the requested trip datum, based on the stored trip data set at least upon detection of a use of the trip datum stored for the medium identification reference.

2. The backend system according to claim 1, wherein at least one transport information datum is selected from the group, comprising: a time stamp of the detection of the electronic medium identification by the validator device (126, 302), an identification of the validator device (126, 302), a location of the validator device (126, 302), an identification of a transit vehicle (122), an identification of a transit station (122), and/or the requested trip datum includes at least one trip datum selected from the group, comprising: a start location of the requested trip, a destination location of the requested trip, a calendar date of the requested trip, a start time point of the requested trip, an end time point of the requested trip, an identification assigned to a requested transit vehicle.

3. The backend system according to claim 1, further comprising: at least one receiving module (108) configured to receive a usage request from a user terminal (136), wherein the usage request comprises at least the requested trip datum, and/or to receiving a usage confirmation from a user terminal (136), comprising the confirmation data set.

4. The backend system according to claim 1, wherein the medium identification reference is a medium identification reference registered in the backend system, wherein a registered medium identification reference is stored in a user data set in the backend system, wherein the user data set comprises, in particular, at least one further user datum selected from the group, comprising a user name, address data of the user, a user password, billing data, trip tariff data, billing details, data of other payment media, a membership to a user group.

5. The backend system according to claim 1 further comprising: at least one assignment module (118) configured to assign a received end data set to a stored trip data set based on the respectively contained medium identification reference, and at least one check module (120) configured to check whether the at least one transport information datum of the end data set corresponds to the stored trip datum of the trip data set.

6. The backend system according to claim 5, wherein the billing module (110) is configured to bill the requested trip datum, based on the stored current tariff datum, only if the check module (120) determines that the at least one transport information datum corresponds to the stored trip datum.

7. The backend system according to claim 1, wherein the confirmation data set replaces the start data set.

8. The backend system according to claim 1, wherein the at least one tariff criterion is a time difference criterion, which indicates a dependency between a time difference and the current tariff datum, where the time difference is, in particular, the time difference between the time point of receipt of a usage request and a start time point of the requested trip datum.

9. The backend system according to claim 1, wherein the at least one tariff criterion is a transport utilization criterion, and wherein the transport utilization criterion indicates a dependency between a transport utilization of at least one transit vehicle of a requested trip datum and the current tariff datum.

10. The backend system according to claim 1, wherein the at least one tariff criterion is at least one meteorological criterion.

11. The backend system according to claim 1, wherein the at least one tariff criterion is at least one event criterion.

12. The backend system according to claim 1, further comprising: at least one blocking check module (152) configured to check whether an amount payable for the completed trip has been paid within a specific period of time, and at least one blocking module (154) configured to send a blocking message to the at least one validator device (126, 302) such that the use of the ticket medium (124) at the at least one validator device (126, 302) is blocked.

13. An open loop transit system (100), comprising: at least one backend system according to claim 1, and at least one validator device (126, 302) configured to detect an electronic start data set and/or end data set of a ticket medium (124) used for a trip.

14. The open loop transit system according to claim 13, further comprising: at least one service application (142, 301) installable on a user terminal (136), wherein the service application (142, 301) comprises at least one request module (144) configured to cause a sending of a usage request containing at least one requested trip datum, and/or wherein the service application (142, 301) comprises at least one receiving module (146) configured to receive an instantaneous tariff datum determined for the requested trip datum, and/or wherein the service application (142, 301) comprises at least a confirmation module (148) configured to cause a sending of a usage confirmation containing at least one confirmation data set.

15. A method for operating an open loop transit system comprising a backend system, the method comprising: determining, by a dynamic tariff determination module of the backend system, a current tariff datum based on a requested trip datum and on at least one tariff criterion; outputting, by at least one output module of the backend system, of the current tariff datum determined for the requested trip datum; upon receipt of the confirmation data set in response to the current tariff datum outputted for the requested trip datum: storing, by at least one storage module (114) of the backend system, a trip data set containing the outputted current tariff datum, the requested trip datum and a medium identification reference; and upon detection of a use of the trip datum stored for the medium identification reference: billing, by a billing module (110) of the backend system, of the requested trip datum, based on the stored trip data set.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0161] The drawings include:

[0162] FIG. 1 a schematic view of an embodiment of an open loop transit system according to the present application with an embodiment of a backend system according to the present application,

[0163] FIG. 2 a diagram of an embodiment of a method according to the present application, and

[0164] FIG. 3 a diagram of a further embodiment a method according to the present application.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

[0165] FIG. 1 shows a schematic view of an embodiment of an open loop transit system 100 (or a transit system 100 with an open loop ticket system) according to the present application with an embodiment of a backend system 102 according to the present application.

[0166] The presented transit system 100 comprises at least one backend system 102 and at least one validator device 126. In addition, the transit system 100 comprises at least one transit vehicle 122, in this example in the form of a bus 122. It shall be understood that a transit system 100 can, alternatively or additionally, comprise further and/or other transit vehicles (e.g. cable car, railroad vehicle, water vehicle etc.).

[0167] In this example, at least one validator device 126 is located in the transit vehicle 122. As can be seen, the at least one validator device 126 is located at an access 134 (e.g. entrance and/or exit) of the transit vehicle 122 to a paid area, preferably the interior of the transit vehicle 122. Preferably, at least one validator device 126 can be located at each access 134 of a transit vehicle 122. In other variants of the application, the validator device may also be located in a station or the like.

[0168] When operating the transit system 100, a user of transit vehicle 122 can log in (“check-in”) for an authorized trip when entering the transit vehicle 122. For this purpose, the user can bring his ticket medium 124, in particular, within reach of a ticket medium interface 128 of the validator device 126.

[0169] The at least one ticket medium interface 128 can be a contact or contactless ticket medium interface 128. It shall be understood that two or more ticket medium interfaces may be provided for a corresponding number of different ticket media.

[0170] In particular, the ticket medium interface 128 allows at least one electronic medium identification datum of the ticket medium 124 to be detected in the log in process. In this example, the ticket medium 124 is a credit card 124 with an ePAN stored in a data storage of the credit card 124. This can be detected via a (contact or contactless) interface of the ticket medium 124.

[0171] It goes without saying that in other variants of the application other ticket media can be used alternatively or additionally, as already described.

[0172] The validator device 126 may comprise at least one communication module 132 and/or be connectable to at least one (not shown) communication module of the vehicle infrastructure. The communication module 132 can at least be configured to transmit a medium identification reference of the detected electronic (unique) medium identification and at least one transport information datum, preferably together with further data, to the (central) backend system 102 of the transit system 100. In particular, a corresponding data set is transferred, such as a (previously described) start data set or end data set.

[0173] The at least one transport information datum of a start data set or end data set can, in particular, be a time stamp (e.g. calendar date and time of the detection time point) and/or at least one location information datum from which the location of the validator device (and the transit vehicle 122, respectively) can at least be derived during the detection of the electronic medium identification.

[0174] Optionally, the validator device 126 can comprise at least one local data storage 130. The at least one data storage 130 can store a list of blocked and unauthorized, respectively, medium identification references. When the electronic medium identification is detected, the medium identification reference can be calculated and compared to the stored and blocked medium identification references. If a correspondence (in particular, identity) is detected, the trip can be refused.

[0175] On a (not shown) display unit of the validator device 126 it can, alternatively or additionally, be indicated that the ticket medium 124 is not authorized for the regular use of the transit vehicle 122, likewise the validator device 126 can indicate the refusal of the trip with an acoustic signal.

[0176] In other variants of the application, an additional access device (e.g. a passage barrier) may be provided. This can only be released if it is determined during the matching process that the detected electronic medium identification is not a blocked medium identification.

[0177] When leaving the transit vehicle 122, the user can log out (“check-out”), in particular, in an analogous way to the log in process described above. In a corresponding manner, a validator device (e.g. the same validator device 126) can transmit at least the medium identification reference and at least one transport information datum, preferably together with the other data mentioned, to the backend system 102. In particular, a transmission of an end data set is conducted.

[0178] In the case of an inspection by an inspector, the inspector may use an inspection device (not shown) to retrieve, in particular receive, the medium identification references transmitted to the backend system 102 and use them for the inspection. In particular, the inspection device can check the ticket media by reading the respective medium identification, calculating the medium identification reference from it and comparing it with the medium identification references received from the backend system 102. If it is found that a user has not logged in and/or has a ticket medium with a blocked medium identification, the inspector can take known measures.

[0179] The backend system 102 can be formed by one or more (possibly distributed) arranged computing device/s. The backend system 102 comprises a plurality of modules. These can be at least partly formed as software modules and/or hardware modules.

[0180] As already described, a communication module 132 of the validator device 126 can exchange data with a communication module 104 of the backend system 102 (preferably bidirectional).

[0181] In addition, the backend system 102 comprises an output module 106 and a receiving module 108. In variants of the application, a common bidirectional communication module can also be provided.

[0182] The at least one receiving module 108 is, in particular, configured to receive a usage request and/or a usage confirmation from a user terminal 136. The usage request comprises at least the requested trip datum. The usage confirmation comprises at least the confirmation data set.

[0183] The output module 106 is at least configured to output a current tariff datum determined for the requested trip datum.

[0184] The current tariff datum is determined by the dynamic tariff determination module 112. The dynamic tariff determination module 112 is configured to determine a current tariff datum based on at least one tariff criterion and at least one requested trip datum. The current tariff datum differs from a fixed preset tariff datum.

[0185] Furthermore, at least one billing module 110 is implemented in the backend system 102. The billing module 110 is configured to bill a trip that has completed, at least based on a received start data set, a received end data set and a fixed preset tariff datum (in a conventional way).

[0186] In addition, the billing module 110 is configured, in accordance with the application, to bill the requested trip datum based on the stored trip data set, at least upon a detection of a use of the trip datum stored for the medium identification reference. In variants of the application, two billing modules for the different billing types can be provided.

[0187] The storing of the at least one trip data set is executed by a storage module 114. In particular, a trip data set can be stored by the storage module 114 in a data storage 116 of the backend system 102. The trip data set contains at least the current tariff datum, the requested trip datum (with at least one trip datum) and a medium identification reference belonging to the ticket medium with which the user will use the requested trip datum.

[0188] In particular, the storing is conducted upon receipt of a confirmation data set in response to the current tariff datum outputted for the requested trip. It is necessary that the response is received within a specific validity period. The validity period (start time is, in particular, the time of output of the current tariff datum) indicates how long the current tariff datum is valid. In particular, if a confirmation data set is received after the validity period has expired, no storing is performed. A message can be sent informing that the current tariff datum is no longer valid. Preferably, this message may also contain a new current tariff datum or a request for a further usage request.

[0189] Preferably, the at least one data storage 116 may contain a plurality of user data sets and user accounts, respectively, of registered users and registered medium identification references, respectively. In particular, the billing module 110 can access the stored user data of a user account for the purpose of performing a billing.

[0190] In the present embodiment, the backend system 102 comprises at least one assignment module 118 and at least one check module 120. In variants of the application, a common module may be provided.

[0191] The assignment module 118 is configured to assign a received end data set to a stored trip data set, based on the medium identification reference contained in each case. In particular, the assignment module 118 executes a corresponding comparison. If it is determined that a received medium identification reference of an end data set (and/or start data set) corresponds to a medium identification reference stored in a trip data set, in particular, is identical, the assignment module 118 assigns the corresponding data sets to each other.

[0192] Then the check module 120 checks whether the at least one transport information datum of the assigned end data set (and/or start data set) corresponds to the stored trip datum. This means, in particular, that it is checked whether a location information contained in the end data set or at least derived from it (e.g. from a validator identification or the like), in particular, a destination, corresponds to a location information contained in the trip datum, in particular, a destination. Accordingly, the detection time point of the end data set can be compared with the stored end time point of the requested trip. A start data set can be checked in an analogous way.

[0193] Preferably, billing can only be performed with the stored current tariff datum by the billing module 110 if the above-mentioned data correspond to each other.

[0194] Optionally, the backend system 102 also comprises a utilization determination module 150, a blocking check module 152 and/or a blocking module 154. The utilization determination module 150 can be configured to determine the predicted and/or actual utilization of a transit vehicle 122.

[0195] For example, in the backend system 102, a database with historical utilization data of transit vehicles can be available in at least one data storage 116. Based on the historical utilization data, the utilization determination module 150 can determine the utilization of a transit vehicle 122. AI (artificial intelligence) technology can be used here.

[0196] Alternatively or additionally, the utilization determination module 150 can preferably be configured to determine the utilization of a transit vehicle 122 based on the actual start data sets available for this transit vehicle 122, i.e. actual logins made by users. The utilization determination module 150 can know the transport capacity of the transit vehicle 122 (in particular, from a corresponding database of the backend system 102).

[0197] Preferably in addition, the determination of the utilization of transit vehicle 122 can be based on the stored trip data sets actually available for this transit vehicle 122.

[0198] The blocking check module 152 can be configured to check whether an amount due for the completed trip has been paid within a specific period of time. Alternatively or additionally, the blocking check module 152 can be configured to check, for example, by communicating with a payment service provider of a ticket medium 124, whether the balance of the account assigned to the medium identification reference meets a specific credit criterion (e.g. a specific amount). If it is determined that this is not the case or that the amount has not been paid within a specific period of time, a blocking module 154 may cause a sending of a blocking message to the at least one validator device 126 in such a way that the use of the ticket medium 124 at the at least one validator device 126 is blocked. Otherwise the use remains allowed.

[0199] Furthermore, the transit system 100 in the present case comprises a user terminal 136 in the form of a mobile terminal 136 with a communication module 138. The communication module 138 is at least configured to communicate with the output module 106 and the receiving module 108.

[0200] Presently, a service application 142 is installed on the mobile terminal 136 (e.g. a smartphone). In the shown example, the service application 142 comprises at least one request module 144 configured to send the described usage request containing at least the requested trip datum. In addition, the service application 142 comprises at least one receiving module 146 configured to receive the described current tariff datum. In addition, at least one confirmation module 148 is presently provided, which is configured to send the usage confirmation containing at least one confirmation data set.

[0201] Via a user interface (e.g. touch display or the like), the user can interact with the service application 142, for example, request a current tariff datum for a specific trip that can be specified by the service application 142. The outputted current tariff datum received by the service application 142 can be displayed to the user on a display of the mobile terminal 136 in such a way that the user can confirm acceptance of the displayed current tariff datum by a user action. Upon detection of a corresponding user action, the confirmation module 148 causes, in particular, the sending of a corresponding usage confirmation and confirmation data set, respectively.

[0202] As can further be seen, at least one (wireless and/or wired) communication network 140 can be provided to enable communication at least between the shown elements 102, 126, 136.

[0203] The functionality of the open loop transit system 100, according to FIG. 1, is described in more detail below with the aid of FIG. 2. FIG. 2 shows a diagram of an embodiment of a method according to the present application.

[0204] In a step 201, a determining, by the dynamic tariff determination module 112 of the backend system 102, of the current tariff datum occurs based on the requested trip datum and at least one tariff criterion. The tariff criterion is, in particular, a time difference criterion (cf. e.g. table 1) and/or a transport utilization criterion (cf. e.g. table 2) and/or a meteorological criterion (cf. e.g. table 3) and/or an event criterion (cf. e.g. table 4), as described above.

[0205] Depending on the at least one tariff criterion and the requested trip datum, i.e., in particular, a requested start time point, end time point, start location and destination location of the requested trip, a current tariff datum is determined, as described above.

[0206] In particular, a usage request can be received by the backend system 102 in a previous step. As already described, the request module 144 of a service application 142 can cause a transmission by the communication module 138 of the mobile device 136. In other variants of the application, also a web interface can be provided, over which a usage request can be requested to the dynamic tariff determination module 112.

[0207] In a step 202, an outputting, by the output module 108 of the backend system 102, of the current tariff datum occurs determined for the requested trip datum. For example, a corresponding message can be sent to communication module 138 and displayed on a screen of the mobile device 136, e.g. by the service application 142. In other variants of the application, the web interface can output the current tariff datum, in particular, display it on a screen.

[0208] In addition, in step 203, a storing, by the storage module 114 of the backend system 102, of a service data set occurs containing the current tariff datum, the requested trip datum and a medium identification reference (which may be contained in the usage request or the confirmation data set or may be determined from a user account (e.g. based on a user ID)).

[0209] Storing is done at least upon receipt of a confirmation data set in response to the current tariff datum outputted for the requested trip, as described above. It shall be understood that a part of this data can be stored even during or after the current tariff datum has been outputted and that if no confirmation data set is received within the validity period, this data can be deleted again. Storing a trip data set means, in particular, that this data set was previously confirmed by a confirmation data set.

[0210] It shall be also understood that step 202 can be performed several times until the user accepts (or finally rejects) an outputted current tariff datum. For a requested trip, a user can receive periodically updated fares until the user chooses the trip (i.e., accepts a current tariff datum) or discards the requested trip.

[0211] In the next step 204, a billing, by the billing module 110 of the backend system 102, of the requested trip datum occurs based on the stored trip data set. The billing is done at least whenever an actual use of the trip datum stored for the medium identification reference is detected.

[0212] A detection is performed, in particular, by obtaining and evaluating an end data set which contains a medium identification reference corresponding (in particular, is identical) to the stored medium identification reference and preferably a transport information datum corresponding to the stored trip datum, as described above.

[0213] Preferably, the confirmation data set can replace the start data set. In variants of the application, it may be additionally required for a billing with the current tariff datum that also a start data set is received, which contains a medium identification reference corresponding (in particular, is identical) to the stored medium identification reference and preferably a transport information datum corresponding to the stored trip datum.

[0214] FIG. 3 shows a diagram of a further embodiment of a method according to the present application. The reference number 301 refers to the service application and the mobile terminal, respectively, on which the service application is installed. Reference number 302 refers to the validator device, reference number 303 to the backend system and reference number 304 to a server system of a payment service provider (in particular, the provider of the ticket medium, for example, a credit card).

[0215] First of all, FIG. 3 shows an exemplary conventional use of the open loop transit system, as described in the application. The open loop transit system can, for example, be formed as shown in FIG. 1.

[0216] After a user logs in at a validator device 302, i.e., in particular, after a detection of the electronic medium identification by the validator device 302, the validator device 302 transmits a start data set in step 305 to the backend system 303. The start data set contains, in particular, the medium identification reference of the detected electronic medium identification, a time stamp of the detection of the electronic medium identification by the validator device 302 and a location information (e.g. geographic coordinates, validator identification, etc.). This data set can be stored in the backend system 303.

[0217] Optionally, in step 306, the backend system 303 can inquire the payment service provider 304 whether the account assigned to the received medium identification reference meets at least one specific credit criterion (e.g. a credit limit), as described above.

[0218] After a check by the payment service provider 304, it sends the response (criterion fulfilled or not) back to the backend system 303 in step 307. If the criterion is not met, a blocking message can be sent in step 308 to the at least one validator device 302, in particular, in order to block the ticket medium for use in the transit system. If the criterion is met, this step is omitted.

[0219] After the user logs off ata (further) validator device 302, i.e. in particular, after the electronic medium identification has been detected by the validator device 302, the validator device 302 transmits an end data set to the backend system 303 in step 309. The end data set contains, in particular, the medium identification reference of the detected electronic medium identification, a time stamp of the detection of the electronic medium identification by the validator device 302 (which may differ from the previous validator device) and a location information (e.g. geographic coordinates, validator identification etc.).

[0220] In step 310 (in particular at the end of the day), a billing, by the billing module, of at least one trip performed by the user occurs. Depending on the medium identification reference, the respective start and end data sets belonging to each other can be assigned to each other. Subsequently, a billing data set can be created using the time and/or location information of these data sets as well as a fixed (unchangeable) tariff datum. This can be outputted to the user.

[0221] In the following, the method according to the application is described in more detail, in which a dynamic “pricing” takes place in the open loop transit system.

[0222] For example, after starting a service application 301 on a user terminal (or after the user terminal accesses a web interface of the backend system 303), a usage request is sent to the backend system 303 in step 311. The usage request contains at least one requested trip datum, i.e., in particular, a start time point, end time point, start location and destination location of the requested trip. It shall be understood that additional or different trip data and/or further or other data (e.g. user identification, medium identification reference, identification of the trip and/or a transit vehicle, etc.) may be included. It shall be further understood that the service application 301 can retrieve timetable data from the backend system 303 (not shown in FIG. 3) in order to generate a usage request.

[0223] In step 312, the dynamic tariff determination module of the backend system 303 determines a current tariff datum, in particular, based on the data content of the received usage request and at least one tariff criterion (cf. e.g. the description to tables 1, 2, 3 and/or 4).

[0224] In step 313, the specific current tariff datum is outputted by transmitting it to the requesting user terminal and service application 301, respectively. A timer can be started at the same time. Thus, the current tariff datum is only valid for a specific period of time. After this (validity) period, i.e. after the timer has expired, the current tariff datum is invalid. For example, a new usage request can then be sent to initiate a new determination.

[0225] If the user does not agree with the received current tariff datum, the user can (e.g. after a specific period of time) submit a new usage request (step 314). Then (step 315), a current tariff datum can be determined again, as described above.

[0226] This may be different from the previous current tariff datum, for example, due to a change in the utilization determined by a utilization determination module and/or a change in the predicted meteorological condition and/or a change in the date of the requested trip (e.g. different times).

[0227] In step 316, an outputting of the determined current tariff datum takes place in an analogous way to step 313.

[0228] The service application 301 can also be configured to periodically and automatically submit a new usage request with the same trip datum (step 314) as before, so that a new current tariff datum is periodically determined for a usage request submitted by the user (step 315) and outputted to service application 301 (step 316) until the user accepts the current tariff datum received or rejects the request. Alternatively, the backend system 303 can be configured to automatically determine a new current tariff datum periodically (step 315) and output it to the service application 301 (step 316) until the user accepts the received current tariff datum or rejects the request.

[0229] If the user accepts the received current tariff datum, he can confirm it by a user action. If a corresponding user action is detected, the service application 301 causes transmitting of a confirmation data set (step 317), which at least indicates that the outputted current tariff datum is accepted for the requested trip. It goes without saying that additional or other data (e.g. user identification, medium identification reference, etc.) may be included.

[0230] Assuming that the validity period has not yet expired, in step 318, a storing takes place, by the backend system 303, of a trip data set containing at least the requested trip datum, the medium identification reference (with which the requested trip is to be used) and the confirmed current tariff datum.

[0231] Optionally, the backend system 303 can send to the server system 304 an authorization request about the stored current tariff datum (step 319) to effect a payment authorization of the amount due for the use according to the current tariff datum. This can be done, in particular, if a specific limit amount (e.g. 50 €) is exceeded.

[0232] After a payment authorization, the server system 304 sends a corresponding confirmation to the backend system 303 in step 320. It shall be understood that an authorization request can also be made before the corresponding trip data set is stored. In particular, it shall be understood that the process can be cancelled if an authorization fails.

[0233] In this embodiment, the confirmation data set preferably replaces the start data set. In other variants of the application, a start data set can also be taken into account and, in particular, a corresponding log in (“check-in”) at a validator device can be detected and evaluated.

[0234] In step 321, the validator device 302 transmits an end data set to the backend system 303 after the user has logged off (“check-out”) at the validator device 302, i.e., in particular, after the electronic medium identification has been detected by the validator device 302. The end data set contains, in particular, the medium identification reference of the detected electronic medium identification, a time stamp of the detection of the electronic medium identification by the validator device 302 (which may differ from the previous validator device) and a location information of the validator device 302 (e.g. geographic coordinates, validator identification etc.).

[0235] In step 322, at first an assigning occurs of the received end data set to a stored trip data set based on the medium identification reference. After a check by a check module on the basis of the received and stored data whether the trip was completed as requested by the user, a billing is made if the test result is positive, i.e. if it is determined that the trip was completed as requested by the user. The billing module of the backend system 303, in particular, executes a billing of the requested trip datum based on the stored trip data set, i.e., in particular, the stored current tariff datum.

[0236] If a deviation is found during the check (for example, in the destination location and/or end time point), a billing can be made according to at least one specific rule.

[0237] For example, the rule can specify that billing must then be performed according to the fixed preset tariff datum.

[0238] It goes without saying that some of the described steps can also be performed in a different order or at least partly in parallel.

[0239] In principle, the dynamic “pricing” method according to the application can also be applied to a transit system in which a paid area does not include a validator device, but rather a determination of whether a user is within a paid area occurs (exclusively) using the mobile device (or its sensors (GPS sensor, Bluetooth sensor, acceleration sensor, etc.)).