CA2300048A1 - Improved travel pass/ticket issuing and/or validating system - Google Patents
Improved travel pass/ticket issuing and/or validating system Download PDFInfo
- Publication number
- CA2300048A1 CA2300048A1 CA002300048A CA2300048A CA2300048A1 CA 2300048 A1 CA2300048 A1 CA 2300048A1 CA 002300048 A CA002300048 A CA 002300048A CA 2300048 A CA2300048 A CA 2300048A CA 2300048 A1 CA2300048 A1 CA 2300048A1
- Authority
- CA
- Canada
- Prior art keywords
- pass
- gid
- ticket
- fare
- boarding
- 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.)
- Abandoned
Links
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
Landscapes
- Business, Economics & Management (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Devices For Checking Fares Or Tickets At Control Points (AREA)
Abstract
A travel pass system wherein travel passes are encoded with a geographical identity (GID) for at least the beginning and end points of a journey and a ticket machine on board the vehicle contains a CPU and a module containing a GID look-up table to enable travel passes to be validated by comparison of the GIDs encoded in a pass and the GIDs stored in the look-up table.
Description
WO 99/09524 PCTlGB98/02355 Title: Improved travel pass/ticket issuing and/or validatinct svstem Introduction This invention concerns an automated geographical ticketing system.
Backctround 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.
Backctround 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.
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 ap~oroach 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.
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 ap~oroach 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 dif ferent points along route such as fare stages and the like .
The invention therefore provides a method which allows interoperability between any number of mufti-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 codes) 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.
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 dif ferent points along route such as fare stages and the like .
The invention therefore provides a method which allows interoperability between any number of mufti-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 codes) 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;
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.
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 harmonised 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 Il 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 usincr the host 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 allots 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 -_. , , . ;._ ...._,_.._. _..__ ~. ._..__.__, ,--. :___. ..
.., ._.-..v _ .._ 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 j ourney 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).
._.. . . _ . .._ _ ___ . . _.._.. _ _,.
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 harmonised 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 Il 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 usincr the host 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 allots 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 -_. , , . ;._ ...._,_.._. _..__ ~. ._..__.__, ,--. :___. ..
.., ._.-..v _ .._ 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 j ourney 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).
._.. . . _ . .._ _ ___ . . _.._.. _ _,.
Claims (23)
1. 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 GIDs 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.
(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 GIDs 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.
2. A system according to claim 1, wherein the ticket machine includes means for indicating any payment required and for issuing a relevant ticket.
3. A system according to claim 1 or claim 2, wherein the pass includes further encoding on it to determine whether a strict or a lenient response is to be initiated, if the check on GIDs fails to validate the pass.
4. A system according to claim 3, wherein, in the case of a strict response, the ticket machine is arranged to reject the pass and the passenger is asked to leave the vehicle.
5. A system according to claim 3, wherein, 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.
6. A system according to any of claims 1 to 5, wherein, if the ticket machine is not provided with a module having a look-up table of GIDs and therefore has no means of interpreting the GID data from the pass, then either the machine checking of passes at boarding points is disabled, or the machine is programmed to trigger a lenient response whenever a pass is presented thereto.
7. A system according to any of claims 1 to 6, wherein the ticket machine is programmed only to use the GID in the pass to verify whether the boarding point is valid.
8. A system according to any of claims 1 to 6, wherein the pass must be shown before leaving the vehicle as well as before boarding, and the ticket machine is adapted 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.
9. A system according to any of claims 1 to 8, wherein each GID comprises the closest Post Office allocated Post Code.
10. A system according to any of claims 1 to 8, wherein each GID comprises a National Grid code.
11. A system according to any of claims 1 to 8, wherein each GID comprises a GPS code.
12. A system according to any of claims 1 to 11, wherein the GIDs are unique to a particular exact location or unique to an area containing a plurality of said locations.
13. A system according to any of claims 1 to 12, wherein, once a look-up table has been configured for each bus company, all pass issuers and all service providers share a common GID
definition for each boarding point and if appropriate each alighting point.
definition for each boarding point and if appropriate each alighting point.
14. A system according to claim 13, wherein the common GID
boarding point definition is encoded into a ticket or pass, and decoded by a card reader at a card acceptance point in the ticket machine.
boarding point definition is encoded into a ticket or pass, and decoded by a card reader at a card acceptance point in the ticket machine.
15. A system according to claim 14, wherein the common GID
boarding point definition is additional to text information about the boarding point which also appears on and may be encoded into the ticket or pass.
boarding point definition is additional to text information about the boarding point which also appears on and may be encoded into the ticket or pass.
16. A system according to claim 15, wherein the text information can be displayed on equipment at the card acceptance point in the ticket machine as a fall back option for manual use where a look-up table is not available or cannot be used.
17. A system according to any of claims 1 to 16, wherein groups of GID codes are compressed to minimise storage both in the pass and in a ticket machine.
18. A system according to any of claims 1 to 17, wherein the GIDs 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).
of a journey, or an interchange point (known as a VIA).
19. A system according to claim 18, wherein each pass holds as many lists of each node of the journey (START, END and VIA) as can be accommodated in the pass.
20. A system according to claim 18 or claim 19, wherein each pass holds 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.
21. A system according to any of claims 18 to 20, wherein 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.
22. A system according to any of claims 1 to 21, wherein GID
codes are allotted on the basis of any one or more of the following criteria:
(1) Post codes are allocated to fare stages only;
(2) All fare stages within the issuer's area are coded;
(3) The transport company maintains and provides to its ticket issuing and verifying machine a look-up table module of stages versus post codes, 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 post codes against that fare stage, for at least a given period of time;
(5) If a fare stage is removed then the post code 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 post code of the new fare stage for a given period of time - a changeover period; and (7) Several fare stages may share the same post code (i.e. fare stages which correspond to a bus station).
codes are allotted on the basis of any one or more of the following criteria:
(1) Post codes are allocated to fare stages only;
(2) All fare stages within the issuer's area are coded;
(3) The transport company maintains and provides to its ticket issuing and verifying machine a look-up table module of stages versus post codes, 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 post codes against that fare stage, for at least a given period of time;
(5) If a fare stage is removed then the post code 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 post code of the new fare stage for a given period of time - a changeover period; and (7) Several fare stages may share the same post code (i.e. fare stages which correspond to a bus station).
23. A system according to claim 22, wherein a ticket machine computer is 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.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9717049.2 | 1997-08-13 | ||
| GBGB9717049.2A GB9717049D0 (en) | 1997-08-13 | 1997-08-13 | Improved travel pass/ticket issuing and/or valdiating system |
| PCT/GB1998/002355 WO1999009524A1 (en) | 1997-08-13 | 1998-08-05 | Improved travel pass/ticket issuing and/or validating system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2300048A1 true CA2300048A1 (en) | 1999-02-25 |
Family
ID=10817369
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002300048A Abandoned CA2300048A1 (en) | 1997-08-13 | 1998-08-05 | Improved travel pass/ticket issuing and/or validating system |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP1004095A1 (en) |
| AU (1) | AU8639398A (en) |
| CA (1) | CA2300048A1 (en) |
| GB (2) | GB9717049D0 (en) |
| WO (1) | WO1999009524A1 (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002055960A (en) * | 2000-08-10 | 2002-02-20 | Nec Corp | System and method for card authentication |
| JP3468744B2 (en) * | 2000-09-06 | 2003-11-17 | 株式会社鷹山 | Automatic fare adjustment system |
| FR2899005A1 (en) * | 2006-07-25 | 2007-09-28 | Thales Sa | Vehicle e.g. tramcar, locating method for validating e.g. ticket with barcode, involves determining vehicle position data at given instant from global positioning system data and predetermined data associated to route traveled by vehicle |
| FR2923057B1 (en) * | 2007-10-29 | 2009-12-25 | Henri Bismuth | URBAN PUBLIC TRANSPORT SYSTEM |
| DE102011012061B3 (en) * | 2011-02-23 | 2011-11-17 | Db Systel Gmbh | Method for performing registration of passenger journey, involves comparing newly created registration record with same ticket support medium and transferring information about variation of ticket types to vehicle on-board computer |
| WO2014197949A1 (en) * | 2013-06-13 | 2014-12-18 | Transportme Pty Ltd | Ticket and conveyance management systems |
| EP3407306A1 (en) * | 2017-05-23 | 2018-11-28 | Siemens Aktiengesellschaft | Method for deduplication of public transport stations in overlapping geographical areas and corresponding route planner or ticketing system |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3859507A (en) * | 1968-05-24 | 1975-01-07 | Japan National Railway | Automatic ticket preparing and examining system employing sequential code |
| US4488035A (en) * | 1982-04-07 | 1984-12-11 | Dca Design Consultants Limited | Through-ticketing in a passenger transport system |
| US4758954A (en) * | 1984-07-25 | 1988-07-19 | Computer Services Corporation | Method of adjusting ticket fares |
| JP2892111B2 (en) * | 1990-06-29 | 1999-05-17 | 株式会社東芝 | Portable recording medium processing system, portable recording medium, automatic ticket gate, and passing point transmitter |
| GB2276266B (en) * | 1994-03-11 | 1995-11-22 | Ghazala Shaheen Jamil Malik | Trip recorder |
-
1997
- 1997-08-13 GB GBGB9717049.2A patent/GB9717049D0/en active Pending
-
1998
- 1998-08-05 AU AU86393/98A patent/AU8639398A/en not_active Abandoned
- 1998-08-05 CA CA002300048A patent/CA2300048A1/en not_active Abandoned
- 1998-08-05 GB GB9816911A patent/GB2328309B/en not_active Expired - Fee Related
- 1998-08-05 EP EP98937672A patent/EP1004095A1/en not_active Withdrawn
- 1998-08-05 WO PCT/GB1998/002355 patent/WO1999009524A1/en not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| GB9717049D0 (en) | 1997-10-15 |
| GB9816911D0 (en) | 1998-09-30 |
| GB2328309A (en) | 1999-02-17 |
| GB2328309B (en) | 2001-12-12 |
| WO1999009524A1 (en) | 1999-02-25 |
| EP1004095A1 (en) | 2000-05-31 |
| AU8639398A (en) | 1999-03-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4847451B2 (en) | Passenger transportation system and method for obtaining a ticket in the system | |
| EP0425961B2 (en) | Automatic toll exaction system for urban and extraurban highways, for bridge and tunnel crossings and for accesses to urban areas and car parks | |
| US6609658B1 (en) | Travel system and methods utilizing multi-application traveler cards | |
| US6910628B1 (en) | Travel system and methods utilizing multi-application airline passenger cards | |
| US6926203B1 (en) | Travel system and methods utilizing multi-application traveler devices | |
| US5101200A (en) | Fast lane credit card | |
| CA2414769A1 (en) | Method and system for accessing travel services | |
| KR20180122274A (en) | Traffic card data base bus information, boarding missing and missing data correction system | |
| JPH05505048A (en) | Pedestrian-vehicle communication system | |
| CA2300048A1 (en) | Improved travel pass/ticket issuing and/or validating system | |
| WO2013164579A1 (en) | Ticket validation apparatus and method | |
| RU2121163C1 (en) | Automatic system for transport for paying fare and checking tickets | |
| JP2010092328A (en) | Taxi management system | |
| JP7553951B2 (en) | Vehicle fare calculation system and vehicle fare calculation device | |
| RU2710802C1 (en) | Fare payment system in public transport and cargo movement monitoring using bluetooth technologies | |
| Bushnell | Smart Cards for Transit: Multi-Use Remotely Interrogated Stored-Data Cards for Fare and Toll Payment | |
| JP2785830B2 (en) | Ticket gate system | |
| JP2023080889A (en) | Common infrastructure system and common infrastructure program | |
| JP2023080885A (en) | Common infrastructure system and common infrastructure program | |
| ITMO970199A1 (en) | METHOD AND COMMUNICATION SYSTEM. | |
| US20070241181A1 (en) | Identification Information Managing Method and System | |
| KR20070027995A (en) | A ticketing management system and method for a predetermined residents | |
| Rowe | for Commercial Vehicle Operations-Requirements and Approaches | |
| Scott et al. | Vehicle-to-roadside communications for commercial vehicle operations-requirements and approaches | |
| Rowe | Recommendations on Selection |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued | ||
| FZDE | Discontinued |
Effective date: 20020805 |