WO2014044307A1

WO2014044307A1 - Operation of an access authorisation system

Info

Publication number: WO2014044307A1
Application number: PCT/EP2012/068459
Authority: WO
Inventors: Norbert Miller; Alfred HÖHN; Wolfgang Flügge; Manfred Feiter; Kai OELERT
Original assignee: Scheidt & Bachmann Gmbh
Priority date: 2012-09-19
Filing date: 2012-09-19
Publication date: 2014-03-27

Abstract

In order to avoid regular and system-wide transmissions of large volumes of data in access authorisation systems, where a system comprises a computer network with at least one central computer forming a background system and at least one computer connected thereto by a data network and present in a terminal arranged in an access area, which terminal is designed at least for reading identification media having a system-wide unique-readable identifier, the invention specifies that a data table constituting a positive/negative list, in which a value representing validity or invalidity is associated with each identifier necessary for the system operation, is maintained in the background system, the positive/negative list is transmitted to terminals and stored by same and, after an identifier is read, the validity state of the associated identification medium is determined by the terminal on the basis of the positive/negative list and a decision is made regarding an access authorisation.

Description

Operation of a train access authorization system

The present invention relates to a method for operating an access authorization system.

In particular, the invention relates to conditional access systems operating with electronic media known by the term smart card or e-ticketing. Examples are parking management systems, access systems for sports, cultural and leisure facilities, ticket systems and the like.

One differentiates between these systems between card-based and account-based systems. In the card-based systems, essential data allowing and registering the use of the access system is stored on the card. In essence, the access authorization is written electronically on the card. Upon entering a system area, based on this data present on the map and on the tariff model depicted in an input control device, the system judges whether the map authorizes the use of the system and displays the result to the user. Typically, this is also written back to the card. Card-based systems can be implemented with proprietary cards that are often valid only with one operator, or with standardized cards that apply to multiple operators. Examples of standardized card-based systems are the British ITSO scheme or the German ((e-ticketing, formerly also known as VDV core application), due to the fact that only dedicated cards with certain data contents and security standards are accepted these systems called "closed loop". A koniobased "open loop" or "open payment" system differs from card based systems in three principles:

• The card that gives the user access to the system is just an identification medium. When accessing the system, the user identifies himself at a terminal (e.g., transit barrier, validator, bus checkout, entry gate) with this medium containing a machine-readable system-wide unique identifier. Due to the system, no information is written back to the medium. The same applies if the identification medium is used to leave the system at a terminal.

• All information about the identification medium and its use are stored in the background system {"back office") of the conditional access system in an account and evaluated. In particular, all price calculations for the use of the system and the downstream cashless billing are performed in the background system.

• Potentially, very different types of identification media may be used in such a system, for example smart cards specially issued by the operator, credit cards, student cards or other card types that may be considered as technically readable identification media. In particular, all media can be used that communicate without contact according to ISO 14443, even in formats that are not designed as cards, but, for. as key fob, ID card, smart-phone or in other formats. But also any sort of mechanically readable data carriers such as magnetic cards, 1- and 2-dimensional barcodes are possible as identification media.

Since the account-based system dispenses with any specific data content of the identification media, any data carrier that can be technically read by the terminals and that can be uniquely identified system-wide can be used as a medium. That is why these systems are also called "open loop" or "open payment" systems.

Based on these principles, a distinction is made between different operating models for an open payment system, that of the tariff structures, accepted cards and Depend on payment methods. Main operating parameters are:

• Type of usage: Must a usufruct prior to entering the system be purchased and credited to the account, or can the price be determined after the end of use?

• What payment methods are available, such as cash, checking cards, credit cards, direct debit or bank transfer?

• In which cases is the registration of a user necessary? This can e.g. become necessary when multiple or season tickets (e.g., monthly passes) or perks (e.g., disability pass) are used to access the system.

• How to balance the usability of the system (ease of use, fault tolerance of the system) with the commercial risk (abuse and default)?

The last point concerns the user acceptance of the system. There is a need to bring the usability of an open payment system with the commercial risk in a sensible balance.

A technical problem of the open payment method in the prior art is that they depend on fast data access from the terminal (eg transit barrier, validator, bus cash, entrance barrier) to the background system, because if the user identifies with his identification medium on the terminal, the System in real time on the background system to query the validity of the medium and receive a response. Real-time means according to common requirements that, for example, a pass-through barrier should open within 500 milliseconds after reading a medium.

That means in terms of the network and the background system that they are

• practically always available

• have to guarantee very short response times • need to allow many concurrent accesses to the background system.

For real networks with a few hundred or a few thousand devices, this can not be completely fulfilled, especially if mobile devices are also connected, which are connected to the background system via mobile networks.

In the prior art, therefore, the approach is chosen to distribute certain validity data for the identification media, which would have to query the terminals in real time from the background system to distribute at short intervals throughout the entire system via broadcasting across all terminals. The validity query for a medium is thus no longer online from the terminal to the background system, but locally in the terminal based on the validity data stored there. Thus, the terminal can also meet the required fast response times, since it works exclusively locally for the authorization of a medium.

In the prior art, WO 2012/088582 selects for a ticket system the approach that registration data sets for an identification medium of 153 bit length (according to WO 2012/088582, Table 1) are distributed by the background system to all terminals. Further, for each entry into the system, validation records of 251-bit length (according to WO 2012/088582, Table 2) are distributed to the background system from the terminal at which the entry into the system took place and from there to all terminals in the broadcast method forwarded. The terminal on which the medium leaves the system again, so also knows the entry data for this trip and can calculate the fare locally. This approach has the inherent disadvantage that for each transaction a data set of 251 bit length is distributed across all devices. Even for small systems, this adds up to a data volume of 610 GB / month as described in WO 2012/088582 and to 170,000 GB / month for large systems (according to WO 2012/088582, Table 4).

Based on the above-described prior art, the present invention is based on the invention to avoid the required regular system-wide sending large amounts of data and still ensure short authorization times for open payment identification media in conditional access systems.

For technical solution of the above object, the invention proposes a method having the features of claim 1. Further advantages and Features of the invention will become apparent from the dependent claims.

According to the invention, an access authorization system is operated, which system comprises a computer network, with at least one central computer forming a background system and at least one computer connected to it via a data network in at least one terminal arranged in an access area, at least for reading identification media with one each system-wide unique machine-readable connoisseur is designed. According to the invention, a data table representing a positive / negative list is maintained in the background system. In this, a value representing the validity or the invalidity is assigned to each connoisseur necessary for the system operation. The positive / negative list is transmitted to terminals and stored by them. From a terminal, the validity state of the associated identification medium is determined after reading a connoisseur on the basis of the positive / negative list and decided on an access grant.

The method according to the invention has the advantage of designing an open payment access authorization system such that it simultaneously fulfills the following conditions of use:

• Simplicity: The validity of an identification medium presented to a terminal is checked exclusively against locally stored positive and / or negative lists. The terminal does not carry out any further tests or calculations and can immediately notify the user of the result of the test. In particular, the terminal does not make any tariff calculations.

• Speed: For an identification medium with which the user wants to gain access to the system, a terminal is locally resolved within less than 500 milliseconds and the user is granted access or denied access.

Robustness: Since a transaction is performed on the terminal only with local data, it is not relevant for the terminal in question in the transaction whether it has a data connection to the background system or not. • Consolidation of data traffic: Compared with such methods, which always work online, in the method according to the invention, the average network load is about the same, as well as the inventive method must send the transaction data from the terminals to the background system.

However, since in the system according to the invention the terminal does not have to communicate with the background system in real time (ie not during the transaction), the data traffic between terminals and the background system can be maintained. The load peaks in the data network will be significantly lower, and the network capacity can be designed with less reserve closer to the average load.

Reduction of the data volume in the network: Compared with methods which always distribute transaction data in the broadcasting method to all terminals, the data volume distributed in the network is significantly lower in the method according to the invention.

For example, in a state of the art ticket disclosure system according to WO 2012/088582, if a monthly pass is used four times (two entries and two exits per day) for 20 working days, then 80 one-month transactions will be issued to each of them Terminals are distributed in the system via broadcasting. The distributed data volume for a monthly ticket is on the order of 20,000 bits per month.

When a user buys a monthly ticket into his identification medium in a ticketing system according to the invention, the background system sets this medium on the positive list and distributes this change once to all terminals. The distributed data volume is on the order of 64 bit once. If the monthly subscription is renewed without interruption, there will be no further traffic and the entry on the positive list will simply be kept.

• Floating risk mitigation: As long as the endpoints are continuously and promptly updated with changes to the positive and negative lists, they will always have the knowledge of the background system and make the right decision about acceptance or rejection of an identification medium.

If a terminal loses the data connection to the background system, the correctness of its decisions does not immediately become zero, but the timeliness of the local positive and negative lists slowly drifts from the state in the background system, until the data connection is restored and the local lists are updated are.

The loss of a data connection between the terminal and the background system thus slowly reduces the accuracy of the decisions at the terminal concerned; the decision-making ability as such remains for the terminal but preserved.

The method according to the invention achieves a balance between, on the one hand, the fast and robust response behavior of the terminals and, on the other hand, a minimized financial risk for the operator. In essence, the process combines three principles:

• The validity of an identification medium presented to a terminal is checked exclusively against locally stored positive and / or negative lists.

The terminal does not carry out any further tests or calculations and can immediately notify the user of the result of the test. In particular, the terminal does not make any tariff calculations. For a medium that has been validated, the terminal records a transaction record and sends it to the background system in a timely manner - typically within minutes.

• The validity of an identification medium is determined only in the background system and can only be changed there.

This is done on the basis of the received transaction data and a successful or unsuccessful billing.

• Then - and only then - if the validity of an identification medium changes, there is a change to the central positive or negative list, and only this change must be distributed to the terminals and stored there.

In the following table, it will be apparent from three exemplified different types of identification media, in which way the positive and negative lists are used in a system according to the invention, the applications shown here are typical and exemplary, but not exhaustive. The change of the validity of a medium is the exception, so that the changes in the system, which have to be distributed to the terminals in the system, do not cause a large communication volume:

[no action: card the

valid

System not yet known]

Contactless Successful offsetting of

valid

Credit card uses

(Open Payment Unsuccessful offsetting

will invalidate entry medium) uses

Settlement open

will be valid cancellation bills

Purchase of the medium invalid

Purchase of a monthly ticket invalid

The beginning of the month will be valid entry

proprietary

Purchase of a 2nd monthly ticket valid

map

The beginning of the 2nd month is valid

of the operator

End of 2nd month becomes invalid deletion

Purchase of a 3rd monthly pass will be valid entry

Card "lost" is reported invalid deletion

bills

A preferred embodiment is characterized by the rapid updating and distribution of positive and negative lists, which according to the invention is carried out in the following steps:

The successful use of an identification medium is recorded by the terminals as a transaction and the transaction data is sent to the background system. These transaction data indicate at least when and where the medium entered the system; another transaction record for identifying when and where the medium has left the system may preferably be generated when exiting through a transit barrier or exit gate. But there are also systems whose architecture and tariff structure do not require registration of the exit. In the background system, a transaction handling and tariff calculation process aggregates a usage from the transaction data and compares that usage with the permissions stored on the account associated with the medium. If there is no authorization, a billing process tries on Background system to charge the use against the deposited to the identification medium payment medium (giro or credit card number). If the usage can not be offset against a stored authorization or a stored payment medium, then the identification medium is placed on the negative list.

Each terminal receives data transfers from the background system new entries and deletions - ie incremental updates - for the positive and negative lists as soon as changes are made to the background system on these lists. As a variant, it is possible that each terminal knows its last update status with regard to the positive and negative lists and cyclically retrieves the changes that have occurred since then in the background system. This has the advantage of distributing the traffic between the background system and the terminals more evenly. As a further variant, it is conceivable to send in each case a complete current negative and positive list to all field devices at certain time intervals, for example once a day or once a week, so that a consistent data consistency in the system is ensured. As a further variant, it is conceivable set up specially adapted positive and negative lists for individual devices or device groups, so that the communication effort - in terms of volume and frequency of communication - can be optimized again and / or certain tariff models are mapped using the adjusted positive and negative lists. The latter can be the case, for example, in a zone-based ticketing system.

In any event, as a result of this approach, each terminal has stored a local copy of the current positive and negative lists against which it is examining a user presented identification medium and deciding locally whether the medium is accepted or rejected.

The positive and negative lists are used as follows:

• Positive lists include those familiar with the system known as system proprietary cards, proprietary cards issued by the operator, and identification media registered in the system.

For example, if a terminal receives an identification medium and recognizes it as the proprietary card, the device becomes local stored positive list for this card and accept the card on successful search.

• Negative lists contain the connoisseurs of those open-payment media that have a negative user history in the access system.

Example: A contactless credit card, which was used in the system according to the invention and for which no billing could be performed, is placed on the negative list - at least until the outstanding claim has been settled. If a terminal gets presented an identification medium and recognizes it as a contactless credit card, the device will search for this card on its locally stored negative list and reject the card on successful search. If it is not found on the local negative list, a credit card will be accepted by the terminal.

Please note that contactless credit cards, which do not need to be registered with the system as open payment media, but can be used as ad-hoc access authorizations, can not be run on positive lists because the large number of credit cards used worldwide is the access system can not be known a priori. Open payment media are placed on the negative list after a failed clearing on the background system; it is also possible that the background system of banks and / or payment system providers imported blacklists (lists of blocked credit and / or giro cards), converted into native negative lists and distributed to the terminals.

Furthermore, this principle means that a contactless credit card, which is used in the access system repeatedly and without complaint, although the system-known identification medium, but is still out on any list - neither on the negative nor on the positive list.

Positive and negative lists thus do not contain all connoisseurs of all identification media known in the access system, but only those who are necessary for the system operation according to the method according to the invention. Typically, these are on the positive list the connoisseurs of approved registered media and on the negative list the connoisseurs unauthorized unregistered media.

Further advantages and features of the invention will become apparent from the following description with reference to FIGS. Showing:

1 shows a flowchart representation of the processes at an entrance system under

Using a contactless credit card and

2 shows a flowchart representation of the processes for the fare determination and

Billing after using a contactless credit card.

FIGS. 1 and 2 illustrate the method according to the invention further by way of example with reference to a transaction in a ticket distribution system according to the invention with a contactless credit card, the subsequent billing of the journey carried out and the decision as to whether the card is placed on the negative list.

Figure 1 shows by way of example and schematically that a contactless credit card 1 is used on a validator 2 for entry into the system. The card handling process 21 reads out the card data and recognizes that there is a credit card type card. For credit cards is searched in the local negative list 22, whether this card is registered there. If there is an entry, the customer will be notified on the display 23 (eg "card invalid") If no entry is found, the customer will be shown on the display 23 that the card is valid Map data is passed to the transaction logging process 24, which stores the usage of that card along with the device number, device location, date, time and other relevant data as a complete transaction record in local transaction memory 25. A transaction upload process sends this transact tone as soon as possible via data Upload 3 to the background system 4.

In the background system 4, the transaction is received by a central receipt process 41 and entered into the central card and transaction database 42. A fare calculation and billing process 43 combines the transactions associated with the card being used into a trip and possibly multiple trips to a trip and settles them with the credit card issuer (details are described in FIG. 2). If billing is not possible, the used Card is added as a new entry in the central negative list 44, which is distributed by the list download process 45 in the broadcast method 5 to all terminals. At the validator 2, the local list update process accepts the new list entries and stores them in the local positives and negatives lists 22.

Figure 2 shows an example and schematically the process for the fare calculation and billing of travel that have been made with a contactless credit card. From the central card and transaction database 42, the fare calculation process 43.1 extracts the uncancelled transactions associated with a credit card number and combines these into trips made with that credit card. Possibly. several trips are put together to a journey, and ultimately always a fare is determined. The fare is charged by the authorization process 43.2 to the credit card issuer 43.3 {outside the ticketing system). An evaluation 43.4 introduces two possible reactions to this settlement: the settlement was possible, ie the credit card was authorized for the travel price - then the trip is paid and no further action is necessary 43.5; or billing was not possible, ie the credit card was not authorized for the travel price - then the open claim is registered 43.6 and the card is added to the central negative list as a new entry 43.7.

C o m p a n c e m e n t i o n s

1 contactless credit card ("Open Payment" card)

2 cancellers

21 card-booking process

22 local positive and negative lists

23 Customer display of the validator

24 transaction logging process

25 Local transaction store

26 transaction upload process

27 List Update Process

3 Data upload from the validator to the background system

4 background system ("back office")

41 Transaction Receipt Process

42 Central Map and Transaction Database

43 processes for fare calculation and billing

43.1 Fare calculation

43.2 Authorization of the card

43.3 Credit card issuer (outside the ticketing system)

43.4 Authorization successful?

43.5 OK. No list entry.

43.6 Not OK: Register open payment.

43.7 Not OK: Set card to negative list.

44 Central positive and negative list

45 list download process

5 Data broadcast from the background system to the terminals

Claims

Patent claims

1. A method for operating an access authorization system, wherein the system comprises a computer network, with at least one background system forming a computer and at least one connected thereto via a data network computer in at least one arranged in an access area terminal, which terminal at least for reading identification media with each a system-wide unique machine-readable connoisseur is designed, characterized in that in the background system a positive / negative list representing data table is maintained in which is assigned to each necessary for system operation connoisseur, the validity or invalidity representing value, the positive Z negative list transmitted to terminals and stored by them and determined by the terminal after reading a connoisseur on the basis of the positive / negative list of validity status of the associated identification medium and an access weight decision is taken.

2. The method according to claim 1, characterized in that only the changes of the positive / negative list are transmitted from the background system to the terminals.

3. The method according to any one of the preceding claims, characterized in that read by the terminals connoisseurs and decisions are transmitted in the context of messages to the background system.

4. The method according to claim 3, characterized in that the background system determined based on received messages system usages.

5. The method according to claim 4, characterized in that the background system performs based on determined system usages billing operations.

A method according to any one of the preceding claims, characterized in that the background system alters and updates the positive / negative list on the basis of validity information.