EP3012808A1 - System und Verfahren zum Erstellen und Auswerten von Nutzungsberechtigungen und Fahrscheinen - Google Patents

System und Verfahren zum Erstellen und Auswerten von Nutzungsberechtigungen und Fahrscheinen Download PDF

Info

Publication number
EP3012808A1
EP3012808A1 EP14003601.3A EP14003601A EP3012808A1 EP 3012808 A1 EP3012808 A1 EP 3012808A1 EP 14003601 A EP14003601 A EP 14003601A EP 3012808 A1 EP3012808 A1 EP 3012808A1
Authority
EP
European Patent Office
Prior art keywords
tester
background system
list
entitlement
valid
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
EP14003601.3A
Other languages
English (en)
French (fr)
Inventor
Martin Rau
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.)
Atron Electronic GmbH
Original Assignee
Atron Electronic GmbH
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 Atron Electronic GmbH filed Critical Atron Electronic GmbH
Priority to EP14003601.3A priority Critical patent/EP3012808A1/de
Publication of EP3012808A1 publication Critical patent/EP3012808A1/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
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems

Definitions

  • the invention generally relates to a system and method for creating and evaluating usage entitlements and, more particularly, to a system and method for creating and evaluating tickets in Public Transport (PPO).
  • PPO Public Transport
  • existing systems require a connection to the server in the data center, but this can fail, increasing the time required for auditing and incurring additional costs.
  • these existing systems require a very reliable, stable and, above all, nationwide data connection, which is required in order to be able to establish a connection to the data center at all times.
  • An embodiment of the invention relates to a method for creating and evaluating a driving authorization in a passenger transport system.
  • identifications (hereinafter also referred to as ID or identifier) are linked to a first authorization, wherein the first authorization concerns at least a first zone or a first route of the passenger transport system and the ID serves as a valid driving authorization in this first zone or on this first route ,
  • the ID is linked according to the embodiment with a second authorization, which relates to at least one second zone or a second route and the ID also serves as a valid driving authorization in this second zone or on this second route.
  • the second zone or the second route may be part of the same passenger transport system.
  • the second zone and the second route may also belong to another passenger transport system which is spatially separate from the former passenger transport system, such as different cities or transport associations, or which belongs to another company or service provider with its own infrastructure.
  • the ID associated with an entitlement is transmitted to a verifier for verifying the validity of driving entitlements of users of the corresponding passenger transport system.
  • the testing device can read in a method step an ID of a user or passenger.
  • the tester checks whether the ID read in is included in a list.
  • this list can be stored locally in the test device and comprises a multiplicity of IDs which are valid driving authorizations in the zone or on the route in which the test device is currently located.
  • the tester can communicate with a background system to receive or update the list.
  • This local storage of the current valid drive list allows for a significant reduction in the data to be stored in the tester and, as described below, avoids the need to constantly connect the tester to a remote system such as a background system or server.
  • a further embodiment of the invention relates to a test device for checking the validity of driving authorizations in a passenger transport system.
  • the testing device may include means for receiving identification from a background system.
  • the ID is linked to a driving authorization which concerns at least a first zone or a first route of the passenger transport system.
  • the ID is used accordingly as a valid driving authorization in this zone or on this route.
  • the tester further comprises means for reading in an ID of a user or passenger, and means for checking the read ID.
  • the tester stores a list with a variety of IDs.
  • the list stored in the tester includes those IDs associated with valid permissions for a zone or a route of a passenger transport system in or on which the tester is currently located. For this purpose it can be provided that the tester can communicate with the background system to receive or update the list.
  • Another embodiment of the invention relates to a method for creating and evaluating user authorizations.
  • the method comprises a step of linking, in a first background system, an ID with a first authorization for at least a first service from a first service provider.
  • the method further comprises a step of associating this ID with a second entitlement for at least one second service from a second service provider, the ID for the at least first and second services serving as a valid entitlement for a user.
  • the method further comprises transmitting the ID and the first entitlement to a second background system of the first service provider, the second background system storing the ID and the first entitlement.
  • the method may transmit the ID and the second privilege to a third background system of the second service provider to store the ID and the second privilege in the third background system.
  • the ID may be communicated by the second or third background system to a verifier for verifying the validity of permissions from the users.
  • the tester can read an ID. Furthermore, it is checked by means of the test device whether the read-in ID is contained in a list.
  • the list may be stored in the tester for this purpose and contain a multiplicity of valid authorization IDs.
  • the tester may further communicate with at least the second or third background systems to receive or update the list.
  • another embodiment relates to a corresponding system for implementing the method.
  • a computer readable medium having computer readable instructions which, when executed, perform one of the methods described above and below.
  • the embodiments of the invention generally relate to entitlements for all possible services.
  • entity which also includes services such as taxi rides, travel agency services, Rental car tours, boat trips and / or flights include.
  • entitlements may also fall under the term entitlement, such as movie or theater tickets, swimming pool visits, web downloads, hotel reservations, shopping permits, and so on.
  • the embodiments of the invention are applicable to all aspects related to the secure purchase of prepaid or guaranteed payments. This applies in particular if several service providers are involved in the provision of services. This creates a globally interoperable entitlement system, which can create a chain of services that can be settled through a reseller.
  • the embodiments described below use the principle of identification (ID) as the basis for issued tickets.
  • ID the principle of identification
  • the ticket information ie the description of permissions, which service, which entry, which means of transport, etc. may be used when and where
  • the ticket serves only as an identification, which is linked in a server with a certain authorization. It is thus no longer worth writing to process tickets, since this value (the authorization) is no longer stored or noted on the ticket itself.
  • a ticket can be a card in which an RFID chip is embedded and allows unambiguous identification.
  • RFID cards can be read out quickly using standard ISO 14443 A / B readers.
  • the RFID cards can be issued by a transport company and used again at any time.
  • a passenger can also bring along a card with a unique RFID identifier, which can then be used as a ticket.
  • the ticket may also be embedded on the mobile phone, for example in the form of an NFC identification or by displaying a QR scan code.
  • the ticket can also be in personalized form, such as in the form of a credit card or a passport of the passenger. Important is only the uniqueness of the ID of the ticket.
  • the ID of the ticket is compared with a list of valid IDs in a tester. To make this possible, it is important that the tester has knowledge of all valid IDs that are in the same zone as the tester. Specifically, this means that the tester locally checks the validity of a ticket by matching the ID of the ticket with internally stored IDs. For this it is necessary that the tester regularly - but not necessarily continuously - all valid tickets in the zone to be checked knows.
  • the embodiments of the invention do not necessarily require that all valid IDs for an entire region (eg, for the whole traffic association) be stored in a tester, but only those IDs should be present in a tester valid in the corresponding zone (validity zone) are in which the tester itself is located. That is, if a controller with a tester is in zone "Z1", then ideally only the IDs stored in the tester are stored in the zone Z1 are valid at this time. In alternative embodiments, more or fewer IDs may also be listed in the tester, as described below.
  • zone generally refers to a scope.
  • a region for example, a city with surrounding area
  • zones are divided into different zones.
  • a zone not only describes a particular section or part in the region, but also a direction of a means of transport in the part or section of the region.
  • the zone "Munich: Marienplatz - Odeonsplatz” can describe a different zone than "Munich: Odeonsplatz - Marienplatz”.
  • the term “zone” is arbitrarily scalable and can describe an entire region, a city, a district, a lot of stops or individual routes.
  • a test apparatus may be a mobile tester which may be worn by a controller to perform spontaneous checks of tickets.
  • the tester may also be part of a stationary control or inlet system.
  • the tester can also be realized in conjunction with a turnstile or a passage barrier.
  • the tester may be fixed in a means of transport (bus, train, etc.) and require the passenger to log in to the means of transport as soon as he gets on the bus.
  • the test apparatus of the present invention comprises an internal memory, at least one wireless communication unit (mobile radio, WLAN, etc.), a processor and at least one read-in unit for reading in an ID of a ticket.
  • Possible read-in units may be: camera, laser or laser scanner, NFC reader, RFID reader, conventional card reader, Bluetooth interface, infrared interface, keyboard, touch screen, etc.
  • the tester may also include a location detection system which detects the current zone at any time the tester is located. This location detection system may be GPS, for example.
  • the location detection system consists of a sensor by means of which a checker with the tester checks in at corresponding location points. For example, an inspector may check in with his tester at a particular stop at which location information is communicated to the tester via the sensor, thereby notifying the tester of the current zone.
  • other location detection systems for the tester are conceivable.
  • an inspector manually enters the current zone in which he is located in the tester or an external system transmits the location information to the tester.
  • the tester also communicates the location (zone) of the tester to the server so that the server can manage the list of valid IDs for the tester and provide the tester with the appropriate IDs.
  • Authorizations e.g., driving rights
  • purchased at short notice e.g., at the platform
  • intended to be used immediately may also allow for direct, local communication between a vending machine (e.g., ticket vending machine) and the tester, as described below.
  • the tester can receive a new ID with authorization directly from a ticket vending machine, which is immediately valid in the zone of the tester.
  • a passenger may use the system for this purpose of passenger traffic.
  • a passenger indicates the starting point, destination and time period for a planned trip or journey (eg at a ticket machine, or via the Internet, input terminal etc.) and the described system offers different routes with different modes of transport (taxi, bus, train, plane, cable car) , Ship, rickshaw, rental car, etc.) in the desired period.
  • all required tickets or their entitlements are purchased and / or reserved and then linked to an ID as described.
  • FIG. 1 shows an overview of the concept and a part of the infrastructure, according to the present invention.
  • FIG. 1 shows a system 100 which shows a server 101 in the background system (eg in a data center) in which IDs are associated with permissions.
  • ID 1 110 and ID 2 120 are shown as associated with the respective permissions 120 and 122, respectively.
  • IDs may be stored in the server 101 and associated with permissions, because the present invention is not limited to a certain number of IDs stored on the server 101.
  • Authorization 120 (and also 122) contains various information.
  • An essential information of the authorization 120 is the scope of the ticket, which is linked to the ID 1 110. In the example off FIG. 1 describes entitlement 120 that the ticket is valid in Zones I and II.
  • authorization 120 which is linked to ID 1 110, describes that the ticket with ID 1 is valid on November 8, 2014 in zones I and II.
  • the ID 2 112 is linked to the corresponding authorization 122.
  • Authorization 122 describes that a ticket with ID 2 112 is valid in Zones II, III and IV on 8.11.2014 between 14:25 and 16:25.
  • zone and the validity period are described as information in a permission on the server 101 in the above example, the present invention is not limited thereto. Further information may be described in the appropriate permissions, such as a description of the means of transport that may be used (for example, bus, tram and subway, but no suburban train).
  • an ID may also be associated with multiple permissions.
  • a first authorization may include a service of a first service provider and a second authorization may include a service of a second service provider.
  • the ID can then be associated with both the first and second permissions.
  • These links between ID and a corresponding authorization can then be transmitted separately to corresponding background systems (for example servers) of the corresponding service providers. That is, the association of the ID with the first authorization is transmitted to the first service provider and the association of the ID with the second authorization is transmitted to the second service provider.
  • the linking of an ID with an authorization in the server 101 can be done by purchasing a ticket in the described system.
  • a passenger may purchase a ticket that allows them to use public transport in a particular zone within a specified time.
  • This purchase of the ticket can be done in different ways.
  • the passenger can purchase a ticket at a ticket vending machine, whereupon the ticket vending machine issues the passenger a ticket with a unique ID, eg an RFID chip card or in the form of a barcode on paper, and at the same time the information about the issued ID and the acquired authorization to the server 101 transmits.
  • the server 101 can then associate the ID transmitted by the ticket vending machine with the authorization and store it.
  • the ticket can also be purchased online by the passenger, for example, on the computer or by mobile phone.
  • the system can then assign a unique ID to the passenger, for example in the form of a QR code for printing or display on a mobile phone display, or mobile phones with integrated NFC chip, or Bluetooth module, or infrared interface can be used to transmit a digital ID to be used.
  • the passenger can specify an existing ID when purchasing a driving authorization. This brought ID can already be known in the server 101 and possibly already associated with an authorization. This existing authorization for the ID of the passenger can then be extended by the server 101 to the newly acquired authorization.
  • This concept of reusing existing IDs is not necessarily limited to buying tickets by mobile phone or computer, but can also be done at the ticket vending machine. For example, the ID of an existing ticket can be read in at a ticket vending machine and linked with other authorizations.
  • the passenger brings his own ticket medium, which is able to be uniquely identified.
  • This can be, for example, an identity document, a credit card, or something similar, which can preferably be read out by RFID.
  • the identification medium can be added to the server 101 immediately upon first use to purchase an authorization if the identification medium meets certain criteria approved by the operator.
  • An ID can be linked to multiple permissions. Thus, e.g. Tickets in different regions or more generally services with different service providers can be mapped on an ID.
  • the server 101 can transmit the ID to one or more zones for which the authorization of the ID describes a validity.
  • the server 101 transmits the corresponding IDs to testers 131 and 141 located in the respective zones 130 and 140. This transmission of the IDs may be done directly from the server 101 to the respective testers 131 and 141, however, one or more servers may be interposed therebetween to realize arbitrary scalability to multiple carriers, as described below with reference to FIG FIG. 4 described. Even if in FIG.
  • test device 101 If only one test device per zone is shown, it should be clear to the person skilled in the art that several test devices can also be in one zone at the same time. In such a case, the server 101 (or an intermediary server) transmits to all testers in a particular zone the ID that is valid in the corresponding zone.
  • a test device may also comprise a plurality of SIM cards or a multi-network SIM card.
  • Wi-Fi hotspots can be set up at certain points (for example, at selected locations or at all stops) so that the list of valid IDs in the test device can be updated at the latest at such a stop.
  • an updated list of valid IDs is transferred to the tester with authority.
  • This update of the list of valid IDs / entitlements stored in the respective testers is preferably done by a transfer of changes in the list. This means that not every connection to the server 101 (or an intermediary server) requires the complete list of valid IDs / permissions to be transmitted to a corresponding tester. Rather, only those IDs / entitlements are transferred from the server 101 (or an intermediate server) to the tester, which are valid in the zone of the tester and are not yet stored in the tester.
  • the list of valid IDs / credentials in a tester can be updated whenever the tester can connect to server 101 (or an intermediate server). Alternatively, the list may be updated at predetermined time intervals, for example once per minute or every 5 minutes, etc.
  • the server 101 can also transmit to the corresponding test devices of the zone the instruction for deleting the corresponding authorization and thus also the ID.
  • a tester may also independently determine that an ID is no longer eligible for the corresponding zone and may remove that ID from the valid ID list of the tester.
  • a reason for the expiration of an ID may be that the validity period described in the authorization associated with the ID has expired. For example, the validity of ID 2 would be 112 FIG. 1 in Zones II, III and IV on 8/11/2014 at 16:26, whereupon the ID from all testing devices in Zones II, III and IV will be deleted from the list of valid IDs at that time.
  • Another reason for the expiration of the validity of an ID may be that the test device is going from a first zone to a second zone, the linked permission of said ID being valid in the first zone but not in the second zone.
  • all IDs that are not valid in the second zone can be deleted from the valid ID list of the tester. For example, if the tester 141 is off FIG. 1 goes from zone II to zone I, so the ID 2 is deleted from the tester 141 because this has no authorization in the zone I.
  • IDs may be retained even though they are no longer valid in the second zone. In this case, the IDs that are invalid in the second zone are marked as invalid in the tester. If the test device subsequently returns to the first zone, then the IDs marked as invalid need not be determined again by the server or downloaded, but only the invalidation marks must be removed.
  • Another reason for the expiration of an ID may be that an ID has been disabled by server 101 (or an intermediary server). If, for example, the system recognizes that a ticket has been illegally duplicated and thus virtually two tickets with the same ID are in circulation, the ID can be blocked. As a result, the locked ID is not stored in any tester on the list of valid IDs.
  • a list of blocked IDs can be transmitted to corresponding test devices (in the corresponding zones), with which fraud attempts can be detected immediately.
  • the list of allowed IDs in a tester may also, according to an embodiment of the invention, be evaluated before the next stop to check if the IDs in the list are valid at that stop.
  • the tester determines the ID of the ticket and searches the list of valid IDs for the ID of the ticket purchased. If the tester recognizes that the imported ID of the ticket is also valid in the list IDs, the tester recognizes that the ticket is valid. On the other hand, if the ID of the imported ticket is not found in the locally stored list of valid IDs in the tester, this is an indication that the ticket is invalid. In such a case, the verifier may attempt to make a directed request to the server 101 (or an intermediary server) to check online whether there is an appropriate entitlement in the current zone for the ID of the ticket being read. The result of this online query can be displayed directly by the tester.
  • connection to the server could be made successfully and an appropriate privilege could be verified as valid by the server 101 (or an intermediary server).
  • Another result of this request may be that the connection to the server was successful, but no corresponding permission was found on the server associated with the ID of the ticket.
  • Another result of this request may be that, for various reasons, it was unable to connect to the server, allowing further steps to be taken to verify the ticket or repeating the process again.
  • the described method ensures that the list of valid IDs in the test devices are optimized for their fields of use, as a result of which the list of valid IDs is kept as small as possible.
  • Another result of the small list of valid IDs is that it minimizes the amount of data transfer and therefore the cost of doing so.
  • This list compilation is generally done for one or more testers in the background, for example, server 101.
  • the background servers are responsible for particular groups of test equipment, i. the provision of lists of valid IDs can be distributed to multiple servers in the background. This makes it possible to extend and realize the system to arbitrarily large regions.
  • the ID may also be deleted by a second tester (eg, by a command from the server) if the ID has just been read by a first tester in a remote zone. The ID can then be transferred back to the second test device after a calculated time.
  • An advantage of the system described herein is that electronic tickets can be checked for validity, even if the necessary test equipment does not have uninterrupted contact with a server that knows and stores the corresponding entitlements of the electronic tickets. Especially in rural areas, but also in underground subways, or other vehicles in tunnels, a radio network coverage is not always guaranteed without interruption. Thus, in public passenger transport, the validity request from a test device to a central server via the mobile network is often difficult. However, with ticketing controls, since a fast check of high-throughput (i.e., fast entry or many controls) driving entitlements is necessary, such a server request is too time-consuming even with good network coverage.
  • the validation of tickets described herein does not require a server request for each individual ticket, but the check is against a list of valid IDs that the testers have stored locally. This testing procedure is more efficient, less error-prone and faster than an online query for each individual ticket.
  • FIG. 2 shows a method 200, according to an embodiment of the invention, which describes the creation of a ticket.
  • the passenger purchases a ticket. This can be done in several ways, as already described. Examples include ticket machines, the Internet, at ticket agencies, the driver directly in the vehicle, etc.
  • step 204 it is checked during the purchase process whether the passenger already has an existing ID.
  • a passenger can present to the sales system (for example the ticket machine) an already existing ID, which may already be linked to authorizations.
  • the passenger can enter the existing ID, for example via a keyboard, or the ID can be read in by means of the existing ticket from the sales system (for example, the ticket machine).
  • an ID for the passenger is created in step 206.
  • This ID can be anonymous, but it can be be personal.
  • the ticket machine can issue an RFID chip card with a unique ID and pass it to the passenger, but also paper tickets with, for example, a scan code or a normal code is conceivable as a non-exhaustive example.
  • the passenger's ID is associated with an appropriate entitlement that the passenger purchased through the purchase process. If there is already an ID associated with a privilege, this privilege can be extended. This can be done by adjusting the permission, or by an additional link in the server with another permission. This linking of the unique ID with the appropriate authorization preferably takes place in the server 101 FIG. 1 However, it can already be done in a ticket machine and then transferred to the server 101.
  • the ID is communicated to those testers that are in the zones for which the associated privilege describes a validity of the ID.
  • This transmission of the ID can be made for example by the server 101 directly to the test equipment.
  • a ticket vending machine can also directly transfer IDs of recently purchased tickets and / or entitlements to nearby test equipment so that an immediate check of an ID with a tester is possible. If, for example, a passenger at a ticket vending machine purchases a ticket directly at a bus stop, the ID of the passenger, together with the corresponding authorization, is not only transmitted to the server 101, but can also be transmitted to one or more testing devices which are in close proximity to the stop if the permission describes a validity in this zone. This makes it possible for test devices to immediately record the newly acquired ID in the list of valid IDs without first having to establish a connection between test device and server 101.
  • the method 300 shown relates to controlling and checking a ticket by means of the test apparatus, according to an embodiment of the invention.
  • a ticket is read into the tester.
  • the ID of the ticket is read from the tester, which can be done in various ways, as described earlier.
  • step 304 the tester verifies that the ID of the ticket is in the list of valid IDs stored in the tester. If this check is positive and the ID read is in the list of valid IDs, the tester recognizes in step 306 that the ticket is valid. If, on the other hand, the imported ID is not in the list valid IDs are found in the tester, then in step 308 the tester will attempt to contact the server to make a request regarding the validity of the read ID.
  • step 310 the tester verifies that the connection to the server is possible. If no connection to the server is currently possible, the method is repeated in step 312 at a later time. Alternatively, another check method for the validity of the ID can be used if no connection to the server is possible. If it is determined in step 310 that a connection to the server is successful, the test device makes a request to the server to determine if the ID is valid by the server in the current zone.
  • the tester determines in step 316 that the ticket is invalid. Otherwise, the tester determines in step 306 that the ticket is valid when a positive acknowledgment comes from the server.
  • FIG. 4 shows an overview to illustrate an extended infrastructure of a system to increase interoperability between multiple service providers.
  • the interoperability is significantly simplified.
  • the servers of the different transport companies can exchange authorizations and usage, blocking and billing for different IDs in the protected environment interoperably, without manipulation possibilities by external ones.
  • the system may include an infrastructure with multiple background systems and associated testing equipment and points of sale.
  • a background system is constructed in a similar manner as in FIG. 1 described. That is, a background system consists of at least one server in contact with at least one tester and one distribution device.
  • the individual background systems can be linked with one another using a standardized protocol.
  • a mediation plane data hub
  • intermediaries between the background systems for billing within transport networks are possible.
  • the HGS A can represent a background system for the Kunststoff region
  • the HGS B background system for the region of Berlin
  • HGS D is a background system for the region of Zurich
  • HGS E is a background system for the Paris region
  • HGS F is a background system represent for the London region.
  • the background systems may also manage other service entitlements in the respective region and are not limited to travel services.
  • This interoperable system makes it possible to purchase a valid ticket for any region from any V vendor and to have it validated for its validity.
  • the individual background systems of the various traffic exchanges exchange the IDs together with the authorizations that are useful for the corresponding background systems of the transport companies in a particular region.
  • a passenger at a distribution device V of a first traffic union can easily acquire a driving authorization for any zone in a second traffic association.
  • a passenger in Kunststoff can buy a ticket for London (HGS F) from a ticket machine belonging to HGS A.
  • the HGS A then transmits the passenger's ID along with the acquired entitlement to the HGS F for London.
  • the HGS F stores the ID along with the authorization as described above, and then transmits the valid ID to the appropriate test equipment in the zones of London for which the acquired entitlement is valid.
  • Another embodiment relates to the possible separation of service provider (DL) and sales partner (VP). This principle is in FIG. 5 shown further. According to one embodiment, it is conceivable that a part of the background systems belongs to a DL and another part of the background systems to a VP.
  • DL service provider
  • VP sales partner
  • the role of the DL is the management and referencing of the offered product, along with price and validity, such as zone, number of people, time, etc.
  • the service provider can therefore provide the general service (trips, entries, downloads, etc.) and works together with one or more sales partners VP.
  • the DL is responsible for checking the authorizations for a service, as described above.
  • the role of the VP is the processing of the purchase of an authorization and the associated linking of an ID with an authorization.
  • the VP can use IDs with link his customer master data.
  • the ID associated with one or more permissions can then be forwarded by the VP to the corresponding background systems of the DL so that the DLs can verify the permissions of the users.
  • a special case of a user authorization represents a credit in money.
  • the user can acquire services without explicit payment with the VP.
  • the second VP acts as DL of the first one managing the credit.
  • one VP will charge the other for the use of the credit.
  • a VP can grant a credit line to a user (PostPaied).
  • a VP can issue authorizations for their corresponding services for different service providers.
  • the VP does not have to issue valuable tickets, vouchers or tickets and does not have to implement or know the typical security features of such tickets, vouchers or tickets of individual different service providers.
  • a VP can only use a (known or new) ID for a user with one or more privileges for the various services of the different service providers.
  • a single system such as the VP, can make the purchase for all different services and service providers.
  • the user may purchase the various services from a single system, such as the VP, and this single system may charge the fees paid to the other service providers and services or their background systems prior to actually using the services.
  • first background system 501 may belong to a VP.
  • a user may acquire, at the vending machines V 505a-c associated with the first background system 501, entitlements that are considered entitlements to services from a first service provider and / or a second service provider.
  • the first authorization concerns a service of the first service provider and the second authorization relates to a service of the second service provider.
  • the first background system 501 then transmits the ID along with the first entitlement to the second background system 502 of the first service provider and transmits the same ID together with the second entitlement to the third background system 503 of the second service provider.
  • the corresponding background systems 502 and 503 of the two service providers may then transfer the IDs with authority to the corresponding test devices 510a to 510f, as long as they control services for assigned authorizations, as in the above FIGS. 1 to 4 described.
  • the second background system 502 and the first background system 501 may be a single background system.
  • the first background system 501 does not transmit the ID and the first permission to the second background system 502, but stores this information.

Landscapes

  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Ein Verfahren und System zum Erstellen und Auswerten einer Fahrberechtigung in einem Personenverkehrssystem ist beschrieben. Identifikationen werden mit einer ersten Berechtigung verknüpft, wobei die erste Berechtigung wenigstens eine erste Zone oder eine erste Strecke des Personenverkehrssystems betrifft und die ID in dieser ersten Zone oder auf dieser ersten Strecke als eine gültige Fahrberechtigung dient. Die ID wird mit einer zweiten Berechtigung verknüpft, die wenigstens eine zweite Zone oder eine zweite Strecke betrifft in der die ID als eine gültige Fahrberechtigung dient. Die mit einer Berechtigung verknüpfte ID wird an ein Prüfgerät zum Überprüfen der Gültigkeit von Fahrberechtigungen von Benutzern des entsprechenden Personenverkehrssystems übermittelt. Das Prüfgerät überprüft, ob eine eingelesene ID in einer in dem Prüfgerät gespeicherten Liste enthalten ist, welche IDs für gültige Fahrberechtigungen in der Zone oder auf der Strecke umfasst. Das Prüfgerät kommuniziert mit einem Hintergrundsystem, um die Liste zu empfangen oder zu aktualisieren.

Description

  • Die Erfindung betrifft im Allgemeinen ein System und Verfahren zum Erstellen und Auswerten von Nutzungsberechtigungen und im Besonderen ein System und Verfahren zum Erstellen und Auswerten von Fahrscheinen bzw. Fahrberechtigungen im öffentlichen Personenverkehr (ÖPV).
  • Klassische e-Ticketing Systeme im öffentlichen Personenverkehr (ÖPV) speichern Berechtigungen mithilfe von kryptographischen Verfahren auf Chips, die in Plastik- oder Papierkarten eingebettet werden und über Kontakte oder kontaktlos mittels Kurzstreckenfunk gelesen und beschrieben werden. Damit funktionieren diese e-Ticketing Systeme autonom, d.h. ohne jeglichen Kontakt zu einer zentralen Instanz im Netz. Der für den Betrieb nötige Aufwand ist jedoch erheblich. Da Fahrkarten in einem solchen autonomen System den Wert der Fahrkarte (in Form einer Fahrberechtigung) in sich tragen, kommt eine illegale Vervielfältigung der Fahrkarte einer Vervielfältigung von Geldscheinen gleich. Das bedeutet, dass in solchen autonomen Systemen viel Sicherheitsaufwand betrieben werden muss, um eine illegale Vervielfältigung zu verhindern.
  • Diese Kosten sinken dramatisch, wenn die Berechtigung nicht mehr auf der Karte gespeichert wird, sondern nur auf einem Server im Rechenzentrum. Dann dient die Karte, oder beispielsweise ein Barcode auf einem Handydisplay nur der Identifikation des Eigentümers und muss lediglich diese ID eindeutig und fälschungssicher vorhalten.
  • Zur Kontrolle der Berechtigung der ID ist in bestehenden Systemen eine Verbindung zum Server im Rechenzentrum erforderlich, die jedoch ausfallen kann und die den Zeitbedarf zur Prüfung erhöht und weitere Kosten verursacht. Insbesondere fordern diese bestehenden Systeme eine sehr zuverlässige, stabile und vor allem flächendeckende Datenverbindung, welche benötigt wird, um jederzeit eine Verbindung zum Rechenzentrum aufbauen zu können.
  • Jedoch gerade im öffentlichen Personenverkehr, wie beispielsweise in Bus und Bahn, gestaltet sich diese Überprüfung der ID mittels Abfrage bei einem zentralen Server schwierig. Zum einen ist nicht in jedem Gebiet des Verkehrsunternehmens die Netzinfrastruktur so gut ausgebaut, dass jederzeit eine Anfrage zum Server gestellt werden kann und weiterhin müssen Fahrgastkontrollen im öffentlichen Personenverkehr sehr zügig und schnell durchgeführt werden, was bei einer Fahrkartenkontrolle mit einer Serveranfrage für jedes einzelne Ticket nicht gewährleistet ist.
  • Eine Ausführungsform der Erfindung betrifft ein Verfahren zum Erstellen und Auswerten einer Fahrberechtigung in einem Personenverkehrssystem. Hierbei werden Identifikationen (nachfolgend auch als ID oder Kennung bezeichnet) mit einer ersten Berechtigung verknüpft, wobei die erste Berechtigung wenigstens eine erste Zone oder eine erste Strecke des Personenverkehrssystems betrifft und die ID in dieser ersten Zone oder auf dieser ersten Strecke als eine gültige Fahrberechtigung dient. Die ID wird gemäß der Ausführungsform mit einer zweiten Berechtigung verknüpft, die wenigstens eine zweite Zone oder eine zweite Strecke betrifft und die ID auch in dieser zweiten Zone oder auf dieser zweiten Strecke als eine gültige Fahrberechtigung dient. Die zweite Zone oder die zweiten Strecke kann Teil desselben Personenverkehrssystems sein. Gemäß einer weiteren Ausführungsform der Erfindung kann die zweite Zone und die zweiten Strecke auch zu einem weiteren Personenverkehrssystem gehören, welches räumlich von dem ersteren Personenverkehrssystem getrennt ist, wie etwa unterschiedliche Städte oder Verkehrsverbünde, oder welches zu einem anderen Unternehmen oder Dienstleister mit eigener Infrastruktur gehört. Die mit einer Berechtigung verknüpfte ID wird an ein Prüfgerät zum Überprüfen der Gültigkeit von Fahrberechtigungen von Benutzern des entsprechenden Personenverkehrssystems übermittelt. Das Prüfgerät kann in einem Verfahrensschritt eine ID eines Benutzers bzw. Fahrgastes einlesen. Das Prüfgerät überprüft danach, ob die eingelesene ID in einer Liste enthalten ist. Diese Liste kann hierzu lokal in dem Prüfgerät gespeichert werden und umfasst eine Vielzahl von IDs, welche in der Zone oder auf der Strecke, in der sich das Prüfgerät momentan befindet, gültige Fahrberechtigungen sind. Das Prüfgerät kann hierfür mit einem Hintergrundsystem kommunizieren, um die Liste zu empfangen oder zu aktualisieren. Dies hat den Vorteil, dass das Prüfgerät lediglich solche IDs lokal speichern muss, die in der der Zone oder auf der Strecke, in der sich das Prüfgerät momentan befindet gültige Fahrberechtigungen anzeigen. Dieses lokale Speichern der Liste mit momentan gültigen Fahrberechtigungen ermöglicht eine erhebliche Reduzierung der zu speichernden Daten in dem Prüfgerät und vermeidet, wie nachfolgende beschrieben ist, dass eine ständige Verbindung des Prüfgerätes mit einem entfernten System, wie ein Hintergrundsystem oder Server erforderlich ist.
  • Eine weitere Ausführungsform der Erfindung betrifft ein Prüfgerät zum Überprüfen der Gültigkeit von Fahrberechtigungen in einem Personenverkehrssystem. Das Prüfgerät kann Mittel zum Empfangen von einer Identifikation von einem Hintergrundsystem umfassen. Hierzu ist die ID mit einer Fahrberechtigung verknüpft, die wenigstens eine erste Zone oder eine erste Strecke des Personenverkehrssystems betrifft. Die ID dient entsprechend in dieser Zone oder auf dieser Strecke als eine gültige Fahrberechtigung. Das Prüfgerät umfasst des Weiteren Mittel zum Einlesen einer ID eines Benutzers oder Fahrgastes sowie Mittel zum Überprüfen der eingelesene ID. Hierfür speichert das Prüfgerät eine Liste mit einer Vielzahl von IDs. Gemäß einer weiteren Ausführungsform der Erfindung umfasst die in dem Prüfgerät gespeicherte Liste solche IDs, die mit gültigen Berechtigungen für eine Zone oder eine Strecke eines Personenverkehrssystems verknüpft sind, in der oder auf der sich das Prüfgerät momentan befindet. Hierfür kann vorgesehen sein, dass das Prüfgerät mit dem Hintergrundsystem kommunizieren kann, um die Liste zu empfangen oder zu aktualisieren.
  • Eine weitere Ausführungsform der Erfindung betrifft ein Verfahren zum Erstellen und Auswerten von Benutzerberechtigungen. Das Verfahren umfasst einen Schritt des Verknüpfens, in einem ersten Hintergrundsystem, einer ID mit einer ersten Berechtigung für wenigstens eine erste Dienstleistung von einem ersten Dienstleister. Das Verfahren umfasst des Weiteren einen Schritt des Verknüpfens dieser ID mit einer zweiten Berechtigung für wenigstens eine zweite Dienstleistung von einem zweiten Dienstleister, wobei die ID für die wenigstens erste und zweite Dienstleistung als eine gültige Berechtigung für einen Benutzer dient. Das Verfahren umfasst weiterhin ein Übertragen der ID und der ersten Berechtigung an ein zweites Hintergrundsystem des ersten Dienstleisters, wobei das zweite Hintergrundsystem die ID und die erste Berechtigung speichert. Ebenso kann das Verfahren die ID und die zweite Berechtigung an ein drittes Hintergrundsystem des zweiten Dienstleisters übertragen, um die ID und die zweite Berechtigung in dem dritten Hintergrundsystem zu speichern. Als weiterer Schritt kann die ID durch das zweite oder das dritte Hintergrundsystem an ein Prüfgerät zum Überprüfen der Gültigkeit von Berechtigungen von den Benutzern übermittelt werden. Das Prüfgerät kann eine ID einlesen. Des Weiteren wird mittels des Prüfgeräts überprüft, ob die eingelesene ID in einer Liste enthalten ist. Die Liste kann hierfür in dem Prüfgerät gespeichert sein und eine Vielzahl von IDs für gültige Berechtigungen enthalten. Das Prüfgerät kann des Weiteren mit mindestens dem zweiten oder dem dritten Hintergrundsystem kommunizieren, um die Liste zu empfangen oder zu aktualisieren. Weiterhin betrifft eine weitere Ausführungsform ein entsprechendes System zum Implementieren des Verfahrens.
  • Gemäß weiterer Ausführungsformen der Erfindung ist ein computerlesbares Medium mit computerlesbaren Instruktionen vorgesehen, welche, wenn sie ausgeführt werden, eines der zuvor und nachfolgend beschriebenes Verfahren ausführen.
  • Es sei hier erwähnt, dass die Ausführungsformen der Erfindung im Allgemeinen Berechtigungen für alle möglichen Dienstleistungen betreffen. Auch wenn die folgende Beschreibung anhand eines Personenverkehrssystems beschrieben ist und von Fahrberechtigungen in Form von Fahrscheinen oder Fahrkarten die Rede ist, so ist dabei grundsätzlich immer auch der allgemeine Begriff "Berechtigung" gemeint, was ebenfalls Dienstleistungen wie Taxifahrten, Dienstleistungen von Reiseunternehmern, Mietwagenfahrten, Schifffahrten und/oder Flüge mit einschließt. Aber auch allgemeinere Berechtigungen können unter den Begriff Berechtigung fallen, wie beispielsweise Kino- oder Theaterkarten, Schwimmbadbesuche, Web-Downloads, Hotelreservierungen, Einkaufsberechtigungen und so weiter.
  • Dadurch ermöglicht sich ein Verkauf von Reiseketten: Verknüpfung der ID mit mehreren Produkten bei unterschiedlichen Dienstleistern.
  • Erfindungsgemäße Ausführungsformen werden anhand der nachfolgenden Zeichnungen beschrieben. Es zeigen:
    • Figur 1
    eine Übersicht über das Konzept und einen Teil der Infrastruktur, gemäß einer Ausführungsform der Erfindung,
    Figur 2
    ein Ablaufdiagramm für ein Verfahren, welches das Erstellen einer Fahrkarte beschreibt,
    Figur 3
    ein Ablaufdiagramm für ein Verfahren, welches das Kontrollieren und Überprüfen einer Fahrkarte mittels eines Prüfgeräts beschreibt,
    Figur 4
    eine Übersicht zur Veranschaulichung einer erweiterten Infrastruktur eines Systems zur Steigerung der Interoperabilität zwischen mehreren Dienstleistern, und
    Figur 5
    eine Übersicht zur Veranschaulichung einer erweiterten Infrastruktur eines Systems zur Steigerung der Interoperabilität zwischen mehreren Dienstleistern, durch die Aufteilung in einen Vertriebspartner und mehrere Dienstleister.
  • Unter Bezug auf die Figuren ist im Folgenden ein System und ein Verfahren beschrieben, mit denen es möglich ist, schnell, zuverlässig und sicher Berechtigungen (z.B. Fahrkarten) für verschiedenste Dienstleistungen von verschiedenen Dienstleistern zu erwerben, zu erstellen und auszuwerten.
  • Grundsätzlich sind die Ausführungsformen der Erfindung auf alle Aspekte anwendbar, die mit dem sicheren Bezug von vorausbezahlten oder zahlungsgesicherten Leistungen zu tun haben. Dies gilt insbesondere dann, wenn an der Leistungserbringung mehrere Dienstleister beteiligt sind. Dadurch wird ein global interoperables Berechtigungssystem erschaffen, was eine Verkettung von Dienstleistungen erschaffen kann, die über einen Vertriebspartner abgerechnet werden kann.
  • Die im Nachfolgenden beschriebenen Ausführungsformen nutzen das Prinzip der Identifikation (ID) als Basis für ausgestellte Fahrkarten. Bei diesem Prinzip wird die Ticketinformation (also die Beschreibung von Berechtigungen, welche Dienstleistung, welcher Eintritt, welche Verkehrsmittel etc. wann und wo genutzt werden dürfen) nicht mehr auf der Fahrkarte direkt gespeichert, sondern zunächst in einem Server in einem Rechenzentrum. Die Fahrkarte dient lediglich als eine Identifikation, welche in einem Server mit einer bestimmten Berechtigung verknüpft ist. Es ist somit kein werthaltiger Schreibvorgang mehr nötig, um Fahrkarten zu bedrucken, da dieser Wert (die Berechtigung) nicht mehr auf der Fahrkarte selber gespeichert oder vermerkt wird.
  • Der Fahrschein (oder die Fahrkarte) kann dabei nun verschiedenartige Formen annehmen. Zum einen kann ein Fahrschein eine Karte sein, in welcher ein RFID-Chip eingebettet ist und eine zweifelsfreie Identifikation erlaubt. Solche RFID-Karten können mit Standard Lesegeräten nach ISO 14443 A/B schnell ausgelesen werden. Die RFID Karten können dabei von einem Verkehrsunternehmen ausgegeben und jederzeit wieder verwendet werden. Alternativ kann ein Fahrgast jedoch auch selber eine Karte mit einer eindeutigen RFID-Kennung mitbringen, welche dann als Fahrkarte genutzt werden kann. In alternativen oder zusätzlichen Ausführungsformen kann der Fahrschein auch auf dem Handy eingebettet sein, zum Beispiel in Form einer NFC-Identifikation oder durch Anzeigen eines QR-Scancodes. Weiterhin kann der Fahrschein auch in personalisierter Form sein, wie beispielsweise in Form einer Kreditkarte oder eines Ausweisdokuments des Fahrgastes. Wichtig dabei ist lediglich die Eindeutigkeit der ID des Fahrscheins.
  • Anstatt nun die Gültigkeit eines Fahrscheins mittels einer Anfrage zum Server zu überprüfen, wird im hierin beschriebenen System die ID des Fahrscheins mit einer Liste von gültigen IDs in einem Prüfgerät abgeglichen. Um dies zu ermöglichen, ist es wichtig, dass das Prüfgerät Kenntnis über alle gültigen IDs hat, welche sich in der gleichen Zone befinden, in der sich auch das Prüfgerät befindet. Genauer bedeutet dies, dass das Prüfgerät die Gültigkeit eines Fahrscheins lokal prüft, indem es die ID des Fahrscheins mit intern gespeicherten IDs abgleicht. Dazu ist es nötig, dass das Prüfgerät regelmäßig - jedoch nicht notwendigerweise ununterbrochen - alle gültigen Fahrkarten in der zu überprüfenden Zone kennt.
  • Tatsächlich benötigen die Ausführungsformen der Erfindung nicht zwangsläufig, dass alle gültigen IDs für eine ganze Region (z.B. für den ganzen Verkehrsbund) in einem Prüfgerät gespeichert sind, sondern lediglich diejenigen IDs sollten in einem Prüfgerät vorhanden sein, die in der entsprechenden Zone (Gültigkeitszone) gültig sind, in welcher sich das Prüfgerät selbst befindet. Das heißt, wenn sich ein Kontrolleur mit einem Prüfgerät in der Zone "Z1" befindet, so sind idealerweise in dem Prüfgerät auch nur die IDs gespeichert, die in der Zone Z1 zu diesem Zeitpunkt gültig sind. In alternativen Ausführungsformen können auch mehr oder weniger IDs in dem Prüfgerät aufgelistet sein, wie weiter unten beschrieben.
  • Der hierin benutzte Begriff "Zone" bezieht sich im Allgemeinen auf einen Gültigkeitsbereich. Zum Beispiel ist eine Region (beispielsweise eine Stadt mit Umland) in verschiedene Zonen eingeteilt. Im Speziellen kann es aber auch sein, dass eine Zone nicht nur einen bestimmten Abschnitt oder Teil in der Region beschreibt, sondern auch eine Richtung eines Verkehrsmittels in dem Teil oder dem Abschnitt der Region. So kann beispielsweise die Zone "München: Marienplatz - Odeonsplatz" eine andere Zone beschreiben als "München: Odeonsplatz - Marienplatz". Somit ist der Begriff "Zone" beliebig skalierbar und kann eine ganze Region, eine Stadt, einen Stadtteil, eine Menge an Haltestellen oder einzelne Strecken beschreiben.
  • Ein Prüfgerät gemäß einer Ausführungsform der Erfindung kann ein mobiles Prüfgerät sein, welches von einem Kontrolleur getragen werden kann, um spontane Überprüfungen von Fahrscheinen durchzuführen. Das Prüfgerät kann aber auch ein Teil eines stationären Kontroll- oder Einlasssystems sein. Beispielsweise kann das Prüfgerät auch in Verbindung mit einem Drehkreuz oder einer Durchgangssperre realisiert werden. In weiteren Ausführungsformen kann das Prüfgerät fest in einem Verkehrsmittel (Bus, Bahn, etc.) angebracht sein und vom Fahrgast fordern, dass dieser sich mit der Fahrkarte in dem Verkehrsmittel einloggt, sobald er einsteigt. Das Prüfgeräts der vorliegenden Erfindung umfasst einen internen Speicher, mindestens eine drahtlose Kommunikationseinheit (Mobilfunk, WLAN etc.), einen Prozessor und wenigstens eine Einleseeinheit zum Einlesen einer ID einer Fahrkarte. Mögliche Einleseeinheiten können sein: Kamera, Laser oder Laserscanner, NFC-Leser, RFID-Leser, herkömmlicher Kartenleser, Bluetoothschnittstelle, Infrarotschnittstelle, Tastatur, Touchscreen usw. Des Weiteren kann das Prüfgerät auch ein Ortserfassungssystem umfassen, welches jederzeit die aktuelle Zone erfasst, in welchem sich das Prüfgerät befindet. Dieses Ortserfassungssystem kann beispielsweise GPS sein. In alternativen Ausführungsformen ist es aber auch möglich, dass das Ortserfassungssystem aus einem Sensor besteht, mittels dem sich ein Kontrolleur mit dem Prüfgerät an entsprechenden Ortspunkten eingecheckt. Zum Beispiel kann ein Kontrolleur sich mit seinem Prüfgerät an einer bestimmten Haltestelle einchecken, an welcher über den Sensor eine Ortsinformation an das Prüfgerät übermittelt wird, wodurch dem Prüfgerät die aktuelle Zone mitgeteilt wird. Jedoch sind auch weitere Ortserfassungssysteme für das Prüfgerät denkbar. Außerdem ist auch denkbar, dass ein Kontrolleur die aktuelle Zone, in welcher er sich befindet, manuell in das Prüfgerät eingibt oder ein Fremdsystem die Ortungsinformation an das Prüfgerät übermittelt.
  • Vorzugsweise übermittelt das Prüfgerät auch den Ort (die Zone) des Prüfgeräts an den Server, so dass der Server die Liste gültiger IDs für das Prüfgerät managen kann und dem Prüfgerät die entsprechenden IDs zur Verfügung stellen kann.
  • Für kurzfristig gültige Berechtigungen, d.h. Berechtigungen (z.B. Fahrberechtigungen), die kurzfristig (z.B. am Bahnsteig) gekauft wurden und sofort benutzt werden sollen, kann auch eine direkte, lokale Kommunikation zwischen einem Verkaufsgerät (z.B. Fahrkartenautomat) und dem Prüfgerät möglich sein, wie weiter unten beschrieben. Zum Beispiel kann das Prüfgerät direkt von einem Fahrkartenautomaten eine neue ID mit Berechtigung übermittelt bekommen, welche in der Zone des Prüfgeräts sofort gültig ist.
  • In den folgenden Figuren wird das oben beschriebene Konzept weiter verdeutlicht. Dabei sollte stets berücksichtigt werden, dass das beschriebene Konzept für alle denkbaren Dienstleistungen und deren Berechtigung(en) herangezogen werden kann und sich nicht nur auf den Gebrauch von Fahrkarten, Fahrscheinen, oder Fahrberechtigungen in einem Personenverkehrssystem beschränkt.
  • Im Speziellen kann ein Fahrgast das System für diesen Zweck des Personenverkehrs nutzen. Dabei gibt ein Fahrgast Startpunkt, Ziel und Zeitraum für eine geplante Fahrt oder Reise an (z.B. an einem Fahrkartenautomat, oder über Internet, Eingabeterminal etc.) und das beschriebene System bietet verschiedene Routen mit verschiedenen Verkehrsmitteln (Taxi, Bus, Zug, Flugzeug, Seilbahn, Schiff, Rikscha, Mietwagen, etc.) in dem gewünschten Zeitraum an. Nach der Auswahl der Reiseroute und entsprechender Zustimmung werden alle erforderlichen Fahrkarten (bzw. die Berechtigungen dafür) gekauft und/oder reserviert und dann mit einer ID verknüpft, wie beschrieben.
  • Figur 1 zeigt eine Übersicht über das Konzept und einen Teil der Infrastruktur, gemäß der vorliegenden Erfindung. Figur 1 zeigt ein System 100, welches einen Server 101 im Hintergrundsystem (z.B. in einem Rechenzentrum) zeigt, in welchem IDs mit Berechtigungen verknüpft werden. Beispielsweise sind in Figur 1 die ID1 110 und die ID2 120 dargestellt, wie sie jeweils mit den entsprechenden Berechtigungen 120 und 122 verknüpft sind. Selbstverständlich können auch weitere IDs in dem Server 101 gespeichert und mit Berechtigungen verknüpft sein, denn die vorliegende Erfindung ist nichts auf eine bestimmte Anzahl auf dem Server 101 gespeicherte IDs beschränkt. Eine Berechtigung 120 (und auch 122) enthält verschiedene Informationen. Eine wesentliche Information der Berechtigung 120 ist der Gültigkeitsbereich des Fahrscheins, welcher mit der ID1 110 verknüpft ist. In dem Beispiel aus Figur 1 beschreibt die Berechtigung 120, dass der Fahrschein in den Zonen I und II gültig ist. Eine weitere Information in der Berechtigung kann ein Zeitraum sein, in welchem der Fahrschein in den besagten Zonen, oder der besagten Zone gültig ist (Gültigkeitszeitraum). Im obigen Beispiel also beschreibt die Berechtigung 120, welche mit der ID1 110 verknüpft ist, dass der Fahrschein mit der ID1 am 8.11.2014 in der Zone I und II gültig ist. In gleicher Weise ist die ID2 112 mit der entsprechenden Berechtigung 122 verknüpft. Die Berechtigung 122 beschreibt, dass ein Fahrschein mit der ID2 112 in den Zonen II, III und IV gültig ist, und zwar am 8.11.2014 zwischen 14:25 Uhr und 16:25 Uhr. Auch wenn in dem obigen Beispiel nur die Zone und die Gültigkeitsdauer als Informationen in einer Berechtigung auf dem Server 101 beschrieben sind, so ist die vorliegende Erfindung nicht darauf beschränkt. Weitere Informationen können in den entsprechenden Berechtigungen beschrieben sein, wie beispielsweise eine Beschreibung der Verkehrsmittel, welche benutzt werden dürfen (zum Beispiel Bus, Straßenbahn und U-Bahn, aber keine S-Bahn).
  • In weiteren Ausführungsformen kann eine ID auch mit mehreren Berechtigungen verknüpft sein. Beispielsweise kann eine erste Berechtigung eine Dienstleistung eines ersten Dienstleisters umfassen und eine zweite Berechtigung kann eine Dienstleistung eines zweiten Dienstleisters umfassen. Die ID kann dann mit sowohl der ersten Berechtigung, als auch der zweiten Berechtigung verknüpft sein. Diese Verknüpfungen zwischen ID und einer entsprechenden Berechtigung können dann getrennt voneinander an entsprechende Hintergrundsysteme (z.B. Server) der entsprechenden Dienstleister übertragen werden. Das heißt, die Verknüpfung der ID mit der ersten Berechtigung wird an den ersten Dienstleister übertragen und die Verknüpfung der ID mit der zweiten Berechtigung wird an den zweiten Dienstleister übertragen.
  • Die Verknüpfung einer ID mit einer Berechtigung im Server 101 kann durch den Kauf einer Fahrkarte im beschriebenen System geschehen. Ein Fahrgast kann beispielsweise eine Fahrkarte erwerben, mit welcher er öffentliche Verkehrsmittel in einer bestimmten Zone innerhalb einer bestimmten Zeit nutzen darf. Dieser Erwerb der Fahrkarte kann auf verschiedene Arten geschehen. Zum Beispiel kann der Fahrgast an einem Fahrkartenautomat eine Fahrkarte erwerben, woraufhin der Fahrkartenautomat dem Fahrgast eine Fahrkarte mit einer eindeutigen ID ausgibt, z.B. eine RFID-Chipkarte oder in Form eines Barcodes auf Papier, und gleichzeitig die Information über die ausgestellte ID und die erworbene Berechtigung an den Server 101 überträgt. Daraufhin kann der Server 101 die vom Fahrkartenautomat übermittelte ID mit der Berechtigung verknüpfen und speichern. Alternativ kann die Fahrkarte auch online durch den Fahrgast erworben werden, zum Beispiel am Computer oder per Handy. Das System kann dem Fahrgast dann eine eindeutige ID zuweisen, zum Beispiel in Form eines QR-Codes zum Ausdrucken oder zum darstellen auf einem Handydisplay, oder Handys mit integriertem NFC-Chip, oder Bluetooth-Modul, oder Infrarot Schnittstelle können zum Übertragen einer digitalen ID benutzt werden. Außerdem kann der Fahrgast beim Kauf einer Fahrberechtigung eine bereits bestehende ID angeben. Diese mitgebrachte ID kann bereits im Server 101 bekannt sein und gegebenenfalls schon mit einer Berechtigung verknüpft sein. Diese bereits bestehende Berechtigung für die ID des Fahrgastes kann dann vom Server 101 um die neu erworbene Berechtigung erweitert werden. Dieses Konzepts der Wiederverwendung bestehender IDs ist nicht zwangsläufig auf den Fahrkartenkauf per Handy oder Computer beschränkt, sondern kann auch am Fahrkartenautomat erfolgen. Beispielsweise kann die ID einer bereits vorhandenen Fahrkarte an einem Fahrkartenautomat eingelesen werden und mit weiteren Berechtigungen verknüpft werden. Zusätzlich gibt es auch die Möglichkeit, dass der Fahrgast ein eigenes Fahrkartenmedium mitbringt, welches dazu in der Lage ist, eindeutig identifiziert zu werden. Dies kann beispielsweise ein Ausweisdokument, eine Kreditkarte, oder etwas ähnliches sein, was sich vorzugsweise per RFID auslesen lässt. Selbst wenn das Identifikationsmedium noch nicht im Server 101 bekannt ist, kann es sofort bei der erstmaligen Nutzung zum Kauf einer Berechtigung im Server 101 hinzugefügt werden, wenn das Identifikationsmedium bestimmte, vom Betreiber zugelassene Kriterien erfüllt.
  • Eine ID kann mit mehreren Berechtigungen verknüpft werden. Damit können z.B. Fahrscheine in verschiedenen Regionen oder ganz allgemein Dienstleistungen bei verschiedenen Dienstleistern auf einer ID abgebildet werden.
  • Wenn der Server 101 im Hintergrundsystem eine neue ID mit einer entsprechenden Berechtigung verknüpft hat, so kann der Server 101 die ID an eine oder mehrere Zonen übertragen, für welche die Berechtigung der ID eine Gültigkeit beschreibt. Im obigen Beispiel bedeutet dies, dass der Server 101 die ID1 110 an die Zone I 130 und an die Zone II 140 überträgt, und die ID2 112 an die Zone II 140 überträgt. Um genauer zu sein, überträgt der Server 101 die entsprechenden IDs an Prüfgeräte 131 und 141, welche sich in den entsprechenden Zonen 130 und 140 befinden. Diese Übertragung der IDs kann direkt vom Server 101 auf die entsprechenden Prüfgeräte 131 und 141 geschehen, es können jedoch auch ein oder mehrere Server dazwischen geschaltet sein, um eine beliebig große Skalierbarkeit auf mehrere Verkehrsunternehmen zu realisieren, wie weiter unten mit Bezug auf Figur 4 beschrieben. Auch wenn in Figur 1 nur ein Prüfgerät pro Zone dargestellt ist, sollte es dem Fachmann klar sein, dass auch mehrere Prüfgeräte gleichzeitig in einer Zone sein können. In solch einem Fall überträgt der Server 101 (oder ein zwischen geschalteter Server) an alle Prüfgeräte in einer bestimmten Zone die ID, welche in der entsprechenden Zone gültig ist.
  • Wenn das Prüfgerät die ID vom Server 101 (oder von einem zwischengeschalteten Server) empfängt, speichert es diese ID zusammen mit der Berechtigung in einer lokalen Liste. Dies erfordert, dass das Prüfgerät regelmäßig - jedoch nicht zwangsläufig ununterbrochen - eine Datenverbindung mit dem Server 101 (oder einem zwischengeschalteten Server) haben muss. Diese Datenverbindung kann beispielsweise über das Mobilfunknetz geschehen, oder über WLAN, ein anderes Datenfunknetz, z.B. Tetra, oder mehrere. Zur Verbesserung der Netzabdeckung kann ein Prüfgerät, gemäß der vorliegenden Erfindung, auch mehrere SIM-Karten oder eine Multi-Netz-SIM-Karte umfassen. Außerdem können an bestimmten Punkten (zum Beispiel an ausgewählten, oder an allen Haltestellen) auch WLAN-Hotspots errichtet werden, so dass spätestens an einer solchen Haltestelle die Liste gültiger IDs in dem Prüfgerät aktualisiert werden kann. Damit ist die Aktualität der lokal im Prüfgerät gespeicherten Liste während der Fahrt bis zur nächsten Haltestelle sicher gestellt, denn wenn die Tür zu ist, dürfen in einer Ausführungsform keine neuen Tickets mehr gekauft werden, d.h. während der Fahrt muss die Liste gültiger IDs nicht zwingend auf dem neuesten Stand sein.
  • Sobald ein Prüfgerät mit dem Server 101 (oder mit einem zwischengeschalteten Server) verbunden ist, wird eine aktualisierte Liste gültiger IDs mit Berechtigung an das Prüfgerät übertragen. Diese Aktualisierung der Liste gültiger IDs/Berechtigung, die in den entsprechenden Prüfgeräten gespeichert sind, erfolgt vorzugsweise durch eine Übertragung von Änderungen in der Liste. Dies bedeutet, dass nicht bei jeder Verbindung zum Server 101 (oder einem zwischengeschalteten Server) die komplette Liste gültiger IDs/Berechtigung an ein entsprechendes Prüfgerät übertragen werden muss. Sondern nur diejenigen IDs/Berechtigung werden vom Server 101 (oder einem zwischengeschalteten Server) an das Prüfgerät übertragen, die in der Zone des Prüfgeräts gültig sind und noch nicht im Prüfgerät gespeichert sind.
  • Die Liste gültiger IDs/Berechtigung in einem Prüfgerät kann immer dann auf den neuesten Stand gebracht werden, sobald das Prüfgerät Verbindung zum Server 101 (oder einem zwischengeschalteten Server) aufnehmen kann. Alternativ kann die Liste auch in vorbestimmten Zeitintervallen aktualisiert werden, zum Beispiel einmal pro Minute oder alle 5 Minuten etc.
  • Verfällt die Gültigkeit einer Berechtigung für eine Zone, so kann der Server 101 (oder ein zwischengeschalteter Server) an die entsprechenden Prüfgeräte der Zone auch die Anweisung zur Löschung der entsprechenden Berechtigung und damit auch der ID übertragen. In alternativen Ausführungsformen kann ein Prüfgerät auch selbstständig feststellen, dass eine ID nicht mehr die Berechtigung für die entsprechende Zone hat und kann diese ID aus der Liste gültiger IDs des Prüfgeräts entfernen. Es können auch diese beiden Möglichkeiten miteinander kombiniert werden und somit kann entweder das Prüfgerät selbst die nicht mehr gültige ID aus der Liste gültiger IDs löschen, oder das Prüfgerät empfängt den Befehl zur Löschung der nicht mehr gültigen ID vom Server, je nachdem welches Ereignis zuerst eintritt.
  • Für den Verfall der Gültigkeit einer ID kann es verschiedene Gründe geben. Ein Grund für den Verfall der Gültigkeit einer ID kann sein, dass der Gültigkeitszeitraum abgelaufen ist, welcher in der mit der ID verknüpften Berechtigung beschrieben ist. Beispielsweise würde die Gültigkeit der ID2 112 aus Figur 1 in den Zonen II, III und IV am 8.11.2014 um 16:26 Uhr ablaufen, woraufhin die ID aus allen Prüfgeräten in den Zonen II, III und IV zu diesem Zeitpunkt aus der Liste gültiger IDs gelöscht wird.
  • Ein weiterer Grund für den Verfall der Gültigkeit einer ID kann sein, dass das Prüfgerät von einer ersten Zone in eine zweite Zone begibt, wobei die verknüpfte Berechtigung besagter ID in der ersten Zone gültig ist, aber nicht in der zweiten Zone. In diesem Fall können aus der Liste gültiger IDs des Prüfgeräts alle IDs gelöscht werden, welche in der zweiten Zone nicht gültig sind. Wenn beispielsweise das Prüfgerät 141 aus Figur 1 von der Zone II in die Zone I geht, so wird die ID2 aus dem Prüfgerät 141 gelöscht da diese in der Zone I keine Berechtigung aufweist. Alternativ können in dem Fall, dass ein Prüfgerät sich von einer ersten Zone in eine zweite Zone begibt IDs beibehalten werden, obwohl sie in der zweiten Zone nicht mehr gültig sind. In diesem Fall werden die in der zweiten Zone ungültigen IDs jedoch im Prüfgerät als ungültig markiert. Sollte sich das Prüfgerät danach wieder in die erste Zone begeben, so müssen die als ungültig markierten IDs nicht erneut vom Server ermittelt oder herunter geladen werden, sondern lediglich die Ungültigkeitsmarkierungen entfernt werden.
  • Ein weiterer Grund für den Verfall der Gültigkeit einer ID kann sein, dass eine ID vom Server 101 (oder einem zwischengeschalteten Server) gesperrt wurde. Wenn zum Beispiel vom System erkannt wird, dass eine Fahrkarte unerlaubt vervielfältigt wurde und somit quasi zwei Fahrkarten mit identischer ID im Umlauf sind, so kann die ID gesperrt werden. Dies hat zur Folge, dass die gesperrte ID in keinem Prüfgerät auf der Liste gültiger IDs gespeichert ist. In alternativen Ausführungsformen kann an entsprechende Prüfgeräte (in den entsprechenden Zonen) auch eine Liste gesperrter IDs übertragen werden, womit Betrugsversuche sofort aufgedeckt werden können. Die Liste erlaubter IDs in einem Prüfgerät kann auch, gemäß einer Ausführungsform der Erfindung, vor der nächsten Haltestelle ausgewertet werden, um zu überprüfen, ob die IDs in der Liste an dieser Haltestelle gültig sind.
  • Wenn ein Prüfgerät eine Fahrkarte kontrolliert (einliest), ermittelt das Prüfgerät die ID der Fahrkarte und durchsucht die Liste gültiger IDs nach der ID der eingelesenen Fahrkarte. Erkennt das Prüfgerät, dass sich die eingelesene ID der Fahrkarte auch in der Liste gültiger IDs befindet, so erkennt das Prüfgerät, dass die Fahrkarte gültig ist. Auf der anderen Seite, wenn die ID der eingelesenen Fahrkarte nicht in der lokal gespeicherten Liste gültiger IDs in dem Prüfgerät gefunden wird, so ist dies ein Indiz dafür, dass die Fahrkarte ungültig ist. Das Prüfgerät kann in einem solchen Fall versuchen, eine gezielte Anfrage beim Server 101 (oder einem zwischengeschalteten Server) zu stellen, um online nachzuprüfen, ob eine entsprechende Berechtigung in der aktuellen Zone für die eingelesene ID der Fahrkarte existiert. Das Ergebnis dieser Onlineabfrage kann das Prüfgerät direkt anzeigen. Ein Ergebnis dieser Anfrage kann sein, dass die Verbindung zum Server erfolgreich hergestellt werden konnte und eine entsprechende Berechtigung vom Server 101 (oder einem zwischengeschalteten Server) als gültig verifiziert werden konnte. Ein anderes Ergebnis dieser Anfrage kann sein, dass die Verbindung zum Server erfolgreich hergestellt werden konnte, jedoch keine entsprechende Berechtigung auf dem Server gefunden wurde, welche mit der ID der Fahrkarte verknüpft ist. Ein anderes Ergebnis dieser Anfrage kann sein, dass aus verschiedenen Gründen keine Verbindung zum Server hergestellt werden konnte, wodurch weitere Schritte zur Verifizierung der Fahrkarte unternommen werden können, oder der Vorgang noch einmal wiederholt wird.
  • Durch das beschriebene Verfahren wird erreicht, dass die Liste gültiger IDs in den Prüfgeräten für deren Einsatzgebiete optimiert werden, wodurch die Liste gültiger IDs möglichst klein gehalten wird. Das heißt, dass die Liste gültiger IDs nur die IDs beinhaltet, die im entsprechenden Einsatzgebiet (in der entsprechenden Zone) gültig sind. Dadurch kann erreicht werden, dass die Suchzeiten und damit die Prüfzeiten minimiert werden. Ein weiteres Resultat der kleinen Liste gültiger IDs ist auch, dass die Datenübertragungsmenge und damit die Kosten dafür minimiert werden. Diese Zusammenstellung der Liste erfolgt im Allgemeinen für ein oder mehrere Prüfgeräte im Hintergrund, zum Beispiel im Server 101. Die Server im Hintergrund sind für bestimmte Gruppen von Prüfgeräten zuständig, d.h. die Bereitstellung der Listen gültiger IDs kann auf mehrere Server im Hintergrund verteilt werden. Damit ist es möglich, das System auf beliebig große Regionen auszuweiten und zu realisieren.
  • In einer weiteren Ausführungsform der Erfindung wird in einem Prüfgerät ein Protokoll über die geprüften IDs angelegt. Dieses Prüfprotokoll kann in regelmäßigen Abständen an den Server 101 im Hintergrund übertragen werden, um eine Doppelnutzung einer ID schnell zu erkennen. Wenn beispielsweise eine ID1 an einem Ort r1 zum Zeitpunkt t1 von einem Prüfgerät erfasst wird, also ID1(r1, t1), und die selbe ID1 an einem anderen Ort r2 zu einem Zeitpunkt t2 erfasst wird, also ID1(r2, t2), so wird auf dem Server 101 überprüft, ob es möglich ist, vom Ort r1 zum Ort r2 in der Zeit T=t2-t1 zu gelangen. Wenn festgestellt wird, dass die zwei Orte r1 und r2 zu weit voneinander entfernt sind, als dass es möglich wäre in der Zeit T=t2-t1 vom einen Ort zum anderen Ort zu gelangen, so wird auf eine doppelte Nutzung ein und derselben ID geschlossen. Dies bedeutet, dass eine ID vervielfältigt wurde, wodurch diese ID als ungültig gekennzeichnet werden kann. In alternativen Ausführungsformen kann die ID auch von einem zweiten Prüfgerät gelöscht werden (z.B. mittels Befehl vom Server), wenn die ID gerade von einem ersten Prüfgerät in einer entfernten Zone eingelesen wurde. Die ID kann dann nach Ablauf einer berechneten Zeit wieder an das zweite Prüfgerät übertragen werden.
  • Ein Vorteil des hierin beschriebenen Systems ist, dass elektronische Fahrkarten auf ihre Gültigkeit hin überprüft werden können, auch wenn das dazu notwendige Prüfgerät keinen ununterbrochenen Kontakt zu einem Server hat, welcher die entsprechenden Berechtigungen der elektronischen Fahrkarten kennt und speichert. Gerade in ländlichen Regionen, aber auch in U-Bahnen unter der Erde, oder anderen Fahrzeugen in Tunneln ist eine Funk-Netzabdeckung nicht immer unterbrechungsfrei gewährleistet. Somit gestaltet sich im öffentlichen Personenverkehr die Gültigkeitsanfrage von einem Prüfgerät an einen zentralen Server über das Mobilfunknetz oftmals schwierig. Da aber bei Fahrkartenkontrollen eine schnelle Prüfung von Fahrtberechtigungen für einen hohen Durchsatz (d.h. für schnellen Einstieg oder viele Kontrollen) notwendig ist, ist eine solche Serveranfrage selbst bei guter Netzabdeckung eine zu zeitintensive Prozedur. Die hierin beschriebene Gültigkeitsprüfung von Fahrkarten erfordert gerade keine Serveranfrage für jede einzelne Fahrkarte, sondern die Prüfung erfolgt gegen eine Liste gültiger IDs, welche die Prüfgeräte lokal gespeichert haben. Diese Prüfprozedur ist effizienter, weniger fehleranfällig und schneller, als eine Onlineabfrage für jede einzelne Fahrkarte.
  • Figur 2 zeigt ein Verfahren 200, gemäß einer Ausführungsform der Erfindung, welches das Erstellen einer Fahrkarte beschreibt. Im Schritt 202 erwirbt der Fahrgast eine Fahrkarte. Dies kann auf verschiedene Arten geschehen, wie bereits beschrieben. Beispiele hierfür sind Fahrkartenautomaten, per Internet, an Vorverkaufsstellen, beim Fahrer direkt im Fahrzeug, etc.
  • Im Schritt 204 wird während des Kaufvorgangs überprüft, ob der Fahrgast bereits eine bestehende ID hat. Beispielsweise kann ein Fahrgast dem Verkaufssystem (zum Beispiel dem Fahrkartenautomat) eine bereits bestehende ID präsentieren, welche auch schon mit Berechtigungen verknüpft sein kann. Dazu kann der Fahrgast die bereits vorhandene ID beispielsweise über eine Tastatur eingeben, oder die ID mittels der bereits vorhandenen Fahrkarte von dem Verkaufssystem (zum Beispiel dem Fahrkartenautomat) einlesen lassen. Wird im Schritt 204 festgestellt, dass keine ID bereits vorhanden ist, so wird im Schritt 206 eine ID für den Fahrgast erstellt. Diese ID kann anonym sein, kann aber auch personengebunden sein. Zum Beispiel kann der Fahrkartenautomat eine RFID-Chipkarte mit einer eindeutigen ID ausstellen und an den Fahrgast übergeben, aber auch Papiertickets mit beispielsweise einem Scanncode oder einem normalen Code ist als nichtabschließendes Beispiel denkbar.
  • Im Schritt 208 wird die ID des Fahrgastes mit einer entsprechenden Berechtigung verknüpft, die der Fahrgast durch den Kaufvorgang erworben hat. Wenn bereits eine ID besteht, die mit einer Berechtigung verknüpft ist, so kann diese Berechtigung erweitert werden. Das kann durch Anpassung der Berechtigung geschehen, oder durch eine zusätzliche Verknüpfung im Server mit einer weiteren Berechtigung. Diese Verknüpfung der eindeutigen ID mit der entsprechenden Berechtigung geschieht vorzugsweise im Server 101 aus Figur 1, kann jedoch auch schon bereits in einem Fahrkartenautomat geschehen und danach an den Server 101 übertragen werden.
  • Im Schritt 210 wird die ID an diejenigen Prüfgeräte übermittelt, die sich in den Zonen befinden, für welche die verknüpfte Berechtigung eine Gültigkeit der ID beschreibt. Diese Übertragung der ID kann zum Beispiel vom Server 101 direkt an die Prüfgeräte vorgenommen werden. In alternativen Ausführungsformen kann auch ein Fahrkartenautomat direkt IDs von kürzlich erworbenen Fahrkarten und/oder Berechtigungen an nahe gelegene Prüfgeräte übertragen, so dass eine sofortige Kontrolle einer ID mit einem Prüfgerät möglich ist. Erwirbt beispielsweise ein Fahrgast an einem Fahrkartenautomat direkt an einer Haltestelle eine Fahrkarte, so wird die ID des Fahrgastes zusammen mit der entsprechenden Berechtigung nicht nur an den Server 101 übertragen, sondern kann zusätzlich auch an ein oder mehrere Prüfgeräte übertragen werden, welche sich in direkter Nähe zu der Haltestelle befindet, falls die Berechtigung eine Gültigkeit in dieser Zone beschreibt. Dadurch kann erreicht werden, dass Prüfgeräte die neu erworbene ID sofort in der Liste gültiger IDs aufnehmen, ohne dass vorher eine Verbindung zwischen Prüfgerät und Server 101 aufgebaut werden muss.
  • Das in Figur 3 gezeigte Verfahren 300 betrifft das Kontrollieren und Überprüfen einer Fahrkarte mittels des Prüfgeräts, gemäß einer Ausführungsform der Erfindung. Im Schritt 302 wird eine Fahrkarte in das Prüfgerät eingelesen. Um genauer zu sein, wird die ID der Fahrkarte von dem Prüfgerät ausgelesen, was auf verschiedene Arten geschehen kann, wie bereits beschrieben.
  • Im Schritt 304 überprüft das Prüfgerät, ob sich die ID der Fahrkarte in der Liste gültiger IDs befindet, die in dem Prüfgerät gespeichert ist. Sollte diese Überprüfung positiv ausfallen und die eingelesene ID sich in der Liste gültiger IDs befinden, so erkennt das Prüfgerät im Schritt 306, dass die Fahrkarte gültig ist. Sollte hingegen die eingelesene ID nicht in der Liste gültiger IDs im Prüfgerät gefunden werden, so wird das Prüfgerät im Schritt 308 versuchen, den Server zu kontaktieren, um dort eine Anfrage bezüglich der Gültigkeit der eingelesenen ID vorzunehmen.
  • Im Schritt 310 überprüft das Prüfgerät, ob die Verbindung zum Server möglich ist. Sollte aktuell keine Verbindung zum Server möglich sein, so wird das Verfahren im Schritt 312 zu einem späteren Zeitpunkt wiederholt. Alternativ kann auch ein anderes Prüfverfahren zur Gültigkeit der ID herangezogen werden, wenn keine Verbindung zum Server möglich ist. Wird im Schritt 310 festgestellt, dass eine Verbindung zum Server erfolgreich ist, stellt das Prüfgerät eine Anfrage zum Server, um festzustellen ob die ID laut Server in der aktuellen Zone gültig ist.
  • Wenn diese Rückmeldung vom Server negativ ist (d.h. der Server teilt mit, dass die ID keine erforderliche Berechtigung für die entsprechende Zone hat), stellt das Prüfgerät im Schritt 316 fest, dass die Fahrkarte ungültig ist. Andernfalls stellt das Prüfgerät im Schritt 306 fest, dass die Fahrkarte gültig ist, wenn eine positive Rückmeldung vom Server kommt.
  • Figur 4 zeigt eine Übersicht zur Veranschaulichung einer erweiterten Infrastruktur eines Systems zur Steigerung der Interoperabilität zwischen mehreren Dienstleistern. Gemäß einer Ausführungsform der Erfindung wird die Interoperabilität deutlich vereinfacht. Die Server der verschiedenen Verkehrsunternehmen können Berechtigungen und Nutzung, Sperrungen und die Abrechnung für verschiedene IDs im geschützten Umfeld interoperabel, ohne Manipulationsmöglichkeiten durch externe austauschen.
  • Wie in Figur 4 zu sehen ist, kann das System eine Infrastruktur mit mehreren Hintergrundsystemen und dazugehörigen Prüfgeräten und Verkaufsstellen umfassen. Dabei ist ein Hintergrundsystem jeweils in ähnlicher Weise aufgebaut, wie in Figur 1 beschrieben. Das heißt, ein Hintergrundsystem besteht aus wenigstens einem Server, der in Kontakt zu wenigstens einem Prüfgerät und einem Vertriebsgerät steht.
  • Die einzelnen Hintergrundsysteme können mit einem standardisierten Protokoll miteinander verknüpft sein. Für sehr große Systeme kann statt einer vollständigen Vermaschung der Hintergrundsysteme eine Vermittlungsebene (Datendrehscheibe) eingefügt werden. Ebenso sind Vermittlungsinstanzen zwischen den Hintergrundsystemen für die Abrechnung innerhalb von Verkehrsverbünden möglich.
  • Durch dieses System mit mehreren Hintergrundsystemen, die miteinander kommunizieren, lässt sich ein beliebig skalierbare System erreichen. Beispielsweise kann das HGS A ein zuständiges Hintergrundsystem für die Region München darstellen, das HGS B ein zuständiges Hintergrundsystem für die Region Berlin darstellen, das HGS C ein zuständiges Hintergrundsystem für die Region Dresden darstellen, das HGS D ein zuständiges Hintergrundsystem für die Region Zürich darstellen, das HGS E ein zuständiges Hintergrundsystem für die Region Paris darstellen und das HGS F ein zuständiges Hintergrundsystem für die Region London darstellen. Wie bereits erwähnt, können die Hintergrundsysteme auch andere Dienstleistungsberechtigungen in der jeweiligen Region verwalten und sind nicht auf Fahrdienstleistungen beschränkt.
  • Durch dieses interoperable System ist es möglich, dass von jedem Vertriebsgerät V aus, eine gültige Fahrkarte für jede beliebige Region erworben werden kann und dort dann auch problemlos auf ihre Gültigkeit hin überprüft werden kann. Die einzelnen Hintergrundsysteme der verschiedenen Verkehrsbünde tauschen die IDs zusammen mit den Berechtigungen aus, welche für die entsprechenden Hintergrundsysteme der Verkehrsunternehmen in einer bestimmten Regionen nützlich sind.
  • Das bedeutet, dass sich ein Fahrgast an einem Vertriebsgerät V eines ersten Verkehrsbundes problemlos eine Fahrtberechtigung für eine beliebige Zone in einem zweiten Verkehrsbund erwerben kann. Beispielsweise kann ein Fahrgast in München an einem Fahrkartenautomat, der zum HGS A gehört, sich eine Fahrkarte für London (HGS F) kaufen. Das HGS A übermittelt dann die ID des Fahrgastes zusammen mit der erworbenen Berechtigung an das HGS F für London. Das HGS F speichert die ID zusammen mit der Berechtigung, wie oben beschrieben, und überträgt die gültige ID dann an die entsprechenden Prüfgeräte in den Zonen Londons, für welche die erworbene Berechtigung ihre Gültigkeit hat.
  • Eine weitere Ausführungsform betrifft die mögliche Trennung von Dienstleister (DL) und Vertriebs-Partner (VP). Dieses Prinzip ist in Figur 5 weiter gezeigt. Gemäß einer Ausführungsform ist es denkbar, dass ein Teil der Hintergrundsysteme zu einem DL gehört und ein anderer Teil der Hintergrundsysteme zu einem VP.
  • Die Rolle des DLs ist dabei die Verwaltung und das Referenzieren des angebotenen Produkts, zusammen mit Preis und Gültigkeit, wie beispielsweise Zone, Personenanzahl, Zeit etc. Der Dienstleister kann folglich die allgemeine Dienstleistung (Fahrten, Eintritte, Downloads, etc.) zur Verfügung stellen und arbeitet dabei zusammen mit einem oder mehreren Vertriebspartnern VP. Weiterhin ist der DL für die Überprüfung der Berechtigungen für eine Dienstleistung zuständig, wie oben beschrieben.
  • Die Rolle des VPs dabei ist die Abwicklung des Kaufs einer Berechtigung und das damit einhergehende Verknüpfen einer ID mit einer Berechtigung. Der VP kann dabei IDs mit seinen Kundenstammdaten verknüpfen. Die ID, die mit einer oder mehreren Berechtigungen verknüpft ist, kann dann vom VP an die entsprechenden Hintergrundsysteme des DLs weitergeleitet werden, so dass die DLs die Berechtigungen der Benutzer überprüfen können.
  • Zusammenfassend kann im Allgemeinen ein Verfahren in einem System mit Trennung von VP und DL folgende Schritte umfassen:
    • Verkauf: VP erstellt Berechtigung und verteilt diese an die DLs; die DLs verteilen diese an relevante Prüfgeräte während der Gültigkeit (räumlich und zeitlich) für die schnelle offline-Prüfung.
    • Kontrolle: Der DL überprüft anhand der ID des Nutzers, ob dieser die Berechtigung zur Nutzung besitzt, wie oben beschrieben. Liegt die Berechtigung vor, meldet der DL die Nutzung an den durch die Übermittlung der ID/Berechtigung bereits bekannten VP. Damit kann der DL seine Dienstleistung zuverlässig abrechnen. Der VP kann mit der Nutzungs-Meldung vom DL eventuellen Missbrauch erkennen und die IDs mit Berechtigungen gegebenenfalls sperren, wie zuvor beschrieben.
  • Ein Sonderfall einer Nutzungs-Berechtigung stellt ein Guthaben in Geld dar. Damit kann der Nutzer ohne explizite Bezahlung Dienstleistungen beim VP erwerben. In einem globalen System mit mehreren VPs kann er das Guthaben auch bei einem anderen VP nutzen, als bei dem, bei dem er es erworben hat. Dann fungiert der zweite VP als DL des ersten, der das Guthaben verwaltet. In diesem Sonderfall berechnet ein VP dem anderen die Nutzung des Guthabens.
  • Diese Sonderfall kann offensichtlich auf andere Bezahlformen ausgeweitet werden, z.B. kann ein VP einem Nutzer einen Kreditrahmen gewähren (PostPaied).
  • Dabei kann die Trennung von VP und DL folgende Vorteile aufweisen:
    • Jeder VP behält seine Daten auf seinem Server, insbesondere "seine" Kunden und deren Umsätze. Der Wettbewerber (alle verknüpften Unternehmen sind scharfe Wettbewerber) erfährt weder Stammdaten noch Umsätze.
    • Jeder DL kann seine Produkte flexibel und individuell gestalten und muss sie bei diesem Verfahren dem VP erst zum Zeitpunkt des Kaufes mitteilen statt wie heute lange davor.
    • Der DL kennt schon vor der Nutzung den ausstellenden VP und kann zuverlässig abrechnen.
    • Transparenz: der Kunde kann Käufe und Nutzung im Internet verfolgen
  • Gemäß einer weiteren Ausführungsform der Erfindung ist es möglich, dass ein VP für verschiedene Dienstleister Berechtigungen für deren entsprechenden Dienstleistungen ausstellt. Dies wird durch die Ausführungsformen der Erfindung ermöglicht, da der VP keine werthaltigen Tickets, Voucher oder Fahrscheine ausstellen muss und die typischen Sicherheitsmerkmale solcher Tickets, Voucher oder Fahrscheine einzelner verschiedener Dienstleister nicht implementieren oder kennen muss. Stattdessen kann ein VP lediglich eine (bekannte oder neue) ID für einen Benutzer mit einer oder mehreren Berechtigungen für die verschiedenen Dienstleistungen der verschiedenen Dienstleister verwenden. Basierend auf dieser Verknüpfung einer einfachen ID oder Kennung mit den jeweiligen verscheiden Dienstleistungen oder Dienstleistern kann ein einzelnes System, wie etwa der VP, den Erwerb für sämtliche verschiedene Dienstleistungen und Dienstleister vornehmen. Ebenso kann der Benutzer die verschiedenen Dienstleistungen von einem einzelnen System, wie etwa dem VP, käuflich erwerben und dieses einzelne System kann die gezahlten Gebühren bereits vor der eigentlichen Benutzung der Dienstleistungen mit den anderen Dienstleitern und Dienstleistungen bzw. dessen Hintergrundsystemen verrechnen.
  • Diese Aspekte und Ausführungsformen sind in Figur 5 weiter veranschaulicht, wobei das erste Hintergrundsystem 501 zu einem VP gehören kann. Ein Benutzer kann an den Verkaufsgeräten V 505a-c, die mit dem ersten Hintergrundsystem 501 verbunden sind, Berechtigungen erwerben, die als Berechtigungen für Dienstleistungen von einem ersten Dienstleister und/oder einem zweiten Dienstleister gelten. Mit anderen Worten, in dem ersten Hintergrundsystem 501 liegt eine Verknüpfung einer ID mit einer ersten Berechtigung vor und eine Verknüpfung der selben ID mit einer zweiten Berechtigung. Die erste Berechtigung betrifft dabei eine Dienstleistung des ersten Dienstleisters und die zweite Berechtigung betrifft dabei eine Dienstleistung des zweiten Dienstleisters.
  • Das erste Hintergrundsystem 501 überträgt dann die ID zusammen mit der ersten Berechtigung an das zweite Hintergrundsystem 502 des ersten Dienstleisters und überträgt die gleiche ID zusammen mit der zweiten Berechtigung an das dritte Hintergrundsystem 503 des zweiten Dienstleisters.
  • Die entsprechenden Hintergrundsysteme 502 und 503 der beiden Dienstleister können dann die IDs mit Berechtigung an die entsprechenden Prüfgeräte 510a bis 510f übertragen, sofern diese Dienstleistungen für zugeordnete Berechtigungen kontrollieren, wie oben in den Figuren 1 bis 4 beschrieben.
  • In alternativen Ausführungsformen können das zweite Hintergrundsystem 502 und das erste Hintergrundsystem 501 ein einzelnes Hintergrundsystem sein. In diesem Fall überträgt das erste Hintergrundsystem 501 nicht die ID und die erste Berechtigung an das zweite Hintergrundsystem 502, sondern speichert diese Information.

Claims (15)

  1. Verfahren zum Erstellen und Auswerten einer Fahrberechtigung in einem Personenverkehrssystem, wobei das Verfahren umfasst:
    Verknüpfen einer Identifikation, ID, mit einer ersten Berechtigung, wobei die erste Berechtigung wenigstens eine erste Zone oder eine erste Strecke des Personenverkehrssystems betrifft und die ID in dieser ersten Zone oder auf dieser ersten Strecke als eine gültige Fahrberechtigung dient;
    Verknüpfen der ID mit einer zweiten Berechtigung, wobei die zweite Berechtigung wenigstens eine zweite Zone oder eine zweite Strecke des Personenverkehrssystems betrifft und die ID in dieser zweiten Zone oder auf dieser zweiten Strecke als eine gültige Fahrberechtigung dient;
    Übermitteln der ID an ein Prüfgerät (131, 141; 510) zum Überprüfen der Gültigkeit von Fahrberechtigungen von Benutzern des Personenverkehrssystems;
    Einlesen einer ID durch das Prüfgerät; und
    Überprüfen, durch das Prüfgerät, ob die eingelesene ID in einer Liste ist, wobei:
    die Liste in dem Prüfgerät gespeichert ist;
    die Liste eine Vielzahl von IDs enthält, die in der Zone, in der sich das Prüfgerät befindet, eine gültige Fahrberechtigung sind; und
    das Prüfgerät mit einem Hintergrundsystem kommuniziert, um die Liste zu aktualisieren.
  2. Verfahren nach Anspruch 1, wobei das Verknüpfen der ID mit der ersten Berechtigung und das Verknüpfen der ID mit der zweiten Berechtigung durch ein erstes Hintergrundsystem (501) durchgeführt wird, und das Verfahren des Weiteren umfasst:
    Übertragen der ID und der ersten Berechtigung an ein zweites Hintergrundsystem (502), wobei das zweite Hintergrundsystem die ID und die erste Berechtigung speichert;
    Übertragen der ID und der zweiten Berechtigung an ein drittes Hintergrundsystem (503), wobei das dritte Hintergrundsystem die ID und die zweite Berechtigung speichert; und
    wobei das Prüfgerät (131, 141; 510) mit dem zweiten Hintergrundsystem kommuniziert, wenn das Prüfgerät die Gültigkeit von Fahrberechtigungen in der ersten Zone oder auf der ersten Strecke des Personenverkehrssystems überprüft, und wobei das Prüfgerät mit dem dritten Hintergrundsystem kommuniziert, wenn das Prüfgerät die Gültigkeit von Fahrberechtigungen in der zweiten Zone oder auf der zweiten Strecke des Personenverkehrssystems überprüft.
  3. Verfahren nach Anspruch 2, wobei das erste Hintergrundsystem (501) das zweite Hintergrundsystem (502) ist und das Übertragen der ID und der ersten Berechtigung an das zweite Hintergrundsystem das Speichern der ID und der ersten Berechtigung im zweiten Hintergrundsystem ist.
  4. Verfahren zum Erstellen und Auswerten von Benutzerberechtigungen, wobei das Verfahren umfasst:
    Verknüpfen, in einem ersten Hintergrundsystem (501), einer Identifikation, ID, mit einer ersten Berechtigung für wenigstens eine erste Dienstleistung von einem ersten Dienstleister und Verknüpfen dieser ID mit einer zweiten Berechtigung für wenigstens eine zweite Dienstleistung von einem zweiten Dienstleister, wobei die ID für die wenigstens erste und zweite Dienstleistung als eine gültige Berechtigung für einen Benutzer dient;
    Übertragen der ID und der ersten Berechtigung an ein zweites Hintergrundsystem (502) des ersten Dienstleisters, wobei das zweite Hintergrundsystem die ID und die erste Berechtigung speichert;
    Übertragen der ID und der zweiten Berechtigung an ein drittes Hintergrundsystem (503) des zweiten Dienstleisters, wobei das dritte Hintergrundsystem die ID und die zweite Berechtigung speichert;
    Übermitteln der ID, durch das zweite oder dritte Hintergrundsystem, an ein Prüfgerät (131, 141; 510) zum Überprüfen der Gültigkeit von Berechtigungen von den Benutzern;
    Einlesen einer ID durch das Prüfgerät; und
    Überprüfen, durch das Prüfgerät, ob die eingelesene ID in einer Liste ist, wobei:
    die Liste in dem Prüfgerät gespeichert ist;
    die Liste eine Vielzahl von IDs für gültige Berechtigungen enthält; und
    das Prüfgerät mit mindestens dem zweiten oder dem dritten Hintergrundsystem kommuniziert, um die Liste zu empfangen oder zu aktualisieren.
  5. Verfahren nach Anspruch 4, wobei unterschiedliche Dienstleistungen unterschiedliche Listen von IDs haben, und wobei ein Prüfgerät (131, 141;510) zum Überprüfen der Gültigkeit von Berechtigungen für eine dieser verschiedenen Dienstleistungen eine Liste nur mit IDs für gültige Berechtigungen dieser Dienstleistung empfängt oder speichert, welche von einem entsprechendem Hintergrundsystem bereitgestellt werden.
  6. Verfahren nach Anspruch 4 oder 5, wobei der erste Dienstleister der zweite Dienstleiter ist, und wobei die erste und die zweite Dienstleistung unterschiedlich sind.
  7. Verfahren nach einem der Ansprüche 4 bis 6, wobei das Aktualisieren der Liste durchgeführt wird, sobald eine Kommunikationsverbindung zwischen Prüfgerät (131, 141; 510) und dem zweiten oder dritten Hintergrundsystem (502, 503) hergestellt ist, wobei nur Änderungen der Liste vom entsprechenden Hintergrundsystem an das Prüfgerät übertragen werden.
  8. System zum Erstellen und Auswerten von Benutzerberechtigungen, wobei das System ein erstes Hintergrundsystem (501), ein zweites Hintergrundsystem (502) eines ersten Dienstleisters und ein drittes Hintergrundsystem (503) eines zweiten Dienstleisters umfasst,
    wobei das erste Hintergrundsystem (501) umfasst:
    Mittel zum Verknüpfen einer Identifikation, ID, mit einer ersten Berechtigung für wenigstens eine erste Dienstleistung eines ersten Dienstleisters,
    Mittel zum Verknüpfen dieser ID mit einer zweiten Berechtigung für wenigstens eine zweite Dienstleistung eines zweiten Dienstleisters, wobei die ID für die wenigstens erste und zweite Dienstleistung als eine gültige Berechtigung dient,
    Mittel zum Übertragen der ID und der ersten Berechtigung an das zweite Hintergrundsystem (502) des ersten Dienstleisters, und
    Mittel zum Übertragen der ID und der zweiten Berechtigung an das dritte Hintergrundsystem (503) des zweiten Dienstleisters;
    wobei das zweite Hintergrundsystem des ersten Dienstleisters eingerichtet ist, die ID und die erste Berechtigung zu speichern;
    wobei das dritte Hintergrundsystem des zweiten Dienstleisters eingerichtet ist, die ID und die zweite Berechtigung zu speichern; und
    wobei das erste und/oder das zweite Hintergrundsystem des Weiteren umfasst:
    Mittel zum Kommunizieren mit einem Prüfgerät (131, 141; 510) zum Überprüfen der Gültigkeit von Berechtigungen der Benutzung der ersten und/oder der zweiten Dienstleistung, wobei eine Liste mit einer Vielzahl von IDs für gültige Berechtigungen für die erste und/oder zweite Dienstleistung an das Prüfgerät übertragen wird oder die Liste durch Übertragen einer oder mehrerer IDs aktualisiert wird.
  9. System nach Anspruch 8, wobei das erste Hintergrundsystem (501) das zweite Hintergrundsystem (502) ist und das Übertragen der ID und der ersten Berechtigung an das zweite Hintergrundsystem das Speichern der ID und der ersten Berechtigung in dem zweiten Hintergrundsystem ist.
  10. System nach Anspruch 8 oder 9, wobei die Liste aktualisiert wird, wenn eine Kommunikationsverbindung zwischen dem Prüfgerät (131, 141; 510) und dem zweiten oder dem dritten Hintergrundsystem (502, 503) besteht, wobei nur Änderungen der Liste von dem zweiten oder dritten Hintergrundsystem an das Prüfgerät übertragen werden.
  11. Prüfgerät (131, 141; 510) zum Überprüfen der Gültigkeit von Fahrberechtigungen in einem Personenverkehrssystem, wobei das Prüfgerät umfasst:
    Mittel zum Empfangen von einer Identifikation, ID, von einem Hintergrundsystem, wobei die ID mit einer Berechtigung verknüpft ist, wobei die Berechtigung wenigstens eine erste Zone oder eine erste Strecke des Personenverkehrssystems betrifft und die ID in dieser Zone oder auf dieser Strecke als eine gültige Fahrberechtigung dient;
    Mittel zum Einlesen einer ID; und
    Mittel zum Überprüfen, ob die eingelesene ID in einer Liste ist, wobei:
    die Liste in dem Prüfgerät gespeichert ist;
    die Liste eine Vielzahl von IDs für gültige Berechtigungen enthält; und
    das Prüfgerät mit dem Hintergrundsystem kommuniziert, um die Liste zu empfangen oder zu aktualisieren.
  12. Prüfgerät (131, 141; 510) nach Anspruch 11, wobei:
    die Liste in dem Prüfgerät IDs enthält, die in einer Zone, in der sich das Prüfgerät befindet, eine gültige Fahrberechtigung sind.
  13. Prüfgerät (131, 141; 510) nach Anspruch 12, wobei das Prüfgerät eingerichtet ist, direkt mit einem Verkaufsgerät zu kommunizieren, um die Liste zu aktualisieren.
  14. Prüfgerät (131, 141; 510) nach Anspruch 11 oder 12, wobei das Prüfgerät des Weiteren eingerichtet ist, während einer Fahrt von einer ersten Haltestelle zu einer zweiten Haltestelle, die gespeicherte Liste in dem Prüfgerät auszuwerten und zu überprüfen ob die IDs an der zweiten Haltestelle noch gültig sind, wobei wenn festgestellt wird, dass eine gespeicherte ID an der zweiten Haltestelle nicht gültig ist, die gespeicherte ungültige ID vom Prüfgerät entfernt wird.
  15. Prüfgerät (131, 141; 510) nach einem der Ansprüche 11 bis 14, wobei das Prüfgerät des Weiteren eingerichtet ist, die Liste zu aktualisieren, sobald eine Kommunikationsverbindung zum Hintergrundsystem hergestellt ist, wobei nur Änderungen der Liste vom Hintergrundsystem an das Prüfgerät übertragen werden.
EP14003601.3A 2014-10-22 2014-10-22 System und Verfahren zum Erstellen und Auswerten von Nutzungsberechtigungen und Fahrscheinen Withdrawn EP3012808A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP14003601.3A EP3012808A1 (de) 2014-10-22 2014-10-22 System und Verfahren zum Erstellen und Auswerten von Nutzungsberechtigungen und Fahrscheinen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP14003601.3A EP3012808A1 (de) 2014-10-22 2014-10-22 System und Verfahren zum Erstellen und Auswerten von Nutzungsberechtigungen und Fahrscheinen

Publications (1)

Publication Number Publication Date
EP3012808A1 true EP3012808A1 (de) 2016-04-27

Family

ID=51870787

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14003601.3A Withdrawn EP3012808A1 (de) 2014-10-22 2014-10-22 System und Verfahren zum Erstellen und Auswerten von Nutzungsberechtigungen und Fahrscheinen

Country Status (1)

Country Link
EP (1) EP3012808A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016217331A1 (de) 2016-09-12 2018-03-15 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Ermitteln einer Anwesenheit wenigstens eines Fahrgasts in einem Fahrzeug

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040249714A1 (en) * 2001-06-21 2004-12-09 Gregor Ponert Method for purchasing a service
US20130063246A1 (en) * 2010-02-22 2013-03-14 Easy Axess Gmbh I.G. System and method for electronically providing an access authorization

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040249714A1 (en) * 2001-06-21 2004-12-09 Gregor Ponert Method for purchasing a service
US20130063246A1 (en) * 2010-02-22 2013-03-14 Easy Axess Gmbh I.G. System and method for electronically providing an access authorization

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016217331A1 (de) 2016-09-12 2018-03-15 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Ermitteln einer Anwesenheit wenigstens eines Fahrgasts in einem Fahrzeug

Similar Documents

Publication Publication Date Title
EP1210693B1 (de) Verfahren und system zur registrierung von billetten
DE202012100172U1 (de) Elektronisches Gutscheinsystem
CN105976435A (zh) 一种车站电子票订票、自动检票方法及系统
EP1999722B1 (de) Verfahren zur registrierung von fahrgast-reisen in verkehrsmitteln mittels eines trägermediums für elektronische tickets
EP1839269B1 (de) Verfahren zur erfassung von leistungsentgelten für reisen in öffentlichen verkehrsmitteln
WO2011101486A1 (de) System und verfahren zum elektronischen bereitstellen einer zutrittsberechtigung
EP2793194B1 (de) Verfahren zum Aufladen einer Onboard-Unit mit einem elektronischen Ticket
EP2913989A2 (de) Bindung eines Terminals an ein mobiles Endgerät zum Zweck der Kostenzuweisung
EP1750220A1 (de) Verfahren und System zur Erstellung und zur automatisierten Überprüfung von elektronischen Tickets
DE19718115A1 (de) Chipkarte und Verfahren zur Verwendung der Chipkarte
EP1328886B1 (de) Programmlogik zum verkauf von berechtigungen
DE102010017861A1 (de) Verfahren zur Handhabung von elektronischen Tickets
DE112019006109T5 (de) Einkaufsmanagementsystem und -verfahren
DE102012011103B4 (de) Verfahren zum Handhaben von Zugangs- oder Nutzungsberechtigungen und Handhabungssystem zur Handhabung von Zugangs- oder Nutzungsberechtigungen
EP3012808A1 (de) System und Verfahren zum Erstellen und Auswerten von Nutzungsberechtigungen und Fahrscheinen
EP3190549A1 (de) Vorrichtung und vorrichtung zur kontrolle von e-tickets
DE60021654T2 (de) System und Verfahren zum Bereitstellen von Diensten mit vertrautem Ortindikator, und fahrbares Gerät zur Anzeige von ihnen
EP3208756A1 (de) Reisedienstleistungssystem für die kommunikation zwischen einem reisenden und einem verkehrsdienstleister
EP3252697A1 (de) Validatorvorrichung für ein ticketsystem
EP1345180B1 (de) System und Verfahren zum Zuweisen und Kontrollieren von Dienstleistungsberechtigungen und dafür geeignete Vorrichtungen
EP2747042A1 (de) Verfahren und System zur Ausgabe oder Kontrolle von Nutzungsberechtigungen
EP4332919A1 (de) Entwertervorrichtung für ein personentransportsystem
EP2112632A1 (de) Verfahren zur Registrierung von Fahrgast-Reisen in Verkehrsmitteln mittels eines Trägermediums für elektronische Tickets
CH713687A1 (de) Verfahren und System zum Bestellen und Verwenden von Zutrittsrechten.
WO2023030954A1 (de) Verfahren und system zum bereitstellen einer nutzungsinformation, welche die nutzung eines fahrzeugs repräsentiert, unter verwendung einer blockchain

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: 20161024

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: 20180629