EP3012808A1 - Système et procédé de fabrication et d'évaluation d'autorisations d'utilisation et billets - Google Patents

Système et procédé de fabrication et d'évaluation d'autorisations d'utilisation et billets 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
German (de)
English (en)
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/fr
Publication of EP3012808A1 publication Critical patent/EP3012808A1/fr
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)
EP14003601.3A 2014-10-22 2014-10-22 Système et procédé de fabrication et d'évaluation d'autorisations d'utilisation et billets Withdrawn EP3012808A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP14003601.3A EP3012808A1 (fr) 2014-10-22 2014-10-22 Système et procédé de fabrication et d'évaluation d'autorisations d'utilisation et billets

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP14003601.3A EP3012808A1 (fr) 2014-10-22 2014-10-22 Système et procédé de fabrication et d'évaluation d'autorisations d'utilisation et billets

Publications (1)

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

Family

ID=51870787

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14003601.3A Withdrawn EP3012808A1 (fr) 2014-10-22 2014-10-22 Système et procédé de fabrication et d'évaluation d'autorisations d'utilisation et billets

Country Status (1)

Country Link
EP (1) EP3012808A1 (fr)

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 (fr) Procede et systeme d'enregistrement de billets
DE202012100172U1 (de) Elektronisches Gutscheinsystem
CN105976435A (zh) 一种车站电子票订票、自动检票方法及系统
EP1999722B1 (fr) Procédé d'enregistrement des trajets d'un voyageur dans des moyens de transport au moyen d'un support de tickets électroniques
WO2011101486A1 (fr) Système et procédé permettant de fournir une habilitation d'accès par voie électronique
EP1839269B1 (fr) Procede de detection de paiements de voyages dans les transports publics
EP2793194B1 (fr) Procédé de charge d'une unité embarquée avec un ticket électronique
EP2645336A1 (fr) Procédé de transmission automatique de places de stationnement
EP1750220A1 (fr) Procédé et système pour la création et le control automatique d'un billet électronique
DE19718115A1 (de) Chipkarte und Verfahren zur Verwendung der Chipkarte
EP1328886B1 (fr) Logique de programme pour vendre des autorisations
DE102010017861A1 (de) Verfahren zur Handhabung von elektronischen Tickets
EP3012808A1 (fr) Système et procédé de fabrication et d'évaluation d'autorisations d'utilisation et billets
EP3190549A1 (fr) Dispositif et dispositif de contrôle de tickets électroniques
DE112019006109T5 (de) Einkaufsmanagementsystem und -verfahren
DE60021654T2 (de) System und Verfahren zum Bereitstellen von Diensten mit vertrautem Ortindikator, und fahrbares Gerät zur Anzeige von ihnen
DE102012011103B4 (de) Verfahren zum Handhaben von Zugangs- oder Nutzungsberechtigungen und Handhabungssystem zur Handhabung von Zugangs- oder Nutzungsberechtigungen
EP3252697A1 (fr) Dispositif de validation pour un systeme de ticket
EP1345180B1 (fr) Procédé et dispositif servant à affecter et contrôler des autorisations de service et dispositif pour la mise en oeuvre de ce procédé
EP2747042A1 (fr) Procédé et système d'édition ou de contrôle d'autorisations d'utilisation
EP4332919A1 (fr) Composteur de billets pour un système de transport de personnes
EP2112632A1 (fr) Procédé d'enregistrement de trajets d'un voyageur dans des moyens de transport au moyen d'un support de tickets électroniques
WO2023030954A1 (fr) Procédé et système pour fournir une information d'utilisation, qui représente l'utilisation d'un véhicule, à l'aide d'une chaîne de blocs
DE102005041837B4 (de) Elektronisches Ticket
EP3196841A1 (fr) Serveur back-end et procédé pour déterminer automatiquement l'utilisation d'un réseau de transport, ainsi q'un appareil portable et procédé correspondants pour communiquer informations de position d'un utilisateur du réseau

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