Patents Form 5NZ. No. 614132NEW ZEALANDPatents Act 1953COMPLETE SPECIFICATIONMETHOD FOR ELECTRONICALLY PROCESSING A TRAFFIC OFFENSE AND ONBOARD—UNIT THEREFORWe, KAPSCH TRAFFICCOM AG, do hereby declare the invention, for which we pray that apatent may be granted to us, and the method by which it is to be performed, to be particularlybed in and by the ing statement:—Method for Electronically Processing a c Offense andOnboard—Unit ThereforThe present invention relates to a method forelectronically ssing ea traffic violation of a. vehicle,which ses an onboard unit having a transceiver, an inputdevice and an output . The invention further relates toan onboard unit for carrying out this method.
Onboard. units (OBUs) are electronic devices carried. byvehicles so as to be able to identify the vehicles in awireless the billing tollsmanner, for example for purpose ofin electronic road toll systems. OBUs can be implemented in theform of active or e radio transponders, radio frequencyidentification (RFID) chips, near field ication (NFC)chips, dedicated short range communication (DSRC) transceiversfor radio or infrared data transmission, wireless access invehicular environments (WAVE) and wireless local area network(WLAN) nodes, or the like. It is the object of the ion torender such OBUs usable for processing traffic violations suchas speed limit violations, parking time violations or the like.
In a first aspect of the invention, this object isachieved by a method for electronically processing a trafficviolation of a vehicle, which comprises an onboard unit havinga transceiver, an input device and an output device,comprising:transmitting a traffic violation message from a beacon tothe transceiver of the onboard unit and outputting the traffic3O violation e on the output device of the onboard unit;accepting a user selection concerning two options via theinput device of the onboard unit;if the user selection indicates the first option,transmitting the traffic violation message from. the onboardunit to a remote central facility;_ 3 _if the user selection indicates the second ,generating a debit transaction related to the traffic violationand charging the debit transaction against a user account.
The invention allows traffic enforcement officials, suchas law enforcement officers, policemen, parking enforcementofficers, parking space managers and the like, to write adetected traffic violation, such as a speed limit or parkingtime violation, directly to the d unit of the violatingvehicle in the form of an electronic traffic violation messageby a . that is implemented. as a handheld device, forexample, using radio or infrared. The vehicle user es theviolation message on the onboard. unit via voice output orgraphic display and can then decline or accept the violationvia the input device. In the first case, the c violatione is forwarded. to a central ty for conventionalviolation processing, for example so as to print and mail apenalty notice to the user, who may then also lodge an appeal.
In the second case, if the user accepts the violation, the usercan immediately pay the fine with the aid of the onboard unitin that the onboard unit generates a corresponding debittransaction and charges it against a user t or at leastinitiates this step.
It shall be noted here that an onboard processing unit isknown from the document US 6,163,277, which, after analyzingdata. received 'via vehicle sensors and. road—side signboards,detects speeding violations of the vehicle and, withappropriate ty of the violation, automatically contactsthe police, who can then read out the violation data from theprocessing unit. The police officer can then establish separate3O voice communication with the vehicle driver and offer to havethe vehicle driver pick up the ticket or to have it .
The user selection made by the user can preferably bemed. by entering a PIN code so as to increase systemsecurity; this can prevent unauthorized persons from confirmingor declining a traffic violation, for example.
It is also favorable if a cryptographic signature of theOBU is transmitted together with the traffic violation message,and in particular if the OBU signs and/or encrypts the trafficviolation message with a cryptographic signature. Authenticateddata can thus be generated for penalty notices, offeringmaximum legal safeguards.
According to a particularly preferred embodiment of theinvention, the user selection can be made in particular by wayof an NFC connection in the input device. For e, a mobiletelephone, hone, PDA, tablet PC or the like having an NFCchip can be used as the input device (and also as the outputdevice), and. the user selection can be made by this deviceapproaching' an. OBU that is integrated. in or mounted. on thevehicle. In this way, for example, the user selection can beset to the second option, this being the confirmation of theviolation and generation of a debit transaction, simply by thedevice ching the unit.
The actual debit against the user account can take placein a wide variety of ways, depending on where the user accountis kept. 5, ing to a first ment of the invention,the user t is kept directly in the onboard. unit, theonboard unit can also directly generate the debit transactionand carry out a corresponding debit against the user account.
If an NFC—compatible input device is used, the user t canalso be kept on a data carrier, which is debited by way of suchan NFC connection. For example, one of the above devices, thesebeing mobile telephone, smartphone or the like, can be used asthe input device, the NFC connection can be established by thedevice ching the remaining OBU part and, for example, a3O payment transaction for the data r can be generated inthis device or sent to the mobile communication network via amobile communication connection and the debit transaction canbe charged t a user account there.
If the user account is kept in the central facility, theonboard unit can, for example, transmit the traffic violationmessage together with the user selection to the centralfacility, so that the debit transaction is charged thereagainst the user account. As an alternative, if the useraccount is kept in the central facility, the onboard unit cantransmit a completed debit transaction to the central facility,which is then applied there to the user account.
An advantageous embodiment of the invention ischaracterized by the preceding step of transmitting a status ofthe onboard unit to the beacon and creating the trafficviolation message in the beacon depending on the receivedstatus. For example, the status of the d unit can relateto an operating mode of the d unit and/or of the vehicle,such as standstill or movement, speed, ing mode,"parking", the readiness to pay a particular parking fee,claiming a particular priority, for example emergency vehicle,multi—occupant status for so—called high ncy vehicle(HOV) lanes, the result of an earlier toll transaction, parkingfee transaction or e inspection or the like. Depending onthe status that is read out from the onboard unit, theinspecting officer can compile the corresponding cviolation message on the beacon or the beacon can te itautomatically, for example based on its own controlmeasurements on the vehicle or the OBU, and can write theion message to the OBU.
The communication between the beacon and onboard unitpreferably takes place according to the dedicated short rangecommunication (DSRC) standard, for example the CEN—DSRCstandards using radio or infrared data transmission, ITS—G5,IEEE 802.11p, wireless local area network (WLAN), wireless3O access in lar environments (WAVE), radio frequencyidentification (RFID), near field communication (NFC), or thelike.
In a second aspect, the invention s an onboard unitfor a vehicle, comprising a eiver, an input device and anoutput device, which is configuredto receive a traffic violation message from a beacon andoutput it on the output device;accept a user selection. concerning’ two options via. theinput device;if the user selection indicates the first option, transmitthe traffic violation message to a remote central facility; orif the user selection indicates the second option, toinitiate the generation of a debit ction for a useraccount related to the traffic ion.
The d unit preferably comprises a stored modifiablestatus and is configured to it the status via theeiver to the beacon in response to a wireless poll. Theonboard unit is particularly preferably configured to keep auser t and charge the debit transaction against the same.
Reference is made to the above comments regarding themethod in terms of the advantages and characteristics of theonboard unit according to the invention.
The invention will be described in greater detailhereafter based on an exemplary embodiment, which is shown inthe accompanying drawings. In the drawings: shows a schematic overview of the communication ofan onboard unit in the tolling mode with tolling beacons ontheir way on a road; shows a schematic overview of the ication ofonboard units in the parking mode with a parking beacon duringparking;is a block diagram and is a front view of anexemplary onboard unit according to the ion;is a state transition diagram of a part of a methodfor generating parking fee transactions that is carried out inan onboard unit; is a flow chart of a part of a method forgenerating parking fee transactions that is carried out in aparking beacon; is a schematic illustration of a road trafficcheck, during the course of which a part of the methodaccording to the invention is carried out; and shows the method of the invention in the form ofthe signal flows between the components ed in the method.
In a vehicle 1 is moving on a road 2 at a speedand in a driving direction 3, and in several vehicles 1are parked in each case in a parking space 4 of the road 2. Theroad 2 can be any arbitrary traffic or g area, forexample an expressway, a highway or an entire road system in or a shoulder, a large parking space or‘ a parkinggarage in all of these are ered to be covered bythe general concept of "road" 2.
Each of the vehicles 1 is equipped with an onboard unit(OBU) 5, which is able to carry out wireless communication 8with roadside beacons (roadside units, RSUs) 6, 7. The OBUs 5can be te devices or an al part of the vehicleelectronics systemd The communication 8 is short range ordedicated short range communication (DSRC), preferably2O according to the CEN—DSRC standards using radio or infrareddata transmission, ITS—G5, IEEE 802.11p, WAVE, WLAN, RFID, NFCor the like. The beacons 6, 7 thus have a respective locallydelimited radio or infrared coverage range 9, 10.
FIGS. 1 and 2 show two different types of beacons 6, 7 andapplication scenarios of the described components. The beacons6 of are ng" beacons ng roadside units, T—RSUs) that are set up in a geographically distributed manneralong the road 2. With the aid of periodically broadcast polls11, the tolling beacons 6 request all passing OBUs 5 to3O ish communication 8, as is illustrated based on theexemplary response 12. So as not to "miss" any g OBU 5due to the potentially high speed of the vehicle 1, the pollsll of the tolling beacons 6 are broadcast at relatively shortintervals, for example every 100 ms or less. For the polls ll,for example, led wave service announcement (WSA) messagesare used in the WAVE standard, and so—called beacon servicetable (BST) messages are used in the CEN—DSRC standard.
Successful ication 8 with a passing OBU 5demonstrates that the OBU 5 is located in the locally delimitedcoverage range 9 of the tolling beacon 6, whereby a fee("toll") can be charged. for usage of the location of thetolling beacon 6. For example, the tolled location usage can bethe driving (n1 a road section, the entering of aa particularterritory ("city toll") or the like.
In contrast, ng" beacons (parking roadside units, P—RSUS) 7 are employed in the g scenario of whichuse a poll 11, for example a WSA or BST message, to request allthe OBUs 5 located in the coverage range 10 to e responsemessages 12 so as to charge a fee for the usage of the parkingspaces 4, as will be described in greater detail hereafter. Tothis end, a parking beacon 7 may be in charge of one or moreparking spaces 4, which together form a parking area P.
Because parked vehicles 1 are stopped, a parking beacon 7can broadcast its polls 11 at considerably longer timeintervals AT than the tolling beacon 6 of for exampleevery 10 minutes, which also defines the time resolution of theparking time billing.
The coverage range 10 of the parking beacon 7 can beadapted to the spatial expansion of the parking spaces 4 usingoptional measures, for example directional antennas, so as toavoid responses 12 of OBUs 5 of es 1 that are not parked,for example passing vehicles. As an alternative or in on,the OBUs 5 of the vehicles 1 can also be caused. to assumedifferent operating modes, which are d in each case to3O the scenarios of FIGS. 1 and 2, and more particularly a firsttoll ing" mode ng‘ mode, TM) for responses 12 topolls 11 from tolling beacons 6, and a second parking operatingmode (parking' mode, PM) for responses 12 to polls 11 fromparking beacons 7. In the polls 11, the beacons 6, 7 canoptionally broadcast a respective beacon identifier, which_ g _indicates whether it is a tolling beacon 6 or a parking beacon7. The beacon identifier can, for example, be indicated as aservice of the beacon as part of a WSA or BST message.
Of course, the tolling beacons 6 and parking beacons 7 canalso be implemented by one and the same physical unit, whichalternately or simultaneously performs the functions of atolling beacon and a g beacon 6, 7. Such a combined unit6, 7 can thus ast polls 11 with the beacon identifier ofa g beacon, for example continually at short intervals,and polls ll with the beacon identifier of a parking beacon 7at longer intervals AT, which is to say onally"interspersed". Such a beacon 6, 7 is then in charge of bothcharging a toll for a road section of the road 2 and charging afee for a parking area P, for e.
Depending on the operating mode TM or PM of the OBU 5, anddepending on the received beacon identifier, the OBU 5 can, forexample, respond only to tolling beacons 6 if the OBU is in thetolling mode TM or only to g beacons 7 if the OBU is inthe parking mode PM.
The operating mode of an OBU 5 can further be encoded as adata themessage (status) st and transmitted as part ofresponse 12. A. beacon 6, 7 can appropriately evaluate thestatus st received in a response 12, so that tolling beacons 6only charge tolls for the passage of OBUs 5 where status st =TM, and parking beacons 7 only Charge fees for the parking ofthose OBUs 5 where status st = PM. Moreover, the OBUs 5 canalso measure their own respective positions p and. transmitthese to the parking' beacons 7, which. compare the receivedpositions p to the respective parking areas P and only charge3O fees for the g of those OBUs 5, the ons p of whichare within the respective parking area P. This will bedescribed in more detail hereafter with reference to FIGS. 3 to shows an ary block diagram, shows anexemplary outside view, and shows an exemplary state_ 10 _transition diagram of an OBU 5, which can be switched between(at least) two operating modes TM and PM in accordance with theation scenarios of FIGS. 1 and 2. According to tothis end an OBU’ 5 comprises a transceiver 13 (for exampleaccording to one 0: said DSRC standards) for carrying out theication 8, a microprocessor 14 controlling thetransceiver 13, a memory 15, an input device 16, and an outputdevice 17. The input and output devices 16, 17 can also beimplemented in a manner that differs from the shown keyboardand. monitor output, for example by way of voice input andoutput, sensor systems, advisory tones and the like. The inputand. output s 16, 17 can also be formed. by’ physicallyte components such. as car radios, navigation devices,smartphones, PDAs, tablets and the like and can be connected tothe microprocessor 14 by wire or ssly, for example by wayof NFC, Bluetooth®, WLAN or infrared.
The OBU 5 can optionally also comprise a nt sensor18, for example in the form of a satellite navigation receiverfor a global navigation satellite system (GNSS), such as GPS,GLONASS, GALILEO and the like; instead of a GNSS receiver, itis also possible to use any other type of movement sensor 18,for example an a sensor (inertial measurement unit, IMU)or a sensor that is connected to components of the vehicle 1,for example a connection to the speedometer or engine of thee 1.
In the st case, the movement sensor 18 can also beonly a connection to the vehicle electronics system, forexample the ignition lock of the vehicle, so that the positionof the key (engine running — not running), for example,3O indicates the (anticipated) movement or parking status of thevehicle.
The OBU 5 can optionally also be equipped with a positiondetermination device 18', which is able to ine thecurrent position p of the OBU 5 — in response to a poll,periodically or continuously. The position determination device_ 11 _18' can operate in any manner that is known in the art, forexample by way of radio triangulation in a k 0;geographically distributed radio stations, which can be formeddirectly by the beacons 6, 7 or by base stations of a mobilecommunication network, for example, or by way of evaluation ofthe cell identifiers of a cellular mobile communicationnetwork, and the like. The position ination device 18' ispreferably a satellite navigation receiver for positiondetermination in a GNSS and in particular can also be formed bythe same GNSS receiver that is used for the movement sensor 18.
In addition. to the riate application. and controland data, the memory 15 of the OBU 5 includesprograms a uniqueidentifier id of the OBU 5, which is established and saved, forexample, during the output or user—specific lization ofthe OBU 5 and which ly identifies the OBU 5 and/or theuser thereof and/or the vehicle 1 and/or a settlement accountof the user. The OBU identifier id is transmitted together with12 from the OBU 5 to a beacon 6, 7every se message so asto uniquely identify the OBU 5 with respect to the beacon 6, 7.
The memory 15 can further include the status st, whichindicates the operating mode TM or PM of the OBU 5 for thecorresponding scenario of or 2. The status st can bemodified. or adjusted. both. depending' on a Inovement (or non—movement) of the OBU 5 measured by the movement sensor 18 or bya user selection via the input device 16. For this purpose, theinput device 16 may, for example, comprise a lockable button16' (, which is labeled "PM" for "parking mode" PM andswitches the OBU 5 to the parking' mode PM. by pressing‘ andg and set the status st to the value "PM". The OBU 5 is3O reset to the tolling mode TM and the status st is set to thevalue "TM" by releasing or unlocking the button 16'. The outputdevice 17 can optionally output appropriate advisory and/orconfirmation messages. shows several of the possible operating states ofthe OBU 5 again in detail in the form of a state transition_ 12 _diagram. The OBU 5 can be switched from the tolling mode TMinto the parking mode PM by pressing the button 16' and/or ifthe movement sensor 18 ines no movement of the OBU 5 overa minimum time period for 5 s, for example. The OBU canbe set from the parking mode PM back to the tolling mode TM byreleasing the button 16' and/or by a Hmvement of the OBU 5detected by the movement sensor 18.
In the parking mode PM, the OBU 5 can temporarily assume apower—saving' sleep mode ("sleep"), and. more particularly assoon as it has received a poll 11 from a parking beacon 7 andsent a response 12. The OBU 5 can also wake up from the sleepmode after a predetermined time period At has lapsed and returnto the parking' mode PM. The time period At is preferablyshorter than the time period At n consecutive wirelesspolls 11 of a g beacon 7. As an alternative or inaddition, the OBU 5 could also be awakened again by receiving asubsequent wireless poll 11. shows the method for generating parking feetransactions in the application scenario of that isbeing carried out in a parking beacon 7 in cooperation with theOBU 5 of FIGS. 3 to 5.
In a first step 19, a poll 11 is broadcast by the parkingbeacon 7 so as to request the OBUs 5 located in the coveragerange 10 to provide responses 12. In step 20, the responses 12ng from the OBUs 5 are received, n each response 12includes at least the respective identifier idi of the OBU 5with. the index i. and ‘-—— ally the status sti fand/or the position pi thereof determined by the positiondetermination device 18'. The received identifiers idh3O statuses sti and positions pi are temporarily stored in theparking beacon 7 as a current dataset setmmr.
Thereafter, a check is carried out within a loop 21covering all received identifiers idi as to whether or not therespective status sti is set to the parking' mode "PM", seedecision 22. In addition (or as an alternative), it can be_ 13 _checked in the decision 22 whether or not the tiveposition pi -— provided this was transmitted falls within apredetermined geographical region, more particularly theparking area P of the g beacon 7. If only some of theconditions that are checked in decision 22 are met (branch "n"of 22), the subsequent steps 23 and 24 are d and the loop21 is continued, or exited for step 25 upon completion. Incontrast, if all the conditions are met, which is to say in thepresent case: sti = PM and pi e P (branch "y" of 22), it ischecked in a further decision 23 whether the respectiveidentifier idi corresponds to a previously stored "old"identifier idLlwt/ which is to say whether or not it occurs ina dataset setlfit{idLlfit} of old identifiers idLlflt. These "old"identifiers idLlfit were determined during an earlier executionof the Hethod and stored in the dataset setmm” as will bedescribed hereafter.
If the respective current identifier idi does not agreewith any old identifier idLlfit, which is to say does not occurin the t setlmm (branch "n" of 23), the loop 21 iscontinued or exited for step 25 after it is completed; if thereis agreement (branch "y" of 23), the method branches to step24, in which a parking fee transaction ta(idi) is generated forthe current identifier idi, as will described in r detaillater.
After step 24, the loop 21 is continued or, aftercompletion thereof, a transition is made to step 25.
In step 25, the current identifiers idi ined in stepare resaved as "old" identifiers idlem, which is to say thet dataset setcurr is (now) stored. as an "old" dataset3O setiast -Thereafter, in step 26, a wait is carried. out for theined. time period. AT, which. is between the individualpolls 11 of the parking' beacon 7, and then the method isrepeated (loop 27)._ 14 _During the next repetition in the loop 27, the uslydetermined current fiers idi now* constitute the "old"identifiers idiJa“, and. if in step 20 again "new" currentidentifiers idi are determined, these can then be compared instep 23 to the "old" identifiers idLlfit from the last datasetsetlfit. As a result, it is Checked during each loop execution27 whether or not an OBU identifier idi determined by a parkingbeacon 7 based on a poll 11 was already present during a poll11 dating' back by the time period. AT; if so, a vehicle 1comprising an OBU 5 having this identifier has sly spentat least the time period AT in the coverage range 10 of theparking beacon 7, so that a corresponding parking feetransaction ta(idi) can be generated for the OBU identifier idifor parking over the time period AT (step 24).
The parking fee ctions ta(idi) generated in step 24can be settled directly by the beacon 7, for example bycharging these to a user account that is kept in the beacon 7.
Alternatively, the parking fee transactions ta(idi) can beforwarded by the beacon 7 to a remote central ty (notshown), which keeps user accounts, toll accounts, bankaccounts, credit accounts and the like under the identifiersidi, so that the parking fee transactions ta(idi) can becharged there against a corresponding ment account.
However, it is also possible for the ted. parking' feetransaction(s) ta(idi) to be returned from the beacon 7 to theOBU 5 with the fier idi and to be charged there against asettlement account (an "electronic ) that is kept in theOBU 5.
Another option is to temporarily store the parking' fee3O transaction(s) ta(idi) returned from the parking beacon 7 tothe OBU 5 in the OBU 5 and, when the OBU 5 returns to thetolling" mode TM, have the OBU 5 send. it/then1 to a tollingbeacon 6 on the way for settlement purposes, as if it were atoll transaction. shows a corresponding operating mode"post ta", which the OBU 5 temporarily assumes after returning_l5_fron1 the parking mode PM and in which it awaits the nexttolling beacon 6 on the way, so as to deliver the parking feetransaction(s) ta(idi) to the same, whereupon. the OBU againreturns to the "normal" tolling mode TM.
The procedures shown in can, of course, beappropriately modified according to programming methods knownto a person skilled in the art. For example, the decision 22could be eliminated or included in step 20, and it could bechcckcd whether the status sti of an identifier idi is set to"PM" and/or the position pi of an identifier idi falls in thearea P, wherein then only those identifiers idi, where statussti = "PM" or position pi E P, are stored as currentidentifiers in the current t setmmr. The loop 21 couldalso be implemented differently and, for example, steps 22 to24 or 23 to 24 could be d out immediately after receiptof a response 12 for an identifier idi if this takes place soquickly in terms of data processing that this can be donebetween consecutively arriving responses 12. It should be notedin this regard. that, according' to some DSRC standards, theresponses 12 of several OBUs 15 replying to one common wirelesspoll 11 are variably spread over time so as to preventcollisions of ses 12, whereby sufficient time can remainbetween dual ses 12 for steps 22 to 24 or 23 to 24.
A g beacon 7, the coverage range 10 of which coversseveral parking spaces 4, at the same time receives a completeoverview of the occupancy status of the parking spaces 4 in itsparking area P as a result of the responses 12 of the OBUs 5 instep 20. For this purpose, the beacon only needs to compare thenumber of identifiers idi received in step 20 to the number of3O parking spaces 4 in the area P, so as to obtain a proportionalor percentage—based ation rate of the parking spaces 4,for example "80%" if 4 out of 5 parking spaces are occupied,and so forth. The parking space occupancy status thusdetermined can be sent to a central facility for parking areamanagement es, for example._ 16 _shows a first part of the method for electronicallyprocessing traffic violations based on a control io, inwhich a control person 31 checks a vehicle 1 comprising the OBUthereof with the aid of a transportable beacon 32, which isimplemented as a handheld device, for example. In the exampleshown, the vehicle 1 is parked. in a parking space 4. Theparking mode PM was set by the user in the OBU 5, which is tosay the status st in the memory 15 of the OBU 5 is accordinglyset to "PM". With the aid of the OBU 5 and one of the bedparking s 7, for example, corresponding parking feections ta are generated, as was described based on FIGS.1 to 6.
The control person 31 now carries out a road traffic checkwith the aid of the beacon 32. In the illustrated example, thisperson checks the correct setting of the parking mode PM in theOBU 5.
As is shown in for this purpose in a first step 33the identifier id and (optionally) the status st of the OBU 5of the checked vehicle 1 are read out into the beacon 32 via a2O communication 8. Optionally, additional data such as thestarting time t1 of a parking process (time at which theparking mode PM is entered), the maximum d parkingduration at this location in the form of a time window or anallowed ending time t2, one or more of the last parking feetransactions taifit processed in the OBU 5, traffic violationes that were previously stored in the OBU 5 or the like,can also be read out.
Depending on the information received in the beacon 32,for example whether the status st in a parking space 4 was setcorrectly to "PM" by the user, a traffic violation message recis compiled in a step 34 based on a visual comparison by thecontrol person 31 — or also in a partially or entirelyautomated fashion directly by the beacon 32, if it hasappropriate sensors. If the beacon 32 carries out step 34mously, instead of being a handheld device, it can also_ l7 _be set up in a stationary manner, for e, or carried by apatrol vehicle. It is also possible for the beacon 32 to beimplemented in the form of one of the beacons 6 or 7 and togenerate traffic violation messages rec, for example in thecase of speed limit violations, g time violations in ashort—term parking zone or pping zones with time limitsand the like.
Thereafter, in a step 35, the traffic violation messagerec is transmitted in a communication 8 to the OBU 5, where themessage is output on the output device 17 to the user of thee 1, for example via voice output or graphic display.
Using’ the input device 16, for example voice input or thekeyboard, the user of the vehicle 1 can now accept ("y"), ornot accept ("n"), the traffic violation for payment and make acorresponding user selection y/n. On a supplementary basis, inthe case of acceptance "y", additionally' a PIN code may’ berequested to be entered so as to further se the paymentsecurity, for example so as to prevent third—party selection inthe case of open convertibles or by vehicle users in rentalcars who are not authorized to access the t.
For example, if the input and output devices l6, 17 areconfigured as a smartphone with an NFC connection, theviolation can be accepted and a payment process can bered simply by the smartphone approaching the processorpart of the OBU 5.
In a step 36 then, the user selection y/n is transmittedvia the eiver l3 — or another transceiver of the OBU 5,for example a mobile communication module or via WAVE/LANaccess of the buted beacons — to a remote central3O facility 37 together with the traffic violation message rec andthe identifier id of the OBU 5. The l facility 37 cantake on any arbitrary form, for example a central facility of aroad toll system, parking fee billing system, a bank computer,a credit card account processor and the like, which isconnected wirelessLy or by wire to one of the beacons 6, 7_ l8 _and/or 32. The central ty 37 can even be directlyimplemented by one of the beacons 6, 7 or 32.
If the user selection y/n related to the declination ofthe indicated traffic violation ("n"), in a step 38 thereaftera "conventional" ticket 39 is created from the trafficviolation message ), for example it is printed out andmailed to the user of the e 1 together a notice of thelegal es that are available.
During the transmission of the user selection y/n in step30, the authenticity of the user can optionally be checked byadditionally transmitting a cryptographic OBU signature that isstored in the OBU 5 and/or the OBU 5 can sign and/or encryptthe user selection y/n and/or the traffic violation messagerec(id) with the OBU signature and/or an OBU key. In this way,ts of the user interaction that hold up in court can begenerated.
If the user selection y/n related to the acceptance of thetraffic violation ("y"), in step 40 a debit transaction ta(id)is generated from the traffic violation message ) andcharged against a user account 41, for example by debiting theuser account 41 with a fine indicated in the traffic ionmessage rec(id). Alternatively or additionally, in step 42 thedebit transaction ta(id) can also be returned to the OBU 5 viaa communication 8 and d there against a user account (an"electronic ") kept directly in the OBU 5. The useraccount 41 could also be kept in a part of the input and outputdevice 16, 17, for example if the same is implemented by amobile terminal such as mobile telephone, smartphone, PDA,tablet PC or the like connected wirelessly, for example via3O NFC, Bluetooth® or the like. In this case, the OBU 5 can beprogrammed so that an appropriate message is sent to thiswirelessly connected part of the input and output device 16, 17for debiting the user account 41 and there, for example, a useraccount 41 in this terminal is debited or the debit transaction_ 19 _ta(id) is forwarded by the , for example to a billingcenter of a mobile communication network.
Alternatively, it is possible for the debit transactionta(id) to be generated directly in the OBU 5 from the cviolation message rec(id) and charged t a user account 41kept in the OBU 5, in which case step 36, this being’ theforwarding of the traffic violation message rec(id), onlybecomes necessary if the traffic violation is declined ("n");or a debit transaction ta (id) that is directly generated inthe OBU 5 is transmitted to the central facility 37 forprocessing in step 36 — instead of the violation messageIf after an extended period, for example one month, theuser has not entered a user selection y/n, the user selectiony/n can be set to a predetermined value directly by the OBU 5and can be r processed accordingly. The user selection isthen ably set to the value "n" so as to not to debit anincorrect account or cause an early expiration of a deadline inthe case of a ticket.
After the user selection y/n has been entered into the OBU, the traffic violation message rec(id) in the OBU 5 isdeleted or marked as processed.
The invention is not limited to the shown embodiments, butencompasses all variants and modifications that are covered bythe scope of the accompanying claims._ 20 _