CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
_1_
A P.~1RHING MANAGEMENT SYSTEM
The present invention relates to parking management systems and, more
particularly, to
parking management systems capable of implementing a variable fee structure
for charging
parking fees.
Historically, parking meters have mostly been used as stand alone units for
measuring a time
interval for which a user pays to park in a particular marked parking position
and to indicate
whether there is still part of that interval remaining. These parking meters
generally require
payment in advance and will stop timing once the paid parking period has
expired. They will
then display, or be able to display, the "expired" status to indicate to
parking enforcement
officers that a fine or an infringement notice should be issued.
Developments in parking management have since seen small computer processors
included in
1 S the meters which enable the meter to keep time, and receive payment, for a
number of different
parking bays. However, it is still often necessary for enforcement officers to
patrol the parking
areas in order to issue infringement notices and fines.
One purpose of a parking management system is to assist the owner or manager
of the parking
area in policing its use. There: are a number of issues associated with
achieving this purpose,
namely: collecting fees from users; enforcing the payment of fines or
penalties levied for
unauthorised or excessive use of the parking area; controlling the parking
system technology;
and providing for the automation of the system so as to reduce the required
policing manpower.
It is desirable that a parking m;3nagement system should be so self sufficient
that no manpower
is required for policing it and it need only be checked occasionally for
maintenance purposes;
enforcement officers should be notified automatically of particular instances
of infringement
so that they may direct their efforts more efficiently; additionally, the
means for receiving
payment and methods of time-metering should be flexible so as to assist in
achieving the
parking resource management goals of the owner of the parking resource.
It is an object of the invention to provide a parking management system and
method which
CA 02346908 2001-04-12 PCT/AU99/00831
Received 22 September 2000
PvbPFR~SSBlaptoslm.doc-21N9N0
-2-
achieves the above goals, or which at least provides a useful alternative to
known systems
and methods.
The present invention provider a parking management system including:
sensing means for sens ing the presence of a vehicle in a parking position;
a housing module having:
communication means for communicating with a network;
transaction means, in communication with the communication means and
accessible to a user of the system, adapted to process data to effect a
payment; and
processing means, in communication with the transaction means for
monitoring the sensing means and for determining the payment for an overall
time period
during which the presence of the vehicle is sensed;
wherein the payment is determined according to a variable fee structure
applicable
to the overall time period and i:; effected at the end of the overall time
period.
Preferably, the variable fee structure includes a base charging rate and a
variable charging
rate, the base charging rate being applicable for a first time period and, if
the vehicle is
sensed longer than the first time period, the variable charging rate being
applicable for a
second time period after the first time period. Preferably, the overall time
period is equal to
the sum of the first and second time periods: Preferably, the base charging
rate is constant
over the first time period and the variable charging rate changes over the
second time
period. Preferably, the variable charging rate increases over the second time
period.
Alternatively, the variable charging rate decreases over the second time
period.
Preferably, the overall time period is the period of time between an initial
receipt of
payment information and receipt by the processing means of a user-actuated
parking
termination signal.
.AMEcI~t?f~"t ~~.r.~-_..
i~;«_
CA 02346908 2001-04-12 PCT/AU99/00~91
Received 22 September 2000
P:10PFR1SSHVaplmlnes.doc-23N9AD0
-2A-
Preferably, the user-actuated parking termination signal is actuated by the
user, either
by providing a termination instruction to the processing means through the
transaction means, or by moviing the vehicle out of the parking position and
thereby
causing the sensing means to cease to detect the presence of the vehicle in
the
parking position.
-_:,-;.
r -° .
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-3-
Preferably, if the presence of the vehicle is sensed after a grace period
before or after the
overall time period, the processing means is adapted to communicate an
infringement signal
to an enforcement body over the network. Preferably, a nil charging rate is
applicable during
the grace period.
S
Advantageously, said charge rate may vary over a predetermined period of time.
The charge
rate may be low initially .and then increased to a high rate when the time
reaches a
predetermined level. The charge rate may increase linearly or otherwise over
the
predetermined period of time. A penalty charge rate may be selected after the
time reaches
a predetermined level.
Preferably, the sensing mean is adapted to sense the presence of one or more
vehicles in
respective one or more parkvag positions. Preferably, the sensing means
includes at least one
presence detector which may preferably be an induction coil for each parking
position.
Preferably, the housing further includes display means for displaying
information to the user,
in communication with the processing means.
Preferably, the transaction means includes card reading means for reading
credit card
information and manual input means for receiving an authorisation code from
the user.
Preferably, if the user inputs a special vehicle authorisation code into the
transaction means,
a nil charging rate is applicable for at least a part of the overall time
period.
Preferably, the transaction means includes cash payment means for receiving
cash payment.
Preferably, the transaction means includes card reading means for reading
stored-value card
information and manual input means for receiving a payment authorisation code
from the user.
Preferably, the communication means is adapted to communicate with a financial
institution
for determining whether the authorisation code is valid and whether there is
sufficient credit
available to the user to effect the payment. Preferably. the communication
means is in
communication with a central control station, the central control station
being adapted to
CA 02346908 2001-04-12 PCT/AU99/0089I
Received 22 September 2000
P:10PFR1SSBUqalro.doc-32/09100
-4-
receive operational information and financial transaction information from the
processing
means over the network.
Preferably, the processing means includes memory means. Preferably, the system
further
includes a transportable programming device adapted to interface with the
processing
means for reconfiguring thereof and for reading and writing data from and to
the memory
means. Preferably, the memory means includes further memory means for storing
system
configuration data, the control station heina arla"tP~ rn calo,.t:,.o1<.
..t..._~.. .,__
configuration data stored in the further memory means. Preferably, the
programming
device is also adapted to interface with a data processing means of the
central control
station.
Preferably, the transaction means includes means for sensing when an access
door to
internal components of the housing has been opened.
Preferably, the system further includes diagnostic means for performing
diagnostic
inspection thereof. Preferably, the diagnostic means of each parking meter
includes fault-
condition monitoring and counting means for fault monitoring and storing fault-
related
data. Preferably, the diagnostic means is controlled by the processing means
and is adapted
to transmit the fault-related data to the control station through a
communications network.
Preferably, the housing further includes printing means for printing a receipt
for payment.
The present invention further provides a parking meter, including:
sensing means for sensing the presence of a vehicle in a parking position;
a housing module having:
communication means for communicating with a network;
transaction means, in communication with the communication means and
accessible to a user of the system, adapted to process data to effect a
payment; and
processing means, in communication with the transaction means for
monitoring the sensing means arid for determining the payment for an overall
time
rt ~~..; ;,
.'w Nl,_, ..: ..; ~° . _ ~-.
'F .;-
CA 02346908 2001-04-12 PCT/AU99/OOg91
P:~OPER~SSBIaploslrts.doc-13N9iU0 Received 22 September 2000
-4A-
period during which the presence of the vehicle is sensed;
wherein the payment is determined according to a variable fee structure
applicable
to the overall time period and :is effected at the end of the overall time
period.
The present invention further provides a parking management system including a
plurality
of parking meters as described above.
Preferably, the communication means of each parking meter is in communication
with a
central control station, the central control station being adapted to receive
operational
information and financial tra~lsaction information from the processing means
of each
parking meter over the network:.
Preferably, each parking meter is in communication with one or more local
controllers,
each of which is in communication with a central control station, the central
control station
being adapted to receive operational information and financial transaction
information
from the processing means of each parking meter via the one or more local
controllers.
Preferably, the parking management system may be directly connected to a local
controller
or directly to a control station via a terrestrial, or wireless public or
private network. The
local controller may also be cormected to the control station by via a
terrestrial, or wireless
public or private network. The local controller may be connected to a data
communication
interface of the control station ~ria a terrestrial, or wireless network,
regardless of whether
the network is public or private.
Preferably, the parking management system may include one or more of the
following:
means for sensing when an EFT unit is located in the housing and means for
sensing when
a coin/token unit is located in the housing.
~,~...,~~,, "..!__
~r ,
CA 02346908 2001-04-12 PCT/AU99/00891
Received 22 September 2000
P:~OPER~SSBlaqosl,es.doc-73A79IO0
Each parking meter preferably includes an electronic card authenticator. The
memory
arrangement of each meter includes operational data regarding the number and
value of
cards received. The operational data may be transmitted to the control station
through a
communications network.
AMEi'~~~~., ~~;.,~.._
Ilc~.~,,~,: ~ ._.:.
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-6-
Preferably, each parking meter may incorporate an electronic coin or token
authenticator. The
memory arrangement of the parking meter includes operational data regarding
the number and
value of coins or tokens received.
5 Preferably, each parking mcaer may include a real time clock. The processing
means and real
time clock of each parking :meter being adapted to allocate time data to
predetermined events
and to store said time data .and data relating to the kind of event in the
memory arrangement.
The real time clock on the parking meter may be synchronised with the control
station time by
the said communications neawork or the field programming device.
The present invention further provides a method for effecting payment for
parking, including
the steps of:
monitoring a presence signal, representative of the presence or absence of a
vehicle,
from at least one parking bay;
receiving payment information from a user of said parking bay which enables a
payment;
selecting at least onE: charging rate, of a plurality of charging rates,
applicable over at
least one respective charging period;
determining a length of time said vehicle is present in said at least one
parking bay in
response to the presence signal;
determining the payment based on the selected said at least one charge rate
applicable
over the length of time; and
effecting the payment.
The present invention further provides a method for managing a parking system,
including the
steps of:
sensing the presence or absence of a vehicle in a parking position;
selecting one or more fee charging rates from a plurality of fee charging
rates
applicable under one or more circumstances of use of the system;
receiving payment information relating to the payment of fees and
authorisation thereof
by a user of the system;
CA 02346908 2001-04-12
WO 00/Z3949 PCT/AU99/00891
establishing a start time from which fees may be charged, the establishing of
said start
time being responsive to the: sensing of the presence of said vehicle in said
parking position;
establishing a finish time beyond which fees will not be charged, the
establishing of
said finish time being responsive to a timing termination signal actuated by
said user;
5 calculating fees to be received from said user based on said one or more fee
charging
rates applicable under said one or more circumstances of use between said
start time and said
finish time;
using said payment information to effect receipt of a payment from said user
based on
said calculated fees.
The present invention further provides a method of managing a parking resource
including a
plurality of parking positions, the method including the steps of:
providing one or more parking meters, as described above, to monitor
utilisation of the
parking positions;
1 S providing a connection to each parking meter, through a communications
network, to
a control station having processing means;
causing each parking meter to regularly perform self diagnostic tests and to
store data
relating to those tests;
causing each parking meter to store operational data relating to payment
transactions
performed by that parking :meter;
causing the parking meters to transmit the data relating to the self
diagnostic tests or the
operational data to the con~~trol station in real time;
and, at the control :station, processing said data in real time for producing
one or more
reports based on the processed data.
The method may also include the step of causing each parking meter to
continually sense
whether a vehicle is parked in a parking position monitored by that parking
meter anc
transmitting data relating to occupation of that parking position to the
control station in rea
time.
The method may also include the step of causing the parking meter to print
ticket:
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
_g_
infringements notices, or re<;eipts for vehicles parked in a parking position
monitored by that
parking meter.
Preferably, parking meter configuration data stored in each parking meter may,
from time to
time, be updated by transmitting new configuration data from the control
station via said
comununications network.
Preferred embodiments of the present invention will now be described, by way
of example
only, with reference to the a~xompanying drawings, in which like components or
elements are
indicated by like reference numerals.
Figure 1 is a block diagram of an embodiment of a parking management system;
Figure 2 is a further block diagram of the parking management system;
Figure 3 is a block diagr~un of a parking meter of the parking management
system in
accordance with the embodiment of Figure 1;
Figure 4 is a more detailed block diagram of the parking meter of Figure 3;
Figure 5 is a block diagram of the electronic funds transfer (EFT) components
of the parking
meter of the embodiment shown in Figure 3;
Figure 6 is a block diagram of a field programming device and a retrieval
machine of the
parking management system of Figure 1;
Figure 7 is a block diagram of system data flow of a parking management system
in
accordance with an embodiment of the present invention;
Figure 8 is a block diagram of the parking management system architecture;
Figure 9 is a flow diagram of a bay monitoring and initial detection procedure
of the parking
management system of an embodiment of the present invention;
Figure 10 is a flow diagram of a payment initiation procedure of the parking
management
system of an embodiment of the present invention;
Figure 11 is a flow diagram of a credit card payment procedure of the parking
management
system of an embodiment of the present invention;
30 Figure 12 is the first part of a flow diagram of a smart card (or stored
value credit card)
payment procedure of the parking management system of an embodiment of the
present
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-9-
invention;
Figure 13 is the second pant of a flow diagram of a smart card (or stored
value credit card)
payment procedure of the parking management system of an embodiment of the
present
invention;
S Figure 14 is the third part of a flow diagram of a smart card (or stored
value credit card)
payment procedure of the parking management system of an embodiment of the
present
invention;
Figure 15 is a flow diagram of an enforcement notification procedure of the
parking
management system of an embodiment of the present invention;
Figure 16 is a flow diagram of an internal monitoring and security procedure
of the parking
management system of an embodiment of the present invention;
Figure 17 is a data flow diagram of the vehicle detection procedure of the
parking
management system of an .embodiment of the present invention;
Figure 18 is a data flow diagram of the smart card transaction procedure of
the parking
management system of an embodiment of the present invention;
Figure 19 is a data flow diagram of the EFT transaction procedure of the
parking management
system of an embodiment of the present invention;
Figure 20 is a data flow dliagram of the internal monitoring and security
procedure of the
parking management system of an embodiment of the present invention;
Figure 21 is a data flow dliagram of the enforcement notification procedure of
the parking
management system of an embodiment of the present invention;
A parking management system 2, as shown in Figures 1 and 2, includes a
plurality of parking
meters 12 connected to a control station 14 via communication networks having
data
communication links 16. The control station 14 includes a data processor 18,
and a datz
communication interface 20. Each parking meter 12 can monitor one or more
parking bay:
(Figure 2 shows each parking meter monitoring 5 parking bays). Sensors for
detecting thf
presence of a vehicle in a parking bay in the form of vehicle presence
detectors 24.1 to 24.N
as shown in Figure 4 (whe,re N is the number of parking bays) axe connected to
an electronic
controller 26 of the parking; meter 12. Although other sensors are
contemplated, not the least o
which are those employing electromagnetic radiation, electromechanical sensors
or magneto
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-10-
resistive sensors, only inductive loop vehicle detectors will be described
hereafter. The vehicle
presence detector can be located just below the road surface in the parking
bay, and/or in the
associated curb-side in the ~~icinity of the parking bay. More than one
vehicle presence detector
may be required per parking; bay to satisfy banking requirements. With the use
of more than one
vehicle presence detector, the parking meter 12 can also determine the
direction and rate of entry
of a vehicle to the parking bay. Since the vehicle presence detectors 24.1 to
24.N are connected
to the electronic controller 26 of the parking meter 12, providing a binary
status indicator for
the parking bay is a way of indicating the parking bay occupancy status.
The parking meters are inter-connected in parking meter communication systems
28.1, 28.2 and
28.3, shown in Figures 1 and 2. The parking meter communication system 28.1
may utilise a
local network to connect a plurality of parking meters 12 to the local
controller 83. The parking
meter communication system 28.2 may utilise a local network to connect a
plurality of parking
meters 12 to the local controller 83, with the local network extended with the
use of modems
82 (for example, to traversf; a roadway). The local controller 83 in turn is
connected to the data
communication interface 20 of the control station 14 via modems 84. The
parking meter
communication system 28.3 may utilise a.modem 74 to connect a plurality of
parking meters
to the data communication interface 20 of the control station 14. Since these
systems are similar,
only parking meter communication system 28.1 will be described hereafter.
As best shown in Figure 5, each parking meter 12 includes an electronic funds
transfer (EFT;
unit 105, the electronic controller 26, a keypad 107, display 108, mufti-mode
reader/writer 11:
and an LED panel 109.
Each parking meter 12 ha:~ one or more doors (not shown) for allowing access
to the inside o
the meter housing and which are closed and locked during normal operation. A
sensor 58, fc
determining whether the doors are open, is electronically connected to the
electronic controlle
26. This allows the system to check whether the doors are open due to
vandalism or because c
a routine maintenance check. A temperature sensor 64 and a timer 65, including
a real tizr
clock 66, are electronically connected to the electronic controller 26. The
temperature sense
64 is for providing temperature calibration to the LCD display 108 so as to
obtain the be
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-11-
display quality. An electronic coin/token validator 68 and a speaker/buzzer 57
is connected to
the electronic controller 26 and a contact-less smart card
transmitter/receiver 113 is connected
to the EFT unit 105.
5 Power for the parking meter is connected to the electronic controller 26 by
the power connecter
56, this power supply may include a battery with solar recharge and/or a mains
supplied power
feed. The power may also lie distributed in a mufti-core cable along with the
parking meter
communication system 28.1, 28.2, and 28.3.
10 Memory 72, connected to the electronic controller 26, is arranged to
include a region 72.1 for
storing program data for controlling operation of the meter, a region 72.2 for
storing
configuration data, a region 72.3 including fault condition flags and counters
and a region 72.4
for storing operational data, such as the total amount of cash/tokens in the
cash/token box and
the number of coins/tokens of each denomination in the cash/token box, the
number and value
15 of fees processed by the EF'f unit 105 and the number and t<pes of cards
processed by the EFT
unit 105.
Also forming part of the system are a portable field programming device 90 and
a portable
retrieval machine 96. The field programming device 90 includes a controller
having a data
20 interface 92 and memory !~4. The retrieval machine 96 includes a controller
having a data
interface 98 and memory 1 (10. Both of these devices can be connected to the
data processor 18
of the control station 14 or the electronic controller 26 of a parking meter
12. The field
programming device 90 and/or the retrieval machine 96 may be in the form of a
hand-held
portable computer such as a Hewlett Packard HP 620LX.
25
The field programming device 90 is connectable to the data processor 18 of the
control station
14 to receive programme dz~ta and/or configuration data and/or synchronised
time data. The field
programming device 90 may then be connected to the electronic controller 26 of
a parking metes
12 to download and store data in the memory 72 of that parking meter. The
retrieval machine
30 96 has a unique identity code stored in its memory 100. When connected to
the electronic
controller 26 of a parking meter 12, it is interrogated for the code. If the
code corresponds to the
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-12-
code stored in the memory '72 of the parking meter 12, predetermined data is
loaded from the
parking meter 12 into the retrieval machine 96. The data so received is loaded
into the data
processor 18 of the control station by subsequently connecting the retrieval
machine 96 to the
data processor 18.
A parking meter 12, with its vehicle presence detectors 24.1 to 24.N, is in
communication with
the control station 14 via tJle data lines 16. Data relating to the operation
and status of each
parking meter 12 may thus be communicated to the control station 14 for real-
time or batch
processing and control. Such data includes: data indicative of whether a
parking bay 22.N is
vacant or occupied by a vehicle. this data being generated by the vehicle
presence detectors
24.N; data relating to the amount of cash/tokens received by the parking meter
during a
specified time period or the total amount of cash/tokens in the cash/token box
54; data relating
to the card transactions conducted by the parking meter during a specified
time period or the
total amount of card transactions by the EFT unit 105; data relating to the
results of diagnostic
tests on the parking meter:, or data indicating that a vehicle is parked in a
parking bay 22.N
during a time period which. is not paid for.
The results of diagnostics tests performed on the individual parking meters
12, whether
automatically initiated, initiated by the field programming device 90 or
directly from the control
station 14, are stored in memory region 72.3 and transmitted via the
communication lines 16 to
the control station 14 or other centralised venue to assist technicians in the
maintenance of the
meters 12. Memory region 72.3 stores a plurality of fault condition flags and
associated fault
condition counters. Together with the real time clock 66, the electronic
controller 26 allocate:
time stamps to fault conditiions detected. T'he fault condition counters count
the number of time:
different fault conditions acre detected. This data is then made available to
the control station 14
Configuration data is stored in the memory 72 of each parking meter 12. Such
data may relat~
to card or EFT transaction characteristics, fee changes, operating hours,
number of parking bay
to be controlled by a parking meter, text to be displayed on display 56 or
special days havin
special rates. Identity codes may be compiled by means of a configuration
editor prograr
resident in the data processor 18 at the control station 14 and sent via the
communications lint
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99J00891
-13-
16, and loaded into the parking meters 12 to be stored in the configuration
data region 72.2 of
memory 72. In response to the real time clock 66, a parking meter I2 may be
required to change
on a specified day from an existing tariff table stored in region 72.2 to a
new tariff table also
stored in region 72.2. Tariff tables for specific groups like the disabled,
local residents, shop
5 owners, public transport workers and couriers may be loaded into the parking
meters 12 to be
stored in the configuration data region 72.2 of memory 72.
The EFT unit 105 has a memory I 19 and is connected to the electronic
controller 26. The
electronic controller 26 passes data to the EFT unit 105 which may be loaded
into an operational
data part 117 of the EFT memory 119 and which may be displayed on display 108.
The multi-
mode card reader/writer 112 collects information from a user's card at the
start or end of a
transaction and stores it in the operational data part 117. The mufti-mode
reader/writer 112 can
simultaneously or individually accept information from a mufti-track magnetic
stripe reader 111
and/or a integrated chip smart card reader/writer 110. A LED panel 109 and
display 108
indicates when to insert or remove a card and displays information such as
card or transaction
error messages. Contact-less smart cards can also be processed by a contact-
less smart card
transmitter/receiver I I3. The keypad 107 is used to enter the user's personal
identification
number (PIN) into the EFT' unit 105, which is normally a banking requirement
for debit card
transactions. The keypad 1 ()7 may or may not be required for credit or stored
value integrated
chip smart card transaction.a or cash/token transactions.
The control station 14 may upload program data to the EFT unit I05 to be
stored in a program
part 114 of the EFT memory 119 via the communication link 16. Program data can
also be
transferred to the memory 72 of the electronic controller 26 by the data
communication link 16
or the field programming device 90. The electronic controller 26 then
transfers the program data
to the program part 114. The field programming device 90 can transfer program
data directly
to the program part 114.
The control station 14 may also upload configuration data to the EFT unit 105
to be stored in
a configuration part 115 of the EFT memory 119. Configuration data can also be
transferred to
the memory 72 of the electronic controller 26 by the data communication link
16 or the field
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-I4-
programming device 90. The electronic controller 26 then transfers the
configuration data to the
configuration part 115 via the EFT unit 105. The field programming device 90
can transfer
configuration data directly to the configuration part 115.
5 The control station I 4 can transmit or receive diagnostic data from the EFT
unit 1 OS to be stored
in a diagnostic part 116 of flue EFT memory 119. Diagnostic data can also be
transferred to and
from the memory 72 of the electronic controller 26 by the data communication
link 16 or the
field programming device 90. The electronic controller 26 then transfers the
diagnostic data to
or from the diagnostic part 116 via the EFT unit 105. The field programming
device 90 can also
transfer diagnostic data directly to or from the diagnostic part 116.
The control station 14 can transmit or receive operational data to or from the
EFT unit 105 and
an operational part 117 of the EFT memory 119. Operational data can also be
transferred to the
memory 72 of the electronic controller 26 by the data communication Iink 16 or
the field
programming device 90. The electronic controller 26 can then transfer the
operational data to
the operational part 1 I7 via the EFT unit 105. The field programming device
90 can transfer
operational data directly to or from the operational part 117. The electronic
controller 26 can
transmit or receive operational data to or from the EFT unit 105. Operational
data can relate to
the text to be printed on the optional printer 55 or the status of the vehicle
presence detectors
22.1 to 22.N.
The electronic controller 2ti can determine the operational status of the EFT
unit 105 and
contents of the EFT memory 119.
2~ During manufacture, the EFT unit 105 may be loaded with encryption programs
stored in the
EFT memory 119. Also, the EFT unit 105 can be loaded with a unique pad
identification
number and secret RSA encryption key and stored in the encryption part of the
EFT memory
I 19. When the EFT unit 105 communicates on-line with a bank 103 for the first
time, the EFT
unit 105 registers with the bmk's Key Initialisation Host to authenticate the
pad identification
number and secret encryption key stored in an encryption part 118. Once
verified as the correct
EFT unit I O5, the bank 103 transfers the Digital Encryption Security (DES)
key to the EFT unit
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
- IS -
105 to be stored in the encryption part 118.
The vehicle presence detector 24.N identifies when a vehicle enters the
parking bay 22.N
and the electronic controller 2.6 commences timing with the timer 65. The
parking meter
12 then awaits cash/tokens e~r card details and the display 56 or 108 directs
the user to
enter a card. A speaker/buzzer 57 may prompt the user to supply payment or
payment
details if he or she is slow to do so. The user enters cash or tokens into the
coin/token
validator 68 or card details :into the mufti-mode reader/writer I 12 and, for
debit card
transactions, Personal Identification Number (PIN) details by the keypad 107.
The card
and PIN details are encrypted using the encryption algorithm in the program
part 114 of
the EFT memory 119 and thc: secret encryption keys stored in encryption part
118. The
EFT unit 105 can process the transaction by one of two methods: firstly by
exception-
processing of invalid cards, whereby the transaction details associated with
valid cards are
stored in memory for later processing with the bank 103 or private label card
issuing
authority I04; secondly, the EFT unit 105 sends the message authentication
code (ie.
encrypted transaction details ) to the electronic controller 26, which then
transmits the
parking meter details and message authentication code (MAC) to the control
station I4
via the communication link 16. The control station then interfaces with the
bank 103 or
private label card issuing authority 104 to verify the details of the card and
PIN details
encrypted in the message authentication code.
The reloading of monetary or other values on stored-value cards (ie. smart
cards or
combination smart card and magnetic strip cards having a stored value on the
card) can
be processed by the parking meter 12 using the mufti-mode reader/writer 1 I2
and the EFT
unit 105 over the communication links 16 with the control station 14, bank I03
or private
label card issuing authority 1'04.
The parking meter 12 can use the communication links 16 with the control
station 14 to
redeem customer loyalty rewards held in the customer loyalty program 101 as an
alternative method of payment.
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
- 16-
If the card and PIN details are correct and the transaction is approved, the
bank 103 or
private label card issuing authority 104 transmits the approval for the
transaction to the
control station 14 which in turn transmits the approval to the EFT unit 105
via the
electronic controller 26 and communication link 16. At the end of the period
during
5 which the vehicle is in a parking position, and immediately prior to
departure, a user may
end the transaction. If a printer 55 is installed, a receipt for the
transaction can be
requested and printed. If a receipt is requested, a grace period will be
allowed to permit
the user to return to the vehicle and drive it away. If the vehicle is not
driven away before
the expiration of the grace: period, the charge is re-activated from the time
of the
10 commencement of the grace period, and the charging continues until either
the vehicle is
driven away, or a further reduest is made for a receipt. The fees will then be
charged to
the user's card account.
If the card or PIN details are incorrect or the transaction is not approved,
the bank 103 or
15 private label card issuing authority 104 transmits the disapproval for the
transaction to the
control station 14 which in turn transmits the disapproval to the EFT unit 105
via the
electronic controller 26 and communication link 16 and the EFT unit 105
displays the
decline of the transaction to the display 108.
20 If the bank 103 or private label card issuing authority 104 determines that
a card may
have been used fraudulently, the bank 103, private label card issuing
authority 104, or
control station 14 can notify the appropriate policing authority of the
location and time
where the alleged fraud took place, and whether the vehicle present in the
parking bay
22.N at the time of the alleged fraud is still there.
When the vehicle presence detector 24.N identifies that a vehicle has departed
the parking
bay 22.N or if the parking arrangement is otherwise terminated, the EFT unit
105
calculates the total time the vehicle was in the parking bay and applies
linear, and/or non-
linear, and/or stepped tariffs ~to calculate the fee associated v~~zth parking
in the parking bay
30 for that period of time. Transaction details are then encrypted and the EFT
unit 105 sends
the message authentication code to the electronic controller 26. The
electronic controller
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
- 17-
26 then transmits the details of the parking meter 12 and message
authentication code to
the control station 14 via the communication link 16. The control station then
interfaces
with the bank 103 or private label card issuing authority 104.
Linear tariffs are those which are constant for each unit of time, eg. $20 per
day or $6 per
hour. Non-linear tariffs are those which increase or decrease the fee per unit
of time over
a longer period of time, resulting in a fee which exponentially increases or
which
asymptotically reaches a maximum. Stepped tariffs involve charging a base
linear or non-
linear charge and then charging an increased fee at a specified time. Stepped
tariffs are
used as the basis for levying fines for overstaying the paid time in the
parking position.
Fees may also be calculated i:n terms of a base rate and a variable rate.
These rates will be
applicable over a base rate period and variable rate period respectively.
During the base
rate period, the fee will increment by a number of uniform fee units per
uniform time unit.
During the variable rate period, the fee rate may vary on a sliding scale per
time unit.
The time units may be uniform or variable. A variable number of fee units may
be able
to be charged per time unit. ~f'lhe fee unit and the time unit is set to suit
parking resource
objectives of the parking authority 102 and may not be the same as those used
in the base
rate period. For example, with a base rate period of one hour, each time unit
may be six
minutes, and the base rate period fee unit 20 cents. The fee for occupying the
bay for one
hour would therefore be two dollars. During the variable rate period, the fee
rate may be
40 cents per two minute time unit for the first 20 minutes, increasing to one
dollar per 90
second time unit thereafter. In this example, the variable time rate therefore
acts as a
disincentive for users to leave their vehicle parked longer than the paid time
but does not
penalise them too harshly for an initial period of overstaying.
Locations and times may have designations such as "Parking permitted",
"Parking
restricted" or "Parking not permitted".
3O
For example, "Parking permitted" means that any vehicle may park in the
parking position
CA 02346908 2001-04-12
WO 00123949 PCT/AU99100891
-18-
and pay the appropriate fee,
"Parking restricted" means 'that only certain classes of user may occupy the
parking bay
22.N, for example, a resident with special parking rights, with or without a
fee, who enters
a special identification information into the meter 12.
"Parking not permitted" means that no vehicle is permitted to park in the
parking position
at any time while the "Parking not permitted" signal, in whatever fashion, is
displayed.
10 The duration of a time block which will attract a set fee may be varied.
For example, the
chargeable time block may be set at seconds, minutes, hours. days, or
multiples thereof.
Once the vehicle remains in the parking position for part of the time block,
the tariff
chargeable will be a set monetary amount which will permit occupation of the
parking
position by that vehicle for i:he whole of the remaining time in that time
block.
The control station 14 may also interface with customer loyalty programs 101
to facilitate
earnings rewards for using tl;~e system. The control station 14 may also
provide details on
occupancy, faults, trends, damage, electronic funds transfer or other relevant
information.
Authorized organisations may be granted access to receive information to the
extent that
their authorization allows. The appropriate authorized municipality 102 may
interface
with the central control station to update, add, or modify control parameters
for parking
meters in their domain.
Data relating to the total amount of card transactions received by each
parking meter 12
can be reconciled with the bank 103 or other card issuer 104 at the control
station 14.
The electronic controller 26 of each parking meter 12 is adapted, upon a
signal from the
vehicle presence detector 24 shat a vehicle is no longer present, to reset the
timer 65, every
time a vehicle leaves the parking bay 22.N, thereby increasing revenue from
the parking
meter 12 (because the next user will not be able to use unexpired time paid
for by the
previous user). Further, data indicating that a vehicle is parked in a parking
bay 22.N
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
- 19-
during a time period not paid for is accessible from the control station 14.
This data may
be used to direct the relevant policing authority to such a parking bay 22.N
for further
action.
If the card used to initiate the fee payment transaction is reinserted into
the multi-mode
card reader/writer 112 or the contactless smart card transmitter/receiver 113,
the EFT unit
105 will then immediately calculate the total amount of fees owing and
transmit it to the
control station 14.
Data relating to the distribution of vehicles over a parking resource as a
whole is
accessible from the control station 14 at any time. Accordingly, vehicles may
be routed
to areas of the parking resow-ce which are under-utilised. Alternatively, the
standard or
variable tariffs for parking areas of higher use may be increased and those
for areas of
lower use may be decreased. This would facilitate a more even distribution of
vehicles
over the parking resource and thus help to manage the parking resource more
effectively.
Parking meter municipalities 1'. 02 can communicate with the control station
14 and via the
data communication interface 20 so as to access data relating to parking
resources they
possess rights to. They may also upload into the data processor 18 new fee
schedules,
tariff changes or changes in the availability of particular parking meters 12
or bays 22.N.
All communications between the control station 14 and parking meters 12 take
place over
a communications network 16. The parking meters 12 effectively act as slaves
to the data
processor 18. A parking meter generally transmits data in response to being
polled by the
control station 14, local controller 83, when an EFT transaction is being
processed or
when a programmed event occurs in the parking meter 12.
The system 2 allows for a grace period during which a car may have been sensed
as
occupying a parking position taut for which the user is not charged. This is
to allow time
for the user to approach the ne~~rest meter, decide on a method of payment and
enter either
payment or payment information, after which entering, charges for use of the
parking
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-20-
position may accrue. If the user remains in the parking position 22.N longer
than the grace
period without entering a vaJlid payment, the enforcement authority will be
notified.
In the case of payment by cash or smart card, the whole of the period of the
timed parking
arrangement will have been pre-paid. In the case of payment by debit or credit
card, the
charge will be automatic on departure of the vehicle from the parking
position. In the case
of payment by debit or creel card, should the user require a receipt for the
parking
payment, the charge, and therefore the receipt, will cover the period of time
up to the end
of the current time block for that meter.
The system uses vehicle detecaion to charge a user from the time the vehicle
enters to the
time the vehicle exits the parking position, and allows the fees attributable
to the whole
period of use to be automatically debited to the user's account after the
vehicle departs.
Within the grace period after the vehicle arrives, the user nominates the
account to be used
by using a valid payment mechanism. Valid payment mechanisms include, but are
not
limited to, standard credit or debit cards incorporating a magnetic stripe
and/or magnetic
smart card or integrated chip card issued by recognized financial institutions
participating
in electronic funds transfer or other authorized private label card issuing
authorities, as
well as the redemption of customer loyalty rewards.
Figure 7 shows the data transfer relationships of the elements of the parking
management
system 2 (also referred to herein as an automatic parking management system
(APMS)).
The data concentrator 83 (also referred to hereinbefore as local controller
83) provides a
communications interface betvveen the control centre 14 and each of a
plurality of parking
meter controllers 26 (also hereinbefore referred to as electronic controllers
26). The
control centre 14 is configured to communicate with a number of data
concentrators 83
at various locations. The control centre 14 provides a central interface 15 to
facilitate
operation and control of the system by a supervisor.
The parking meter controller 26 is located within the parking meter 12 and is
in
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-21 -
communication with the EF":C unit 1 O5, local user interface (including keypad
107, display
108 and LED panel 109), internal sensors 58, 64 and vehicle detectors 24.
A transportable programrr~ing/retrieval device (being either one or both of
the
aforementioned field programming device 90 and milking machine 96 as shown in
Figure
6) is adapted to interface with each of the control centre 14, data
concentrator 83 and
parking meter controller 26.
Figure 8
The Control Centre communicates with a number of Parking Meter Controllers in
the field
via the Local to Central Communications Link. It batches and transmits EFT
transaction
data to the Financial Clearing House.
The Control Centre:
~Alerts the Enforcement Authority of any violations.
~Maintains a historical records.
~Monitors alarm data.
~Performs hardware checks.
~Monitors by other elements of the system.
The Central Interface receive; and displays prompts and alarms from the
Control Centre,
and allows the Supervisor to call up information and perform searches of its
various
databases as required. The Central Interface may also allow the input and
dissemination
of Fee Tables and other data within the APMS.
The Data Concentrator provides communications between a number of Parking
Meter
Controllers and the Control <:entre. The Data Concentrator receives and stores
hatched
data from Parking Meter Controllers.
A Parking Meter Controller located within each Parking Meter controls that
meter via the
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-22-
a local area network (LAN), and monitors and operates the following field
devices:
~Internal Sensors
~User Interface
~Vehicle Detector
~EFT Unit
The Parking Meter Controller performs:
~Fee calculation
~Transmission of data to and from the User via the User Interface
~Transmission of data to the LEFT Unit required to process a fee transaction
~Timing of the charging period
~Error checking and routing of encrypted transaction data from the EFT Unit to
the
Financial Clearing House
~General communications with the EFT Unit
Other functions of the Parking; Meter Controller include:
~Real-time processing of the data from the vehicle sensors.
~Communication with the Data Concentrator (transmittal of hatched data).
~Communication at asynchronous intervals with the Control Centre via the Data
Concentrator (transmittal of alarm and violation alerts).
~Error checking of data transmitted and received. This may alternatively be
carried out by
the Communications Links.
~Diagnostics monitoring of field devices.
~Monitoring and reporting on the mechanical security of the Parking Meter
Controller.
The EFT Unit is used by the P~crking Meter Controller to process Credit Card
and Smart
Card transactions and encrypt the data for transmittal to the Financial
Clearing House.
The User Interface provides ini:ormation to the User via a display
incorporating text and
diagrams. The user may input data to the User Interface via a keypad. The
keypad and
display functions may be combined with those of the EFT Interface on one
physical unit.
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
- 23 -
Each vehicle detector monitors the presence of vehicles in a particular
parking bay
controlled by the APMS. This information is transmitted to the Parking Meter
Controller.
If a detector is detected to have failed then the detection processor deems
the car space to
be vacant and immediately to;rminate any transaction.
The bay monitoring and initi,~l detection procedure is shown in Figure 9.
The procedure begins with th.e bay empty at step 900.
Step 905. The parking bay is monitored for the presence of a vehicle.
Step 910. The presence/absence of a vehicle in the parking bay is registered.
Step 915. Timing of the parking duration of the vehicle is commenced.
Once the presence of a vehi<:le has been established, and the timing
commenced, the
Payment Initiation procedure is commenced at step 1005. Other procedures feed
into the
bay monitoring and initial detection procedure at step 905 as shown in Figure
9.
The payment initiation procedure is shown in Figure 10. This procedure ensures
that:
~the Bay number is entered arid is valid.
~The User selects the preferred Card payment option.
~A vehicle present in the parking bay either commences pa~-ment procedures or
leaves.
~The Enforcement Authority is notified by the Control Centre of any vehicles
not paying
for parking.
The payment initiation procedure described below requires that the User carry
out actions
in the following logical sequence:
1. Park the vehicle in the bay
2. Enter the bay number into t:he User Interface
3. Select a payment option
Step 1005. A message prompting the User to enter a bay number is displayed on
the User
Interface. The other steps which feed into this step are shown in Figure 10.
Step 1010. The APMS determines if the User has entered the bay number.
Step 1012. A Grace Period is given to Users to complete payrzent initiation
procedures.
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-24-
If this period expires prior to payment initiation, the User is considered to
be in violation
of parking rules and the Enforcement Notification procedure is initiated at
step 1500.
Step 1 O 14. While the APMS waits for the bay number to be entered, it checks
if the User
exits the parking bay. If this happens before the end of the Grace Period, the
procedure is
cancelled at step 1050 and the Parking Duration is reset to zero.
Step 1015. The Bay Number entered by a User is checked for validity. This
ensures that:
a) The number is a vz~lid bay number for that parking meter;
b) The number of the bay which is entered is currently occupied by a vehicle.
Step 1017. If an invalid Bay Number is entered, an error message is displayed,
and the
User is prompted to enter the number again.
Step 1020. The APMS prompts the User to select their preferred payment option
(Credit
Card, Smart/Credit Card or Manual Cancellation of Parking ).
Step 1025. The APMS deternaines if the Credit Card option is selected. If so,
the Credit
Card Payment procedure is indtiated at step 11 O5.
1 S Step 1030. The APMS determines if the Smart/ Credit Card option is
selected. If so, the
Smart/ Credit Card Payment procedure is initiated at step 1200.
Step 1040. The APMS determines if the vehicle leaves the Parking Bay.
Step 1045. The APMS allows Users a Grace Period after parking their vehicle in
a parking
bay. This is to allow them to:
a) Identify the number of the lparking Bay they have parked in
b) Locate the Parking Meter
c) Initiate Payment procedures
Should the Grace Period be exceeded then the Enforcement Notification
procedure is
activated at step 1500.
Step 1050. If the vehicle has Ieft the bay, the parking duration is reset to
zero.
The credit card payment procedure is shown in Figure 11. When the User
commences the
Parking Period, the APMS will record and store the User's credit card details.
When the
parking period is concluded. the transaction is processed and stored for later
batch
transmission to the Financial (Jlearing House.
Processing of the Credit Card transaction may be initiated in three ways:
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-25-
~The vehicle leaves the bay;
~The User re-enters the same card used to terminate the charge period;
~The vehicle exceeds the maximum parking period allowable.
The applicable Parking Fee is calculated on the basis of the total Parking
Duration, with
the Base Rate and Variable Hate components as required.
The parking duration is not s~~t manually but is calculated automatically;
based on when
the vehicle leaves, the card is re-entered, or the vehicle exceeds the maximum
parking
period. Users can park to the end of the Base Rate Period (at the Base Rate)
plus a
Variable Rate Period (chargE:d at the Variable Rate Fee). The end of the
Variable Rate
Period will constitute the effective time limit for parking when using a
Credit Card to pay
the fee.
At step 1105, the APMS verifies the validity of the credit card.
Step 1110. If the card is invalid, an error message is displayed and the card
is rejected.
The Payment Initiation procedure is activated at step 1005.
Step 1115. Details required may include:
Bay Number
Start time
~ Card details
Account details
Step 1120. The APMS monitors the Parking Bay.
Step 1125. If a vehicle leaves .a parking space without swiping the credit
card, the APMS
determines if the vehicle leaves the Parking Bay.
Step 1130. The appropriate perking fee is calculated.
Step 1132. The information required by the APMS is stored for later
transmission.
Step 1134. The parking duration for that parking bay is reset to zero, and the
Bay
Monitoring and Initial Detection procedure is initiated (step 905).
Step 1135. If the User exceeds the maximum allowable parking duration, the
APMS
determines if the maximum allowable parking duration has been exceeded.
Step 1140. The appropriate perking fee is calculated.
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/0089I
-26-
Step 1142. The information required by the APMS is stored for later
transmission and the
Enforcement Notification procedure is initiated (step 1500).
Step I 145. If the User re-enters the Credit Card used to set up the fee
period, the APMS
determines if the User entered the credit card used to set up the payment
period.
S Step 1150. The appropriate sparking fee is calculated.
Step I I52. The information required is stored for later transmission.
Step 1 I55. A receipt is printed.
Step 1160. The APMS determines if the vehicle has left the parking bay.
Step 1165. The parking duration for that parking bay is reset to zero and the
Bay
Monitoring and Initial Detection procedure is initiated (step 905).
Step 1170. The APMS detetrnines if payment procedures are initiated. If so,
the Parking
Initiation procedure is initiated (step 1105).
Step 1175. The APMS determines if a predetermined grace period has elapsed. If
the
grace period has elapsed, then and the Enforcement Notification procedure is
initiated
(step 1500).
Users can pay for parking fees using a combination Smart/Credit Card. The
procedure for
this payment method is shown in Figures I2, 13 and 14. The User parks the
vehicle, keys
in the Bay Number and swipes the SmartlCredit Card. The APMS deducts from the
Smart
Card element the Base Rate Fee for the full Base Rate Period. The APMS records
and
stores the details of the Credit Card element needed to complete a Credit Card
transaction
as shown in Figure 11. Charging for the duration of the Base Rate Period is
terminated in
one of the following ways:
1. The User drives the vehicle away. If the User does not re-enter the
Smart/Credit
Card, the APMS retains the full amount deducted from the Smart Card element.
2. The User re-enters the Smart/Credit Card. As the Base Rate period has not
ended, the APMS refunds the unused parking fee to the User, transferring the
credit to the Smart Card element.
3. The vehicle remains in the bay beyond the end of the Base Rate period. The
APMS ends the Smart Card charging and retains the full fee for the Base Rate
Period. Charging for l:he Variable Rate Period is commenced (using the Credit
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-27-
Card details).
Termination of charging for the Variable Rate period, and processing of the
Credit Card
Transaction, may proceed in. any of the following ways:
1. The User drives th~~ vehicle away. The APMS charges the Credit Card account
at the Variable Rate :for the period occupied.
2. The User re-enters the SmartJCredit Card. The APMS charges the Credit Card
account at the Variable Rate for the Variable Period occupied, and prints a
receipt.
A period of grace is allowed for the User to vacate the bay, beyond which the
Enforcement Notification procedure is initiated (step 1500).
3. The vehicle remains in the bay beyond the end of the Variable Rate period.
The
APMS charges the Credit Card account at the Variable Rate for the full
Variable
Rate Period. The Enforcement Notification procedure is initiated (step 1500).
The following is the procedure for the Srnart Card payment component.
Step 1200. The APMS prompts the User to enter the Smart/Credit Card.
Step 1205. The APMS checks that the Smart/Credit Card is of a type accepted by
the
system and is a valid card.
Step 1210. An error messagc: is displayed indicating that the Smart/Credit
Card is not
valid and the Payment Initiation procedure is re-initiated (step 1005).
Step 1215. The APMS reads the amount of credit available on the Smart Card
element of
the card, and determines if this is sufficient to pay for the Full Base Rate
Period.
Step 1220. If not, a message is displayed to the User that insufficient funds
remain on the
card for this type of payment, and that the parking fee may be paid for
exclusively with
the Credit facility on the card.
Step 1225. The User indicates if they wish to use the Credit facility on the
entered card.
If so, the Credit Card Payment procedure is initiated (step 1105). If not, the
Payment
Initiation procedure is re-initiated (step 1005)
Step 1230. The valid paymern: amount is transferred from the Smart Card to the
APMS.
Step 1235. Details are recorded. These may include:
- Bay Number
Start time
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-28-
Card details
Amount
Step 1240. Details are read from the card, recorded and stored.
Step 1300. The APMS monitors the Parking Bay.
If a vehicle leaves a parking space prior to the Smart Card credit being used
up:
Step 1305. The APMS determines if the vehicle leaves the Parking Bay.
Step 1310. Excess credit is rf:corded.
Step 1312. Information required is stored.
Step 1314. The parking duration for that parking bay is reset to zero, and the
Parking
Initiation procedure is recommended (step 905).
The Following section applies if the User re-enters the SmartlCredit Card used
to set up
the Smart Card charging process.
Step 1315. The APMS confirms that the initial card used is re-entered.
Step 1320. The amount of unused credit is calculated.
Step 1322. The APMS transfers the unused credit to the Smart Card element of
the card
as a refund.
Step 1324. Information required is stored.
Step 1340. A receipt is printed.
Step 1345. The APMS determines if the vehicle has left the parking bay.
Step 1350. The parking duration for that parking bay is reset to zero and the
Bay
Monitoring and Initial Detection procedure is recommended (step 905).
Step 1355. The APMS determines if payment procedures are initiated. If so, the
Parking
Initiation procedure is initiated (step 1005).
Step 1360. The APMS determines if a predetermined grace period has elapsed. If
the
2~ grace period has elapsed, the Enforcement Notification procedure is
initiated (step 1500).
If the Smart Card credit is used up prior to the vehicle leaving the Parking
Bay or the User
cancelling the payment Period.
Step 1330. The APMS determines if the Smart Card credit has been used up (i.e
the Base
Rate Period is complete).
Step 1335. Fee Charging against the Credit Card element entered in (9) above
is
commenced.
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-29-
Step 1400. The APMS monitors the Parking Bay.
If a vehicle leaves a parking space without swiping the SmartlCredit card.
Step 1405. The APMS determines if the vehicle leaves the Parking Bay.
Step 1410. The appropriate sparking fee is calculated.
Step 1412. Information required is stored.
Step 1414. The parking duration for that parking bay is reset to zero, and the
Bay
Monitoring and Initial Detection procedure is recommended (step 905).
The following section applies if the User exceeds the maximum allowable
parking
duration.
Step 141 S. The APMS detennines if the allowable parking duration has been
exceeded.
Step 1420. The appropriate parking fee is calculated.
Step 1422. Fee details and other information required by the APMS, Bank, etc
are stored
for later transmission and the Enforcement Notification procedure is initiated
(step 1500).
If the User re-enters the Smart/Credit Card used to initiate the fee period:
Step 1425. The APMS dete rmines if the User entered the Smart/Credit card used
to
initiate its free period.
Step 1430. The fee is calculated.
Step 1432. Information required is stored.
Step 1435. A receipt is printed.
Step 1440. The APMS determines if the vehicle has left the parking bay.
Step 1445. The parking duration for that parking bay is reset to zero and the
Bay
Monitoring and Initial Detection procedure is recommended (step 905).
Step 1450. The APMS determines if payment procedures are initiated. If so, the
Parking
2~ Initiation procedure is initiated (step 1005).
Step 1455. The APMS determines if a predetermined grace period has elapsed.
This
allows the User to complete: payment procedures, receive the receipt, and
leave the
parking bay. If the grace period has elapsed, then and the Enforcement
Notification
procedure is initiated (step 1500).
The enforcement notification procedure is shown in Figure 15:
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-30-
Step 1500. Having identified that a vehicle is in violation, the APMS may send
Parking
violation data to the appropriate Enforcement Authority.
Step 1505. The APMS continues to monitor the bay (in violation).
Step 1510. The APMS continues to record the time of overstay.
Step 1515. The User may leave the parking bay before any Enforcement actions
are
initiated.
Step 1520. If so, the parking c(uration for that bay is reset to zero, and the
APMS resumes
monitoring the empty bay. T)ze records of the overstay may be retained by the
APMS if
required.
Steps 1525, 1530. To process a violation, the APMS advises the Enforcement
Authority
that nominated parking locations are in violation.
The internal monitoring and :security procedure is shown in Figure 16:
Step 1600. System operations are monitored. These involve the receiving,
transmission,
storage, processing and display of data. Records are retained for later
review.
Step 1605. An error is registered in the operation of the APMS
Step 1610. The physical integrity of the APMS is monitored. By physical
sensors.
Step 1615. A fault in the physical integrity of the APMS is detected.
Step 1620. The current status of the various subsystems within the APMS is
recorded.
Step 1625. The system status is transmitted to the Control Centre.
Step 1630. It is determined whether this is a previously reported fault, or is
new.
Step 1635. The new fault is recorded.
Step 1640. The fault data is tr;~nsmitted to the Control Centre.
Step 1645. The continuance o f an existing fault is recorded
Step 1650. The continuance of the existing fault is transmitted to the Control
Centre.
The vehicle detection data flow is shown in Figure 17:
Step 1700. The presence or absence of a vehicle in a parking bay generates a
response in
the vehicle detector installed i:n that bay.
Step 1705. The sensor response: is transmitted asynchronously from the Vehicle
Detector
to the Parking Meter Controller that controls that bay. This information is
preferentially
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-31-
conveyed by means of a physical wireline circuit between the detector and the
Parking
Meter Controller.
Step 1710. The sensor response is registered by the PMC that controls that
bay. This data
is used by the PMC to calculate the Parking Duration for the vehicle, and to
generate a
S parking record (Parking Data) for that bay.
Step 1715. Parking data is batch transmitted to the Data Concentrator as
required. This
data is preferentially conveyed using a packet radio network designed for
handling
frequent small transactions. 'The protocols shall use Cyclic Redundancy Code
(CRC)
checking and error detection .appropriate to the data radio network selected
for the area.
Alternatively, the information can be conveyed to the Data Concentrator by
physical
wireline using low speed modems. Alternatively the information can be conveyed
over
a TCP/IP Local Area Network using multidrop fibre optic links.
Step 1720. As the transmittal i:ime requirements between this device and a)
the PMC and
b) the Control Centre may be different, this device shall be capable of
storing and
rebatching hatched data received from the PMC devices, prior to forwarding it
to the
Control Centre. The Data Concentrator does not perform any data manipulation
or
conversion but acts as a data roister with appropriate storage. Preferentially
the Data
Concentrator is provided with .an Intelligent Data Switch capable of
concentrating packets
of data.. Such data packets would contain all information concerning a
specific
transaction including ID, address and CRC code.
Step 1725. Parking Data is batch transmitted to the Control Centre
preferentially via a
packet radio network. The protocols shall use CRC checking and error detection
appropriate to the data radio neawork selected for the area. Alternatively the
information
can be conveyed via dial-up o r fixed wireline services using modems
appropriate to the
line speeds available in the area. Preferentially such data rates shall be a
minimum of 28.8
KB/sec.
Step 1730. The Control Centre stores and maintains a current "picture" of the
whole
system, for the purposes of system monitoring, and generating a Parking
History for the
areas controlled by the system.
Step 1735. Data held and generated by the Control Centre may be transmitted to
the
Central Interface asynchronously as required by the Supervisor. Preferentially
this
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-32-
information shall be conveyed using fixed wireline services using modems
appropriate
to the line speeds available in the area. For very large installations ISDN
Iinks can be
provided to meet the service response times needed to meet operational
requirements.
Such services shall use CRC checking and error detection to maintain system
data
S integrity. Alternatively fibrf; optic links can be used in place of wireline
services.
Alternatively information can be conveyed over a TCP/IP Local Area Network
using fibre
optic or twisted pair links depending upon the separation of the Control
Centre and the
Central Interfaces.
Step 1740. The Central Interface will display system data as required. This
may include
a current "snapshot" of the system, system history and other data as required.
The Central
Interface must be able to display prompts and receive input from the
Supervisor. This
interface may also include links to other organisations (such as the
Enforcement
Authority) and field operatives (such as the Technician or Operator) to enable
the
accessing of information, and transmission of fault alarms and data,
enforcement
information etc.
The EFT transaction data flow is shown in Figure 18:
Step 1800. The User enters a Credit Card into the EFT Interface. This device
reads off
identification data and any other data required by the APMS or Financial
Clearing House
to process the transaction. This; device also carries out any checksum or
other accuracy or
security procedures. The Card Reader may temporarily store data for use with
checksum
or other procedures.
Step 1805. Card data and error checking data is transmitted asynchronously
between the
EFT Interface and the EFT Unit. Securit<~ measures, such as encryption or use
of dedicated
lines, may be used as required.
Step 18I 0. If required, the Receipt Printer prints a receipt of the
transaction using the data
provided by the EFT Unit.
Step 1815. Receipt data is transmitted asynchronously from the EFT Unit to the
Receipt
Printer.
Step 1820. The EFT Unit identifies and verifies the card and Generates data to
be printed
on the receipt. Credit transfer data to be sent to the Financial Clearing
House may be
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-33-
encrypted prior to being sent.
Step 1825. Data is transferred between the EFT Unit and the Parking Meter
Controller
asynchronously. Security measures, such as encryption or use of dedicated
lines, may be
used as required.
Step 1830. The User Interface; receives and transmits data and instructions to
and from the
User. The User Interface m,ay temporarily store data for use with checksum or
other
procedures.
Step 1835. Data is transmitted between the User Interface and the Parking
Meter
Controller (asynchronously) ass required. Security measures, such as
encryption or use of
dedicated lines, may be used as required.
Step 1840. The Parking Meter Controller performs calculations and stores data
based on
information received from thc: Card Reader and User Interface. The PMC is the
primary
source of transaction timing and will be periodically checked for accuracy by
the Control
Centre. Preset fee tables are also used that are stored by the Parking Meter
Controller.
This device transmits the transaction records, as well as encrypted
transaction data to the
Control Centre.
Step I 845. Data transmitted to the Data Concentrator is not required for
response time to
the User. As such, this data may be sent in batch form, at times that suit the
economic and
operational requirements of the system. Security measures, such as encryption
or use of
dedicated lines, may be used ;~s required.
Step I 850. The Data Concentrator receives batched data from a number of
Parking Meter
Controllers. This data may be immediately batch transmitted to the Control
Centre, or may
be stored and compiled for batch transmission at a different schedule that
suits the
economic and operational requirements of the system
Step 1855. Data is batch transmitted between the Data Concentrator and the
Control
Centre.
Step 1860. The Control Centre compiles a Transaction History from the
Transaction
Records. It also assembles encrypted Transaction Data for batch transmission
to the
Financial Clearing House.
Step 1865. Data is transmitted between the Control Centre and the Central
Interface
(asynchronously) as required.
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-34-
Step 1870. The Central Interface displays the Transaction History, and
displays and
receives instructions and prompts to and from the Supervisor.
Step 1875. Transaction Data is batch transmitted at regular intervals to the
Financial
Clearing House. The results of these transactions may be transmitted back to
the Control
S Centre at regular intervals a:; required. Security measures, such as
encryption or use of
dedicated lines, may be used as required.
Step 1880. The Financial Clearing House processes the transaction data and
provides
credit to the various municipalities, authorities, etc., as required. This
aspect of the
operation is outside the scope; of the APMS.
The internal monitoring and operational status data paths are shown in Figure
19.
This section covers the flow of information generated by the System Monitoring
and
Operational Status procedure s. In general these take the form of:
Physical sensors, whose output can be directly monitored. This includes the
vehicle
1 S detectors, door sensors, there iometer etc.
System devices, which can transmit a "heartbeat" at regular, predefined
intervals to
confirm their functionality and the integrity of the communication line.
Fault Notification. This data its generated as a result of a fault being
detected by a device,
and transmitted to the Control Centre. This may be triggered by a missing
"heartbeat"
signal or other fault that a particular device is designed to detect.
System operations records, generated by various system devices as a record of
the
processes, transactions, faults detected etc and transmitted to a central
point (the Control
Centre) for storage and review.
The paths that this data takes are described in Figure 19. The individual
processes are as
?S follows:
Steps 1900, 1905, 1910, 191 S. Each peripheral device transmits either a
continuous signal
or a "heartbeat" signal to the Parking Meter Controller. Some signals go via
an
intermediary device. depending on the normal communication paths used. Those
intermediary devices may be able to register faults and notify the Parking
Meter
Controller. The intermediary devices also provide heartbeat signals on their
own.
Step 1920. The Parking Me~:er Controller collects and collates the various
signals
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
- 35 -
received. If a fault is detected, fault notification is transmitted
asynchronously to the
Control Centre (via the Data Concentrator). The system monitoring data
received by the
Parking Meter Controller also is collated into the Operations Record, which is
transmitted
as a batch at regular intervals to the Control Centre.
Steps 1925, 1930, 1935. In general, batch data is transmitted at regular
intervals from the
Parking Meter Controller to the Control Centre. However. fault notification
may be
required to be transmitted as soon as it is detected.
Steps 1940, 1945, 1950. The Control Centre stores and collates the data
received into the
System History databases. The Supervisor is notified of any faults that are
detected via the
Central Interface, and can access the System History to display more data if
required.
The enforcement notification data flow is shown in Figure 20:
Step 2000. The Parking Meter Controller registers a parking violation, as part
of its
parking monitoring activities.
1 S Step 2005. The violation data is transmitted immediately (asynchronously)
to the Data
Concentrator.
Step 2010. The Data Concentrator routes the data through to the Control
Centre. Data may
be stores temporarily for the purposes of error checking.
Step 2015. The violation data is transmitted immediately (aswchronously) to
the Control
Centre.
Step 2020. The Control Centre registers the violation and enters it into its
Violation
History database. The Control Centre then generates a Violation Alert for the
relevant
Enforcement Authority. The firm of this transmittal will depend on the
requirements of
the authority.
Steps 2025, 2030. The Violation alert and violation data is transmitted to the
Enforcement
Authority in a prearranged format. The authority may respond with a message
confirming
reception of the data and/or that action has been carried out.
Glossary of terms
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-36-
APMS
Automatic Parking Management System. This refers to the electronic devices and
associated processes defined in this document.
Base Rate Period
The time period during whiclh a vehicle parked in a bay attracts a Base Rate
parking fee.
This period commences when the vehicle enters the bay.
Control Centre
The central point for the administration and control of the APMS by the
Supervisor.
Credit Card
This refers to any card used to facilitate the transfer of funds or credit
stored remotely.
For the purposes of this specification, this term refers to the Credit Card
ability of a
particular card, as some cards may be able to perform Credit Card, Charge Card
and
Smart card functions. See also the definition of Smart Card below.
EFT
Electronic Funds Transfer. 'This includes any credit card, debit card or
charge card
transaction in which funds arc; not transferred immediately in real time from
the account
of the customer to the account of the merchant.
EFT Fee Processing
For the purposes of this specification, this refers to the calculation of the
applicable
parking fee to be charged, a.nd transmission of the fee and EFT data to the
Control
Centre, for later hatched transmission to the Financial Clearing House.
EFTPOS
Electronic Funds Transfer Point of Sale system. In these transactions, the
account of the
customer is immediately deb ted. These transactions always require a PIN
number to
be keyed in and they never require a signature. Verification of card details
is done in
CA 02346908 2001-04-12
WO 00/23949 PGT/AU99/00891
-37-
real time.
EFT Transaction Initiated
This refers to the initial entry of an EFT card through the card reader that
prompts the
storage of the EFT data and commencement of the EFT charge period.
Enforcement Authority
The entity with the responsibility of enforcing penalties for parking
violations on behalf
of the Parking Authority.
Financial Clearing House
The entity responsible for the collection and distribution of fees collected
by the APMS,
normally expected to be a bank.
Fine, penalty
The fee to be charged to a u:;er in cases of a parking violation by that user.
GST
Goods and Services Tax
Grace Period
In general, this refers to the period between the initiation and the
implementation of a
particular function that allows time for an action or actions to be carried
out. For
example, Users are allowed a Grace Period after parking their vehicles to
allow them
2~ to locate the relevant Parking Meter and initiate payment, prior to being
considered in
Violation (see below). There .are several Grace Periods used by the APMS, and
separate
descriptions of these are given in the text of this document as they occur.
Parking Authority
The ultimate body responsible: for the control and regulation of parking in
the area. This
may be a local government body or the owner or manager of the parking resource
and
CA 02346908 2001-04-12
WO 00/23949 PC'T/AU99/00891
-38-
may include the enforcement authority.
Smart Card
This refers to any card having funds stored on the card itself. For the
purposes of this
specification, this term refer;> to the "Smart Card" ability of a particular
card, as some
cards may be able to perform both Smart and Credit card functions.
Special Vehicle
Vehicles accorded special parking rates, times and times etc. These may be
council
vehicles, courier vehicles, vehicles of local residents and others where
special parking
rates and/or times have been pre-arranged with the Parking Authority. For the
purposes
of this specification it is assumed that the status of special vehicles is to
be determined
from a coded card which can be read by the card reader.
Supervisor
The person responsible for the day-to-day operation of the APMS from the
Control
Centre.
User
The person who pays for the use of a parking bay, typically a member of the
public who
has parked his or her vehicle in the bay.
User Interface
The keypad and display to allow the user to communicate with the APMS.
Transportable Programming/:Retrieval Device (TPRD)
A portable device used by field operatives for maintenance and repair
activities. It may
upload/download data from field devices, perform checks, change equipment
settings
etc.
Variable Rate Period
CA 02346908 2001-04-12
WO 00/23949 PCT/AU99/00891
-39-
The time period during which a vehicle parked in a bay attracts a Variable
Rate parking
fee. The rate may be higher than the Base Rate fee, and may increase over
time. This
reflects the maximum time period the Parking Authority wishes a vehicle to
remain in
the bay, as remaining in the bay for longer than this will be considered a
violation.
Violation, infringement
A violation of the parking regulations as defined by the Parking Authority. In
the
context of the APMS, this is usually when a User is occupying a Parking Bay
and has
not paid the appropriate parking fee, or is over the maximum Period of
Occupancy
defined for that Bay. The dfaermination and collection of fines for violations
are the
responsibility of the Enforcement Authority, and is outside the scope of
operation of the
APMS
