Backend System for a Passenger Transport System

Abstract

A backend system for a passenger transport system includes: data memory for storing at least one user data set containing at least one electronic medium identifier authorizing the execution of a transport trip and at least one first transport usage condition linked to the electronic medium identifier; a receiving module configured to receive a change data set containing at least one second transport usage condition, at least one first time date and at least one user identifier for identifying a stored user data set; a change module configured to change the linkage between the electronic medium identifier stored in the identified user data set and the first transport usage condition for at least one future transport trip; a trip reconstruction module configured to reconstruct an executed transport trip at least based on a received user identifier; and a generation module configured to generate a billing data set.

Claims

1. A backend system for a passenger transport system, comprising: at least one data memory configured to store at least one user data set, containing at least one electronic medium identifier authorizing the execution of a transport trip and at least one first transport usage condition linked to the electronic medium identifier, at least one receiving module configured to receive a change data set generated by an interface device of the passenger transport system, the change data set containing at least one second transport usage condition, at least one first time date, and at least one user identifier for identifying a stored user data set, at least one change module configured to change the linkage between the electronic medium identifier stored in the identified user data set and the first transport usage condition for at least one future transport trip based on the received second transport usage condition, at least one trip reconstruction module configured to reconstruct an executed transport trip based at least on a check-in data set received from a validator device of the passenger transport system containing at least one electronic medium identifier and a provided check-out data set containing at least the same electronic medium identifier, and at least one generation module configured to generate a billing data set at least based on the reconstructed transport trip and the transport usage condition of the user data set linked to the electronic medium identifier.

2. The backend system according to claim 1, wherein the backend system comprises a transmitting module configured to transmit a change message about the at least one second transport usage condition to the interface device after a change of the linkage, and/or the backend system comprises a transmitting module configured to transmit a change message about the at least one second transport usage condition to a communication address stored in the identified user data set after a change of the linkage.

3. The backend system according to claim 1, wherein the change data set contains at least one second time date indicating a validity time duration of the second transport usage condition, wherein the backend system comprises at least one time module configured to set a timer according to the second time date, and wherein the change module is configured to change the linkage between the electronic medium identifier stored in the identified user data set and the second transport usage condition upon detection of an expiration of the timer based on the first transport usage condition.

4. The backend system according to claim 1, wherein the change data set contains at least one trip number indicating the number of trips for which the second transport usage condition is valid, wherein the backend system comprises at least one counter module configured to set a counter corresponding to the number of trips, and wherein the change module is configured to change the linkage between the electronic medium identifier stored in the identified user data set and the second transport usage condition upon detection of an expiration of the counter based on the first transport usage condition.

5. The backend system according to claim 1, wherein the backend system comprises a transmitting module configured to transmit a received change data set to at least one further interface device of the passenger transport system after a change of the linkage.

6. An interface device for a passenger transport system, wherein the interface device is arrangeable in a passenger transport vehicle and/or in a transport stop area, comprising: at least one detection module configured to detect an electronic medium identifier of a ticket medium, wherein the electronic medium identifier is an electronic medium identifier authorizing the execution of a transport trip and linked to a first transport usage condition, at least one sensing module configured to detect a second transport usage condition determined by means of a user interface of the interface device and linkable to the detected medium identifier, at least one linking module configured to link a detected electronic medium identifier to the determined second transport usage condition, at least one generation module configured to generate a change data set containing the detected electronic medium identifier, the second transport usage condition linked with the detected electronic medium identifier, and at least one first time date, and at least one transmitting module configured to transmit the generated change data set to a backend system of the passenger transport system.

7. The interface device according to claim 6, wherein the interface device is a validator device.

8. The interface device according to claim 7, wherein the interface device comprises a checking module configured to check an admissibility of the detected electronic medium identifier based on a comparison of the detected electronic medium identifier with a plurality of electronic medium identifiers stored in a negative list, and the interface device comprises a release module configured to release a passing through the interface device if the detected electronic medium identifier is a permissible electronic medium identifier, wherein the release module is configured to block a passing through the interface device if the detected electronic medium identifier is a non-permissible electronic medium identifier.

9. The interface device according to claim 6, wherein the interface device comprises a receiving module configured to receive a change data set from a further interface device of the passenger transport system and/or from the backend system, the interface device comprises a data memory configured to store the received change data set, the interface device comprises a checking module configured to check the admissibility of the detected electronic medium identifier based on a comparison of the detected electronic medium identifier with the electronic medium identifier of the stored change data set, and the interface device comprises a release module configured to release a passing through the interface device if the detected electronic medium identifier corresponds to the stored electronic medium identifier.

10. The interface device according to claim 6, wherein the interface device comprises a data memory configured to store the change data set and/or a check-in data set, wherein the data memory is configured to provide the change data set and/or a check-in data set such that the change data set and/or a check-in data set is receivable by an inspection device via a data network.

11. A passage barrier for a passenger transport system comprising: an interface device according to claim 6, at least one blocking element movable between a blocking position and a release position, and at least one control module configured to control a moving of the blocking element between the blocking position and the release position.

12. The passage barrier according to claim 11, wherein the control module is configured to control a moving of the blocking element between the blocking position and the release position based on the transport usage condition associated with the detected electronic medium identifier.

13. The passage barrier according to claim 12, wherein the control module is configured to hold the blocking element in the release position for a release time duration, where the length of the release time duration is based on the transport usage condition linked with the detected electronic medium identifier.

14. The passage barrier according to claim 12, wherein the passage barrier comprises at least one sensor configured to detect a passage through the passage barrier in the release position of the barrier element, wherein the transport usage condition specifies as the scope of validity of a single electronic medium identifier detected by the interface device a specific number nN of users, and the control module is configured to move the blocking element from the release position to the blocking position upon detection of a number nP of passages corresponding to the specified number nN of users.

15. The passage barrier according to claim 14, wherein the passage barrier comprises at least one timer that can be started after each detected passage, and the control module is configured to move the blocking element from the release position to the blocking position upon an expiration of the timer.

16. A passenger transport system having at least one backend system according to claim 1, the passenger transport system comprising: at least one interface device, wherein the interface device is configured to detect an electronic medium identifier of a ticket medium and/or a user identifier for identifying a stored user data set, wherein the interface device is configured to detect a transport usage condition determined by means of a user interface of the interface device, wherein the interface device is configured to generate a change data set containing at least the detected electronic medium identifier and/or user identifier, the determined transport usage condition, and at least one first time date, wherein the interface device is configured to transmit the generated change data set to the backend system.

17. A method for operating a passenger transport system having a backend system, comprising: storing at least one user data set containing at least one electronic medium identifier authorizing the execution of a transport trip and at least one first transport usage condition linked to the electronic medium identifier, receiving a change data set generated by an interface device of the passenger transport system, the change data set containing at least one second transport usage condition, at least one first time date, and at least one user identifier for identifying a stored user data set; and changing the linkage between the electronic medium identifier stored in the identified user data set and the first transport usage condition for at least one future transport trip based on the received second transport usage condition, reconstructing a performed transport trip based at least on a check-in data set received from a validator device of the passenger transport system, the check-in data set containing at least the electronic medium identifier, and on a provided check-out data set containing at least the same electronic medium identifier, and generating a billing data set based at least on the reconstructed transport trip and a transport usage condition of the user data set linked with the electronic medium identifier.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0121] There is now a multitude of possibilities for designing and further developing the backend system according to the application, the interface device according to the application, the passage barrier according to the application, the passenger transport system according to the application and the method according to the application. For this purpose, reference is made on the one hand to the claims subordinate to the independent claims, and on the other hand to the description of embodiments in connection with the drawings. The drawings show:

[0122] FIG. 1 a schematic view of an embodiment of a passenger transport system according to the present application with an embodiment of a backend system according to the present application,

[0123] FIG. 2 a schematic view of an embodiment of an interface device in the form of a validator device according to the present application,

[0124] FIG. 3 a schematic view of an embodiment of a passage barrier according to the present application,

[0125] FIG. 4 a diagram of an embodiment of a method according to the present application,

[0126] FIG. 5 a flowchart of a further embodiment of a method according to the present application,

[0127] FIG. 6 a flowchart of a further embodiment of a method according to the present application,

[0128] FIG. 7 a flowchart of a further embodiment of a method according to the present application, and

[0129] FIG. 8 a flowchart of a further embodiment of a method according to the present application.

[0130] Similar elements are designated below with similar reference signs.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

[0131] FIG. 1 shows a schematic view of an embodiment of a passenger transport system 100 according to the present application, with an embodiment of a backend system 102 according to the present application.

[0132] In addition to the at least one backend system 102, the passenger transport system 100 comprises at least one interface device 104, 106, 110, 112, preferably a plurality of interface devices 104, 106, 110, 112. Exemplarily, at least one validator device 104 and/or at least one interface device 106 (in particular also a validator device) arranged in a passage barrier 108 and/or at least one mobile terminal 112 (e.g., a smartphone) of a user 116 and/or at least one ticket vending machine 110 are arranged as interface device 104.

[0133] An interface device 104 may be arranged in a transport vehicle 120 (e.g., a bus, a train, etc.), in particular in an entrance area 122 and/or an exit area 122 of the transport vehicle 120. Preferably, the passenger transport system 100 may comprise the at least one transport vehicle 120. Alternatively or additionally, an interface device 106, 110 may be arranged in a stop area 142 of the passenger transport system 100.

[0134] Furthermore, the passenger transport system 100 may comprise at least one ticket medium 114, preferably a plurality of ticket media 114. A ticket medium 114 according to the present application may comprise at least one storage means 118. The storage means 118 is used to store the electronic medium identifier of the ticket medium 114. In particular, the electronic medium identifier is readable by means of a not shown (contactless and/or contact-based) interface of the ticket medium 114.

[0135] Preferably, the ticket medium may be a credit card-based and/or debit card-based ticket medium. Preferably, the ticket medium may be a credit card and/or a debit card. Also, the card-based ticket medium may be a mobile terminal on which a credit card and/or debit card is electronically mapped or to which a credit card and/or debit card is electronically (uniquely) linked. Non-exhaustive examples of such a concept are Apple Pay, Google Pay or PayPal.

[0136] An interface device 104, 106, 110, 112 of the passenger transport system 100 is at least configured to detect an electronic medium identifier of a ticket medium and/or a user identifier (of the user data set) for identifying a stored user data set (from the plurality of stored user data sets). In particular, an interface device 104, 106, 110, 112 may comprise at least one detection module, such as a (contactless) near-field interface (e.g., NFC interface, camera, Bluetooth interface, etc.) in particular for detecting the electronic medium identifier and/or a contact-based interface (e.g., magnetic stripe reader module, etc.), in particular for detecting the electronic medium identifier, and/or a user interface (e.g. keyboard, touch display, etc.), in particular for detecting a user identifier (e.g. user name and password, etc.) (which can be entered by means of the user interface).

[0137] The at least one interface device 104, 106, 110, 112 of the passenger transport system 100 is further at least configured to detect a transport usage condition determined by means of a user interface (e.g., keyboard, touch display, etc.) of the interface device 104, 106, 110, 112. In particular, the same user interface that has already been used to detect the user identifier may be used. A different user interface may also be used in variants of the application.

[0138] The at least one interface device 104, 106, 110, 112 of the passenger transport system 100 is further configured to at least generate a change data set. The change data set contains at least the detected electronic medium identifier and/or user identifier, the determined transport usage condition, and at least one first time date (in particular, the detection time (and time stamp, respectively) of the electronic medium identifier and/or user identifier or the transmitting time of the change data set).

[0139] The interface device 104, 106, 110, 112 of the passenger transport system 100 is further configured to transmit the generated change data set to the backend system 102.

[0140] The illustrated backend system 102 (in particular formed by at least one computing device and/or cloud system) comprises at least one data memory 124. The data memory 124 is at least configured to store at least one user data set and user account, respectively, preferably a plurality of user data sets of in particular a corresponding number of different users 116 of the passenger transport system 100. It shall be understood that further data may be stored in the at least one data memory 124.

[0141] The at least one stored user data set contains at least one electronic medium identifier authorizing the execution of a transport trip and at least one first transport usage condition linked to the electronic medium identifier. Optionally, further data may be stored, such as a further user identifier, billing data, etc., as has already been described.

[0142] In addition, the backend system comprises at least one receiving module 134 and optionally a transmitting module 136. In particular, at least one bidirectional communication module may be provided for transmitting and receiving data. It shall be understood that two or more communication modules may be provided for different communication technologies.

[0143] The at least one receiving module 134 is configured to receive, in particular via a (not shown) wireless and/or wired communication network, a change data set generated by an interface device 104, 106, 110, 112 of the passenger transport system 100. As previously described, a received change data set contains at least one second transport usage condition, at least one first time date, and at least one user identifier for identifying a stored user data set. The user identifier may be the electronic medium identifier and/or a further user identifier, such as a user name and/or user password.

[0144] In addition, the backend system 102 comprises at least one change module 126. The at least one change module 126 is configured to change the linkage between the electronic medium identifier stored in the user data set identified (by means of the user identifier of the received change data set) and the first transport usage condition for at least one future transport trip based on the received second transport usage condition.

[0145] In particular, the change module 126 replaces or supplements the linkage between the first transport usage condition and the electronic medium identifier with a linkage between this electronic medium identifier and the second transport usage condition that is different from the first transport usage condition (immediately) after receiving the change data set.

[0146] Replace means that for at least one future, i.e., the immediately following, transport trip only the linkage between the electronic medium identifier and the second transport usage condition is valid. Supplement means that for at least one future, i.e., the immediately following, transport trip both the linkage between the electronic medium identifier and the second transport usage condition and the linkage between the electronic medium identifier and the first transport usage condition are valid. It shall be understood that at least one further linkage between the electronic medium identifier and at least one further second transport usage condition may be valid.

[0147] The backend system 102 comprises at least one trip reconstruction module 128. The trip reconstruction module 128 is configured to reconstruct an executed transport trip at least based on a check-in data set (e.g., said change data set) received from a validator device of the passenger transport system, the check-in data set containing at least the electronic medium identifier, and a provided check-out data set containing at least the same electronic medium identifier. Further data, such as schedule data, transport vehicle movement data, etc., may be considered by the trip reconstruction module 128.

[0148] Furthermore, a generation module 130 is provided, which is configured to generate a billing data set at least based on the reconstructed transport trip and the transport usage condition of the user data set linked to the electronic medium identifier, i.e., for example, only a linkage between the electronic medium identifier and the second transport usage condition or the linkages between the electronic medium identifier and the first transport usage condition as well as the second transport usage condition.

[0149] Optionally, the backend system 102 may comprise further modules 132, 138, 140, and 144, such as a time module 138, a timer 140, a counting module 132, and a counter 144.

[0150] Optionally, the change data set may contain at least one second time date (e.g., t=2 h, t=24 h, t=48 h, etc.) indicating a validity time duration of the second transport usage condition. In particular, the time module 138 is configured to set the timer 140 according to the second time date, i.e., 2 h, 24 h, or 48 h in said example. The change module 126 may be configured to change the linkage between the electronic medium identifier stored in the identified user data set and the second transport usage condition upon detection of an expiration of the timer 140 based on the first transport usage condition. In particular, after the change, only the linkage between the electronic medium identifier and the first transport usage condition is again valid (until the next change data set for that electronic medium identifier is received).

[0151] Alternatively or additionally, a change data set may optionally contain at least one trip number (e.g., 10) indicating the number of trips (between a check-in and a check-out) for which the second transport usage condition is valid. In particular, the counting module 132 is configured to set the counter 144 according to the number of trips contained in the change data set.

[0152] The change module 126 may be configured to change the linkage between the electronic medium identifier stored in the identified user data set and the second transport usage condition upon detection of an expiration of the counter 144 based on the first transport usage condition. In particular, after the change, only the linkage between the electronic medium identifier and the first transport usage condition is again valid (until the next change data set for that electronic medium identifier is received). Thus, when the counter 144 in the above example reaches 10 (or has counted down from 10 to zero), the change module 126 may change the linkage as described.

[0153] FIG. 2 shows a schematic view of an embodiment of an interface device 204, in particular in the form of a validator device 204, such as can be used, for example, in the passenger transport system 100 according to FIG. 1.

[0154] As previously described, the validator device 204 comprises at least one detection module 250 (e.g., a near-field interface 250) for detecting the electronic medium identifier of a ticket medium held within the read range of the detection module 250. By detecting the electronic medium identifier, for example, a validating of the ticket medium can be performed and a check-in data set can be generated.

[0155] The validator device 204 comprises at least one sensing module 256. In particular, the sensing module 256 is configured to detect a second transport usage condition determined by means of a user interface 252 (in the present example, a touch display 252) and linkable to the detected medium identifier. In particular, a selection of different and available second transport usage conditions can be displayed on the user interface 252, such as additional users, additional luggage, etc. At least one second transport usage condition may be selected respectively determined by (manually) selecting it via the touch display 252. This can be detected by the sensing module 256.

[0156] Furthermore, the validator device 204 comprises at least one linking module 258 that is configured to link a detected electronic medium identifier with the determined second transport usage condition. Linking is performed in particular by linking (immediately (e.g.: between 1 s and 20 s)) after a selecting respectively determining of the at least one second transport usage condition by means of the user interface 252 by the detection module 250, this detected electronic medium identifier with the determined second transport usage condition by the linking module 258.

[0157] Further, at least one generation module 260 is provided. The generation module 260 is configured to generate the change data set containing the detected electronic medium identifier, the second transport usage condition associated with the detected electronic medium identifier, and at least one first time date. In particular, this change data set is a check-in data set.

[0158] The at least one transmitting module 254 of the validator device 204 is configured to transmit the generated change data set to a backend system (e.g., 102) of the passenger transport system.

[0159] Optionally, a validator device 204 may comprise at least one further module 248, 262, 264, 266, 268. In particular, the validator device 204 may comprise at least one receiving module 248 in addition to a transmitting module 254. In particular, at least one bidirectional (remote) communication module for transmitting and receiving data can be provided. It shall be understood that two or more communication modules may be provided for different communication technologies.

[0160] In addition, the interface device 204 may optionally include a checking module 262 and a release module 264. The checking module 262 is configured to check an admissibility of a respective detected electronic medium identifier based on a comparison (performed by the checking module 262 or a checking module (not shown) of the backend system) of the detected electronic medium identifier with a plurality of electronic medium identifiers stored in a negative list, as previously described.

[0161] The release module 264 may be configured to release a passing through the interface device 204 if the detected electronic medium identifier is a permissible electronic medium identifier. A releasing may be indicated, for example, by the user interface 252.

[0162] The release module 264 may be configured to block a passing of the interface device if the detected electronic medium identifier is a non-permissible electronic medium identifier. A blocking may be indicated, for example, by the user interface 252.

[0163] Alternatively or additionally, a validator device 204 may preferably have a (local) data memory 266. The data memory 266 may be configured to store received change data sets of at least one further (not shown) validator device and, in particular, the generated change data sets.

[0164] The authentication module 262 may alternatively or additionally be configured to verify the authenticity of the detected electronic medium identifier based on a comparing of the detected electronic medium identifier with the electronic medium identifier of the at least one stored change data set.

[0165] The release module may alternatively or additionally be configured to release a passing of the interface device 204 if the detected electronic medium identifier corresponds to the at least one stored electronic medium identifier. This may be indicated, for example, by the user interface 252.

[0166] The release module 264 may be configured to block a passing through the interface device if the detected electronic medium identifier does not correspond to the at least one stored electronic medium identifier. This may be indicated, for example, by the user interface 252.

[0167] As previously described, the data memory 266 may be configured to store the generated and/or received change data sets. Additionally, in particular, the at least one check-in data set may be stored in the data memory 266. The data memory 266 may be configured to provide, for example via a further interface 268, the at least one change data set and/or the at least one check-in data set such that said data sets are receivable by an (not shown) inspection device via a (not shown) data network.

[0168] As has been described above, the inspection device can read all electronic media identifiers that have been detected (and, in particular, that have not yet been deemed to have been cancelled or checked out) and store them locally in the inspection device. In other words, all medium identifiers of properly validated ticket media can be transmitted to the inspection device by the validator device 204. Then, all (current) users of the transport vehicle can be verified by having their respective ticket media read by the inspection device, i.e., having their respective electronic medium identifiers detected by the inspection device, and compared to the locally stored (permissible) electronic medium identifiers. If it is determined that there is no correspondence between a detected medium identifier and a medium identifier stored locally in the inspection device, it can be assumed that the user is not authorized to use the transport vehicle. By additionally reading second transport usage conditions from the validator device 204 by the inspection device, the authorization of additional users and/or items can also be verified in a simple manner (by an inspector).

[0169] FIG. 3 shows a schematic view of an embodiment of a passage barrier 308 according to the present application, in particular with an interface device 306. The interface device 306 may preferably be formed according to the interface device 204 of FIG. 2.

[0170] The passage barrier 308 comprises a movable blocking element 370 (in particular a door 370). In the present case, the blocking element 370 can be moved respectively displaced between a release position and a blocking position shown in FIG. 3 by an actuator 376, which can be arranged in a base of the passage barrier 308.

[0171] In particular, the passage barrier 308 may comprise a local control module 372, in particular configured to control the actuator 376. In particular, the control module 372 may be configured to control a moving of the blocking element (in particular by controlling the actuator 376) between the blocking position and the release position. For example, a release module of the interface device 306 may be linked to the control module 372. As has been described, the release module may cause a releasing and blocking of passing through the passage barrier 308. Depending on the input from the release module, a moving of the blocking element 370 may be caused respectively controlled (or refrained from) by the control module 372.

[0172] Preferably, the controlling is based on the (first and/or second) transport usage condition(s) linked with the detected electronic medium identifier. In particular, the control module 372 may be configured to hold the blocking element 370 in the release position for a release time duration. The length of the release time duration may be based on the (second) transport usage condition linked with the detected electronic medium identifier. In particular, the first transport usage condition may provide a default release time duration that may be extended based on the second transport usage condition.

[0173] Optionally, the passage barrier 308 may comprise at least one sensor 374, such as in the form of a light barrier. The sensor 374 may be configured to detect passages through the passage barrier 308 in the release position of the barrier element 370. In particular, a second transport usage condition may specify a specific number n.sub.N of users as the scope of validity of a single electronic medium identifier detected by the interface device 306 (for the first transport usage condition, there may be (by default) n.sub.N=1).

[0174] The control module 372 may be configured to move the blocking element 370 from the release position to the blocking position upon respectively (immediately) after a detection of a number n.sub.P of passages corresponding to the determined number n.sub.N of users, as described earlier.

[0175] In particular, in addition, the passage barrier 308 may comprise at least one timer 378 that can be started after each detected passage. The control module 372 may be configured to move the blocking element 370 from the release position to the blocking position (always) upon expiration of the timer 378.

[0176] FIG. 4 shows an embodiment of a method according to the present application for operating a backend system (e.g., the backend system 102 according to FIG. 1) of a passenger transport system.

[0177] In a step 401, a storing of at least one user data set is performed, the user data set containing at least one electronic medium identifier authorizing to execute a transport trip (with a passenger transport vehicle) and at least one first transport usage condition linked with the electronic medium identifier, as has been described.

[0178] In step 402, a receiving of a change data set generated by an interface device of the passenger transport system is performed, the change data set containing at least one second transport usage condition, at least one first time date, and at least one user identifier for identifying a stored user data set, as has been described.

[0179] In step 403, changing the linkage between the electronic medium identifier stored in the identified user data set and the first transport usage condition is performed for at least one future transport trip is performed based on the received second transport usage condition, as has been described.

[0180] In step 404, a reconstructing of an executed transport trip is performed at least based on a check-in data set received from a validator device of the passenger transport system containing at least the electronic medium identifier, and a provided check-out data set containing at least the electronic medium identifier, as has been described.

[0181] In step 405, a generating of a billing data set is performed based at least on the reconstructed transport trip and the transport usage condition of the user data set linked with the electronic medium identifier. Then, the billing data set may be transmitted to the user, for example, as has been described.

[0182] FIGS. 5 to 8 show exemplary use cases and methods, respectively.

[0183] In the application according to FIG. 5, at least one validator device (e.g., as in FIG. 2) can be arranged in a transport vehicle (e.g., bus, streetcar, subway, commuter train, ferry, . . . ), which in particular is intended to be used immediately after a user enters the vehicle.

[0184] Alternatively or additionally, at least one validator device (e.g., as in FIG. 2) can be arranged in a stop area respectively at a stop (e.g., station concourse, platform, stop), which is intended to be used in particular before a user enters the vehicle respectively enters the boarding area. In this case, for example, a group of users may wish to use the transport vehicle.

[0185] In a first step 501, one of the users of the group can determine respectively select a second transport usage condition by means of a user interface of the validator device, in particular to select the scope of validity for the next tap with his ticket medium. For example, the following second transport usage condition can be determined respectively selected on a touch display with plus/minus keys: [0186] + ADULT [0187] + CHILD [0188] + BICYCLE [0189] + DOG

[0190] The determined second transport usage condition may be detected by a sensing module.

[0191] In a step 502 immediately following step 501, the user can then cause a check-in for the entire group at the validator device by a single tap, i.e., by detecting the electronic medium identifier of his ticket medium.

[0192] In step 503, the detected second transport usage condition is linked to the detected electronic medium identifier. In particular, the validator device can generate and store a single change data set respectively validation data set which, compared to a conventional check-in data set, can in particular contain additional data about the currently selected scope of validity. In a step 504, this data set can be transmitted to the backend system.

[0193] Then the group can drive to its destination. If a check-out is necessary, the entire group can be checked out with a single tap and, in particular, a corresponding check-out data set can be generated and transmitted. In this exemplary use case, if the same group in identical occupancy wishes to continue the trip, the same second transport usage condition must be selected again at the next check-in before the tap. If the group wants to continue the trip with a different occupation, a different second transport usage condition must be selected at the next check-in before the tap in this exemplary use case.

[0194] The backend system reconstructs according to the received data sets in step 505 the at least one performed transport trip and charges this at least one trip, in particular according to the second transport usage condition, with the payment means deposited to the customer account assigned to the used electronic medium identifier (step 506).

[0195] The backend system can optionally transmit at least one message about the selected second transport usage condition, for example to a mobile device respectively app on the user's mobile device, to a mobile phone number stored in the customer account, and/or to an email address stored for the customer account.

[0196] In the use case according to FIG. 6, at least one validator device (e.g., as in FIG. 2) can be arranged in a transport vehicle (e.g., bus, streetcar, subway, commuter train, ferry, . . . ), which in particular is intended to be used immediately after a user enters the vehicle. Alternatively or additionally, at least one validator device (e.g. as in FIG. 2) can be arranged in a stop area respectively at a stop (e.g. station concourse, platform, stop), which is intended to be used in particular before a user enters the vehicle respectively before a user enters the boarding area. In this case, for example, a group of users may wish to use the transport vehicle.

[0197] One of the users of the group in the present case uses a further interface device of the passenger transport system in a first step 601 for determining a second transport usage condition to pre-select the scope of validity for the next tap with its ticket medium. The further interface device of the passenger transport system may be, for example: [0198] a special validator device with a customized preset application, [0199] a ticket vending machine with an additional function, [0200] a website that can be accessed via a mobile device, for example, [0201] an app installed on the mobile device.

[0202] The user can use his ticket medium respectively the electronic medium identifier stored therein for the identification of his user account or a further user identifier (e.g., the user can enter access data for a user account). Then, in a step 602, the user can determine respectively select a second transport usage condition by means of a user interface of the further interface device, in particular in order to select the scope of validity for the next tap with his ticket medium. For example, the following second transport usage condition can be determined at a touch display with plus/minus keys: [0203] + ADULT [0204] + CHILD [0205] + BICYCLE [0206] + DOG

[0207] The determined second transport usage condition may be detected by a sensing module.

[0208] In step 603, a change data set may be transmitted to the backend system. The backend system may store the change data set and, in particular, in step 604, change the linkage between the electronic medium identifier stored in the identified user data set and the first transport usage condition for at least one future transport trip based on the received second transport usage condition.

[0209] Then, at a validator device, the user can perform a check-in for the entire group with a single tap of his/her ticket medium.

[0210] In step 605, the validator device can generate and, for example, store a check-in data set. In particular, the check-in data set does not contain any additional data about the currently selected scope of validity. In step 606, the check-in data set can be transmitted to the backend system.

[0211] The backend system may store the check-in data set and link it to the stored second transport usage condition. Optionally, the backend system can transmit a change data set containing the second transport usage condition to the at least one validator device. Then, the validator device may display the selected second transport usage condition immediately after the electronic medium identifier is detected. The validator device may store said data sets, in particular for an inspection process described previously.

[0212] The backend system reconstructs, according to the received data sets in step 607, the at least one completed trip and charges this at least one trip, in particular according to the second transport usage condition, to the payment means stored to the customer account assigned to the used electronic medium identifier (step 608).

[0213] The backend system can optionally transmit at least one message about the selected second transport usage condition, for example to a mobile device respectively app on the user's mobile device, to a mobile phone number stored in the customer account, and/or to an email address stored for the customer account.

[0214] In the use case according to FIG. 7, at least one passage barrier (e.g., as in FIG. 3) and/or at least one passage barrier array with a plurality of passage barriers (e.g., as in FIG. 3) may be arranged in a stop area respectively at a stop point (e.g., station concourse, platform, stop), wherein the passage barrier is intended to be used before a transport vehicle is entered and/or before the boarding area is entered. Again, by way of example, a group of users may wish to use the at least one transport vehicle.

[0215] In a first step 701, one of the users can determine respectively select a second transport usage condition by means of a user interface of the interface device (e.g., a validator device) of the transit barrier, in particular, in order to select the scope of validity for the next tap with his/her ticket medium. For example, the following second transport usage condition can be determined at a touch display with plus/minus keys: [0216] + ADULT [0217] + CHILD [0218] + BICYCLE [0219] + DOG

[0220] The determined second transport usage condition may be detected by a sensing module.

[0221] In a step 702 immediately following step 701, the user can then cause a check-in for the entire group at the validator device by a single tap, i.e., by detecting the electronic medium identifier of his/her ticket medium.

[0222] In step 703, the detected second transport usage condition is linked to the detected electronic medium identifier. In particular, the interface device can generate and store a single change data set and validation data set, respectively, which, compared to a conventional check-in data set, can in particular contain additional data about the currently selected scope of validity.

[0223] The passage barrier then releases its access for the number n.sub.N of preselected passengers. In particular, the at least one barrier element is opened and n.sub.P passages are allowed, detectable by at least one sensor of the passage barrier. In particular, it may be provided that as long as less than n.sub.P passages are detected by the at least one sensor, a timer of the passage barrier is started after each passage (e.g., 10 to 15 seconds). If the next passage does not start within the expiration of the timer, the blocking element is moved to the blocking position. After detecting n.sub.P passages, the blocking element can be moved to the blocking position. Alternatively or additionally, an in particular slow closing of the at least one blocking element can be performed, e.g. depending on the selected additional persons or objects (e.g., if children or dogs have been preselected).

[0224] In a step 704, the data set generated in step 703 can be transmitted to the backend system. Then, according to step 505 of FIG. 5, the method can be continued.

[0225] In the use case according to FIG. 8, at least one passage barrier (e.g., as in FIG. 3) and/or at least one passage barrier array with a plurality of passage barriers (e.g., as in FIG. 3) can be arranged in a stop area respectively at a stop point (e.g., station concourse, platform, stop), wherein the passage barrier is intended to be used before a transport vehicle is entered and/or before the boarding area is entered. Again, by way of example, a group of users may wish to use the at least one transport vehicle.

[0226] As in FIG. 6, one of the users may use a further interface device in step 801 for determining a second transport usage condition to pre-select the scope of validity for the next tap with its ticket medium.

[0227] As in FIG. 6, the further interface device can transmit the change data set for the next tap with the corresponding ticket medium identifier to the backend system (step 802).

[0228] Furthermore, according to FIG. 6, the backend system can link the change data set for the next tap to the medium identifier and, in particular, store it. Then the change data set can be transmitted and stored by the backend system in the way described before (step 803).

[0229] The backend system may transmit the received change data set to preferably all transit barriers (this is done in particular within a few seconds (e.g., <3 seconds) after a reception) (step 804).

[0230] The user can then perform a check-in for the entire group at the passage barrier in step 805 with a single tap of his/her ticket medium. Then, according to FIG. 7, the passage barrier can release the passage barrier, and the method can continue according to FIG. 7.

[0231] As already described, an inspection process can optionally be carried out according to the application. In order to carry out an inspection, in particular of open-payment ticket media described above (i.e., to check whether each passenger has tapped respectively validated his or her ticket medium at a validator device before entering the transport vehicle), an inspector can tap an inspection card (also referred to as an inspection element) at a validator device and can cause a validator device in a transport vehicle, in particular by means of a (secured) data network in the form of a (secured) WLAN, to transmit the current medium identifier list of the validated ticket media to an inspection device of the inspector.

[0232] In a subsequent inspection process, the inspection device may detect and read, respectively, an electronic medium identifier of a user's ticket medium to be inspected to verify that the read electronic medium identifier is on the current medium identifier list, as previously described.

[0233] For example, according to the first use case, the current medium identifier list of a validator device may also contain the additional data respectively the second transport usage conditions about the currently selected scope of validity of a ticket medium used, i.e., in particular: How many people and items requiring payment are riding on a tap. The inspection device can take this information from the medium identifier list and display it to the inspector, for example.

[0234] According to the use case shown in FIG. 6, the current medium identifier list of a validator device cannot contain the additional data on the currently selected scope of validity of a ticket medium used, i.e., in particular, it cannot contain information on the fact that several persons and objects requiring payment are riding on one tap. This information can be requested by the inspection device for a current inspection process by means of a remote communication network at the backend system.

[0235] Finally, it should be noted that multiple tapping is not a preferred solution for a majority of users in practice, as it violates the frequently applicable anti-passback rules, does not allow other tariffs to be activated (child tariff, etc.) and, in particular, leads to operating errors, as it is not always clear to the user how many times he has actually tapped contactless.

LIST OF REFERENCE SIGNS

[0236] 100 passenger transport system [0237] 102 backend system [0238] 104 interface device, in particular validator device, [0239] 106 interface device [0240] 108 passage barrier [0241] 110 interface device, in particular ticket vending machine [0242] 112 interface device, in particular mobile terminal device [0243] 114 ticket medium [0244] 116 user [0245] 118 storage means [0246] 120 transport vehicle [0247] 122 exit area or entrance area [0248] 124 data memory [0249] 126 change module [0250] 128 trip reconstruction module [0251] 130 generation module [0252] 132 counting module [0253] 134 receiving module [0254] 136 transmitting module [0255] 138 time module [0256] 140 timer [0257] 142 stop area [0258] 144 counter [0259] 204 interface device, in particular validator device [0260] 248 receiving module [0261] 250 detection module [0262] 252 user interface, in particular touch display [0263] 254 transmitting module [0264] 256 sensing module [0265] 258 linking module [0266] 260 generation module [0267] 262 checking module [0268] 264 release module [0269] 266 data memory [0270] 268 interface [0271] 306 interface device [0272] 308 passage barrier [0273] 370 blocking element [0274] 372 control module [0275] 374 sensor [0276] 376 actuator [0277] 378 timer