Background to the invention In an environment where the deregulation of public transport initiative is encouraged then a ticket or pass may have to be valid across a number of different service providers and modes of transport. A revenue apportionment system is therefore essential, and one such system is described in UK Patent Application No. 9707451.2.

Currently and particularly in public transport, season tickets and travel cards are issued for prescribed journeys or travel within certain zones. Concessionary travel passes for use in or between designated areas may also be issued to groups of users (ie Scholars or Pensioners) at special rates subsidised by a third party, typically local authorities. The normal method of preventing misuse if such tickets or passes (ie for the wrong journey) is for the bus driver or a ticket inspector to manually examine the pass. This is slow and reliant upon the availability of a human operator. Ideally the checking should be automatic.

Transportation companies and third parties who subsidise travel, need to be assured that they are operating efficient and cost effective services for their customers. A system that provides them with information about journeys travelled and frequency of usage would enable such organisations to better manage their affairs. Ideally an automatic audit is required.

Summary of the invention According to one aspect of the present invention in a system which uses travel passes (which may be cards or tickets), a travel pass is encoded with a geographic I/D (GID) for each of the normal beginning and end points of a journey, and if appropriate similar (GID) information about any interchange points that are normally used, and a ticket machine on a public service vehicle includes a travel pass reader for deriving therefrom the GID information, and further includes means for receiving a module containing a look-up table of GID's for the route being followed by that vehicle, to enable a check to be made automatically by the ticket machine, as to whether the pass is suitably coded for boarding at the current fare stage, and if it is, to enable the passenger to board the vehicle and make any payment required, the ticket machine including means for indicating such payment as is required, and for issuing the relevant ticket.

Preferably the pass includes further encoding on it to determine whether a strict or a lenient response is to be initiated, if the check on GID's fail to validate the pass.

In the case of a"strict"response the ticket machine is arranged to reject the pass outright and the passenger is asked to leave the vehicle. In the case of a"lenient"response the driver is alerted to the situation and the ticket machine is arranged to display text information about boarding points, to allow the driver to exercise discretion in allowing the journey to continue, if appropriate.

If the ticket machine is not provided with a module having a look-up table of GID's and therefore has no means of interpreting the GID date from the pass, then either the machine checking of passes at boarding points is disabled altogether, or the machine is programmed to trigger a lenient response whenever a pass is presented thereto.

In one arrangement the ticket machine is only programmed to use the GID in the pass to verify whether the boarding point is valid.

In other arrangements where the pass must be shown before leaving the vehicle, as well as before boarding, the invention can be used to validate both boarding and destination points for single paid journeys on the same vehicle, or determine whether separate fares are to be paid for each leg of a journey.

Geographical pass usage Many concession systems specify specific areas of use or journeys that are allowed alongside other parameters, such as dates and times when the pass can be used.

The automatic checking of dates and times is relatively straightforward since these are globally understood and facilities therefore are readily available for any electronic ticket machine (ETM). The automatic checking of journey information is not so straightforward. There follows the rationale for, and the method selected to facilitate, the automatic"geographical"checking of journeys or zones where passes may be used.

The Manual approach Manual pass checking systems rely upon visual authentication by a driver/inspector. Whilst at off peak times a driver may be able to fastidiously check all the details written on a pass, at peak times it is highly unlikely that passes are thoroughly checked.

A driver may also be required to exercise discretion if pass holders board a bus or train at points between the start and end of a permitted journey.

The automatic approach Any automatic system should endeavour to minimise driver involvement whilst allowing flexibility in the criteria for pass acceptance.

There are a number of issues to overcome when considering how to automate geographical pass acceptance especially where passes are valid for journeys with more than one bus company and via different routes.

Passes may be used with different bus or train companies, but each bus or train company may have a different annotation for the location of fare stages (bus stops or stations).

Journeys may involve changing from buses or trains run by one company to buses or trains run by another.

A pass may be valid for more than one regular journey.

Frequently, new journeys/zones may be required.

Journey or zone information is often prescribed by third parties who use their own but different annotation for the description of journeys, particularly the combination of different points along route such as fare stages and the like.

The invention therefore provides a method which allows interoperability between any number of multi-modal transit companies and pass issuers.

By creating a link between an independent geographical position identifying system and the bus stops and fare stops used by bus and train companies, a very flexible geographical system can be implemented.

By identifying each bus stop/railway station (transit boarding point) by a unique geographical identifier, this will provide a unique identification number for the geographical location of every fare stage or station or embarkation or arrival point throughout the UK.

According to another aspect of the invention each GID comprises the closest Post Office allocated Post Code.

Because the postal code system describes large areas which are subdivided into smaller and smaller areas, fare stages can easily be grouped into progressively larger zones, where this is appropriate.

A look-up table connecting individual bus company fare stage coding to post codes can then be stored in the module insertable into a ticket validating machine (ETM). This look- up table should only rarely require changing, ie when bus stops or fare stages are relocated significantly.

Once a look-up table has been configured for each bus company all pass issuers and all service providers will share a common definition for each boarding point and if appropriate each alighting point. This common boarding point definition can then be encoded into a ticket or pass, and decoded by a card reader at a card acceptance point.

Preferably the common boarding point definition is additional to text information about the boarding point which also appear on, and may be encoded into the ticket or pass, and this text information can be displayed on equipment at a card acceptance point as a fall back option for manual use where a look-up table is not available or cannot be used for some reason.

By incorporating software linking post codes to a digital road/street map, into a clearing and settlement system such as described in UK Patent Application No. 9707451.2 the process of relating fare stages to post codes may be simplified and an analysis of journeys made.

The number of Post Code GIDs a pass can hold depends entirely on the amount of memory the pass contains. Because post codes break down into districts, sectors and units, groups of codes can be easily compressed to minimise storage both in the pass or in a ticket machine.

Preferably the Post Code GID's are stored in lists, and each list includes a header which defines whether the list holds the normal START of a journey (boarding point nearest the home of the pass holder), the END of a journey, or an interchange point (known as a VIA).

There can be as many lists of each node of the journey (START, END and VIA) as can be accommodated in the pass.

Passes may hold single or multiple post code (s) for any node of a journey to allow for different operators routes and node points to be permitted to the holder of the pass.

Where appropriate sector, district or area codes may be used to define successively larger areas.

Preferably each header to a list of post codes also carries information as to whether strict or lenient action should be taken if the pass is used at a boarding point which is not included within a list in the pass.

Allocation of post codes Preferably this is undertaken by the pass issuer, in conjunction with the transit companies, typically using the following basic principles: (1) Post codes shall be allocated to fare stages only.

(2) All fare stages within the issuers area shall be coded.

(3) The transport company maintains and provides to its ticket issuing and verifying machine a look-up table module of stages versus postcodes, typically by way of ticket machine configuration data.

(4) If a fare stage is moved to a new post code, then the look-up table must list the old and new postcodes against that fare stage, for at least a given period of time.

(5) If a fare stage is removed then the postcode of the deleted fare stage must be listed alongside the look-up table entry for the preceding stage for a given period of time for a changeover period.

(6) If a fare stage is added then the entry for the preceding stage must be listed alongside the postcode of the new fare stage for a given period of time-a changeover period.

(7) Several fare stages may share the same postcode (ie fare stages which correspond to a bus station).

A computer may be programmed to interpret the above logic and instructions to enable a validation process to be performed as a pass, and to be updated as changes occur.

The invention will now be further described, by way of example, with reference to the accompanying drawings, in which: Figure 1 shows the typical card details for scholars A, B and C which go to The Queens school, and are entitled to free travel from home to school and back, Figure 2 which shows in principle the main elements which have to be added to an existing manual scheme to validate passes, where passes can be used; Figure 3 is a block diagram of a card encoder; Figure 4 is a block diagram of a ticket machine; Figure 5 is a block diagram of a travel pass reader; Figure 6 is a functional flow diagram; Figure 7 is a block diagram of a complete system based on post codes; Figure 8 is a block diagram of a complete system based on National Grid coordinates; and Figure 9 is a block diagram of a complete system based on GPS.

In relation to Figure 1, Scholar A travels to school via the town centre, Scholar B travels to school directly but also regularly attends the school annex, and Scholar C travels via the railway station from two possible home locations.

As shown in Figure 2, there are three main elements to be added to existing"manual"schemes in order to automatically validate the places where passes can be used. These are: 1. A"smart"pass or ticket T, capable of holding in a memory, inter alia a list of post codes of valid boarding points for the pass/ticket.

2. A ticket validating machine M carried on the bus, train or other vehicle to be used by the pass/ticket holder, and containing a look-up table module referencing postcodes to boarding points (ie bus stops, railway stations, etc) which is adapted to compare the boarding point post codes stored in the pass with post codes in the look-up table to generate a validation signal, and memory means for storing details of the boarding point and permitted end point of the journey validated by the pass/ticket.

3. A central processing system S adapted to receive and analyse journey data stored in the memory of ticket validating machines.

Considering each in turn.

The smart pass or ticket The"smart"pass or ticket T, which may also be used for other functions, is preferably encoded by the issuer with the post codes of the boarding points permitted for the holder of the pass. This could be a season ticket for travel between two points defined by their full post code, or a pensioners pass coded with postcode districts allowing much wider use. Data referring to more than one permitted journey defined by boarding and end points, or areas of travel, may be stored in a single pass.

Each pass is also preferably encoded with a unique number which can be read by a ticket validating machine and stored in conjunction with the journey data in the machine memory, so that subsequently usage information may be made available via the central processing system to the pass/ticket issuers and/or transport companies.

According to a further aspect of the invention, such information could be used to debit customers later, and to facilitate customers who wish to pay on account.

The ticket validating machine When the passenger boards, for example, a bus, the pass or ticket is presented to the machine M by which it is read (in this case a bus ticket machine with reader attached). The machine provides a data comparison function by which it compares post codes read from the pass/ticket with a list of valid post codes held within a memory in the machine.

Providing there is a match a validation signal is produced and a visual and/or audible indication is provided, enabling the passenger to travel.

The machine also stores in a memory information about the actual boarding point against the card number. This date is kept so as to be available subsequently to be transferred to the central processing system via a machine to computer reader interface currently located at the bus depot.

The method by which a bus ticket machine calculates the fare to be paid depends upon a list of fare stages and prices held within the validator. Fare stages are signalled to the validator by the bus driver, who increments the stage number when approaching a bus stop that is designated a fare stage.

According to another aspect of the invention, the validator may include a transmitter/receiver unit for interrogating (or merely receiving signals transmitted from) a transmitter unit at each bus stop, preceding road sign or lamp post, which emits an encoded signal including the Post Code of the location, whereby the vehicle can automatically identify and update its location, for example by reading an electronic tag at a bus stop.

Every bus company numbers fare stages differently and even the same bus company may allocate a different stage number to the same bus stop in connection with different bus routes operated by the same company. If passes were coded with fare stage numbers they would only work with a single bus company, and then not reliably on overlapping routes.

By providing the additional look-up table in the ticket machine which relates Post Code GID's to fare stages the ticket machine will be able to identify the geographic location of each fare stage in the same way. Only by using this harmonise approach can an automatic pass validation scheme effectively be implemented.

The central processing system A preferred clearing system S is adapted firstly to allocate post codes to individual or groups of passes or tickets and secondly to accept the data collected from every pass or ticket used and log usage against journey details. Such information may be anonymous or not, depending on whether the owner of the pass/ticket can be identified from the pass/ticket serial number, and whether or not this is logged on the central database.

The post code system along with other data collected allows the clearing centre to analyse journeys individually or by area, graphically or otherwise for each different type of pass or ticket issued.

Alternatives to using the post code In principle any system that allocates a unique geographical identification (GID) to each boarding point could be used.

Post codes are initially preferred because: 1. Computer databases exist containing all UK post codes, which would be suitable for use in the central processing system.

2. There are published directories of UK post codes for given areas, which may be used by bus companies.

3. The system is graduated in size and has greater definition where population density is highest. This matches to a degree the density of bus stop distribution.

Instead of a post code, each bus stop could be given its National Grid reference or indeed its global position reference determined via satellite. In either case the principles used are the same. The National Grid or GPs references, could replace post codes in the card and the ticket machine look-up table, and in the central processing system computer memory.

The Global Positioning System data could be used to fully automate the input to the ticket machine, since it could eliminate the need for tags or other transmitting devices on bus stops or lamp posts, by mounting a GPS decoder to each vehicle (bus, train or the like). A back-up method may be needed in places where the satellites are screened, such as high buildings etc.

Figure 3 shows a travel pass card encoder. From an empty card store 10, a card to be issued is supplied to a printer 12 which prints with information supplied from a data base 14 details of the scope of the card to be issued. The card then passes to a card reader 16, whereupon a card serial number is drawn at station 18. This number is fed through a master code key allocation station 20 and thence to a sub-code allocation station 22 which all. ots the card a unique code for the particular master code. This code information is applied to the card in card writer 24, from which emerges a printed and encoded card 26 ready for use.

Figure 4 shows details of a ticket machine on board a vehicle.

When a bus, for example, is to undertake travel on a particular route, the driver inserts a module 28 containing a look-up table appropriate to that route into the machine, for use by a machine CPU 30.

In use, a travel pass card 32 is inserted to a card acceptor 34, where it is checked by a security device 36. In conjunction with the CPU 30 and the look-up table, the card is checked for its validity for a particular journey, whereby the printer 38 is able to issue a paper ticket 40. An electronic ticket option 42, linked to the card 32, may also be provided.

As shown in Figure 5, the items 34,36 constitute a travel pass reader. The data stored in the card 32 is only readable after allocation of a password (code) unique to that card. The card acceptor 34 communicates with the card 32 via a radio frequency interface. Electronics in the security device 34 controls reading and possible writing of the card, and checks its authenticity. It may also decode journey information from the card. In any case, use of the card is logged in the ticket machine.

Operational variations possible when a card is inserted into the ticket machine are shown in Figure 6. These operational variations will be clear from the preceding description of machine operation in strict and lenient mode, according to whether or not a GID system 44 is active.

Figure 7 is a diagram of a system using GID post codes for bus companies 1, n and train companies 1, n. These transport providers have a common description of each boarding point (TBP) converted into a TBP post code ID, loaded into the ticket machine as a look-up table module.

The card issuer provides journey details converted to post code IDs, which are encoded on the card, either in full or in abridged form (area codes), dependent on the travel pass conditions. The ticket machine compares the TBP IDs in the GID look-up table and conveniently displays the journey details encoded on the card, logging the location of each transaction.

The use of post code IDs enables a card to be used with any transport provider.

Figure 8 shows a system using National Grid coordinates instead of postcode IDs and Figure 9 shows a system using GPS instead of post code IDs.

In the system of Figure 8, the National Grid IDs (NG IDs) used may be full location specific (10 digits) or area general (8 digits).

Again, in the system of Figure 9, the GPS IDs used may be full location specific (14 digits) or area general (10 digits).