SYSTEMS FOR COUNTING PASSENGERS

Abstract

A system and method for counting passengers in a road vehicle (10) comprises a vehicle server (160) within the vehicle (10). At the start of a journey, the vehicle server sends (210) local connection data for a local short-range network, e.g. WiFi or Bluetooth, to a public server (101). During the journey, one or more user terminals (112) request (220) and gets (224) the connection data, and can thereby submit (230) a digital passenger ID to the vehicle server (160). The passenger IDs are added to a passenger list (162). At the end of the journey, the vehicle server (160) counts the number of distinct passenger IDs in the, and submits (240) the passenger count to the public server (101). An alternative embodiment comprises an ID-card and USB cable instead of a short-range private network.

Claims

1-15. (canceled)

16. A system for counting passengers in a road vehicle comprising: a public server configured for recording a journey ID and an associated passenger count; a vehicle server within the vehicle; and a machine-readable passenger token for providing a passenger ID unique for each passenger, wherein the public server and the vehicle server are nodes in a public network, and the public server is configured to record the passenger count as the number of distinct passenger IDs that is/are read by the vehicle server over a short-range connection during a journey identified by the journey ID.

17. The system according to claim 16, wherein the journey ID comprises a vehicle ID and an expiration.

18. The system according to claim 16, wherein the vehicle server is a process running in a secure device mounted in the vehicle.

19. The system according to claim 16, wherein the vehicle server is a process running in a driver's mobile terminal.

20. The system according to claim 16, wherein the machine-readable passenger token is a personal card associated with the passenger.

21. The system according to claim 16, wherein the short-range connection is a wireless short-range network.

22. The system according to claim 16, wherein the machine-readable passenger token is a user terminal forming a node in the public network and comprising a private key and a corresponding public key.

23. The system according to claim 22, wherein the user terminal further comprises a digitally signed certificate containing its public key and one passenger ID.

24. A method for counting passengers in a road vehicle, comprising the steps of: creating a data structure journey identified by a unique journey ID and comprising an empty passenger list in a digital storage medium; reading a passenger ID from a machine-readable passenger token; submitting the passenger ID over a short-range connection to a vehicle server within the vehicle; adding a distinct passenger ID to the passenger list; and submitting the journey ID and a number of distinct passenger IDs to a public server over a public network.

25. The method according to claim 24, wherein creating data structure journey includes storing a vehicle ID and local connection data in the public server.

26. The method according to claim 25, wherein reading the passenger ID includes authenticating the passenger.

27. The method according to claim 25, further comprising a step of issuing a receipt for the journey.

28. The method according to claim 25, further comprising a step of requesting an end of journey before an expiration.

29. The method according to claim 25, further comprising the steps of recording the journey ID and passenger count in the public server and deleting private data from the public server and vehicle server.

30. The method according to claim 25, wherein each message transmitted over the public network and/or the short-range connection is encrypted with a sender's private key or a recipient's public key.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The invention will be explained with reference to exemplary embodiments and the accompanying drawings, in which

[0037] FIG. 1 illustrates a system for charging usage fees to a vehicle,

[0038] FIG. 2 illustrates the system and method of the present invention and

[0039] FIG. 3 is a block diagram showing details of the method in FIG. 2.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0040] The drawings are schematic and not to scale. For ease of understanding, numerous details known to a skilled person are omitted from the drawings and the following description.

[0041] FIG. 1 illustrates a system 100 for charging fees disclosed in our co-pending application NO20160003A1. A central system comprises a public server 101 with associated data 102 and predefined processes 103, e.g. for collecting fees. A secure device 110 mounted in a vehicle 10 collects emission data from an emission sensor 120, a mileage from an odometer 121 and positioning data from a GPS-receiver 130. The fee data may be transmitted over a public network 140, e.g. a mobile network, to the public server 101 for computing fees. Alternatively, the secure device 110 may store the data in an internal file system 111 and compute the fees. In this case, no sensitive data such as positions with associated times are sent to the central system 101.

[0042] A user terminal 112, e.g. a smartphone, tablet, PDA and/or a laptop is able to communicate over the public mobile network 140, e.g. with the public server 101. The user terminal 112 is also able to communicate via short range links, e.g. a USB cable or a private and/or personal area network such as WiFi or Bluetooth.

[0043] In a first embodiment of the present invention, each passenger has a unique ID-card identifying the owner. A card reader 150 is connected to the secure device 110, e.g. by a USB-cable. A person may insert a personal card 151 into the reader 150 and enter a PIN to verify that he or she is the owner of the card. The card reader 150 should read a passenger ID unique for the owner. The card and PIN is an example of two-factor authentication suitable for connecting a person to a digital passenger ID. The USB-cable connects the card reader, and thereby the authenticated person, to the vehicle 10. This prevents someone in a remote location from registering as passenger for a journey.

[0044] The unique passenger ID read by the card reader 150 is added to a passenger list for counting passengers as further described below. Some private and public organisations provide machine readable cards, e.g. tickets issued by public transport companies, smart cards for banking applications or secure networking or ID-cards issued by some governments. However, large scale distribution of new smart cards or electronic devices comprising a unique passenger ID for a traffic application is expensive.

[0045] FIG. 2 illustrates an alternative embodiment, in which a passenger's user terminal 112, e.g. a smartphone, tablet, PDA or laptop replaces the ID-card as a factor in authenticating the passenger. The main benefit is that all passengers are likely to carry such a device in a journey from home to work or back. A vehicle server 160 comprises a passenger list 162 and processes running in the vehicle 10, e.g. in a secure device 110 of the system 100 or in a mobile device 112 belonging to a driver of the vehicle 10. A short range network, e.g. WiFi or Bluetooth, provides the short range connection between the user terminal 112 and the vehicle server 160, and thereby associates the user terminal 112 with the vehicle 10 for the journey.

[0046] FIG. 2 also illustrates the main steps in a method 200 for counting passengers. In step 210, the vehicle server 160 creates a journey data structure identified by a vehicle ID and a fixed expiration. The newly created data structure journey comprises an empty passenger list, and is preferably created in the vehicle server 160 to save traffic over the public network 140. The passenger list may have a maximum number of items, e.g. the number of passenger seats in the vehicle.

[0047] In embodiments with a private, local net, the step of creating 210 a data structure may involve sending local connection data for the vehicle server 160, e.g. an SSID and a passphrase for a WiFi network, to the public server 101. In response, the public server 101 stores the local connection data for the vehicle server 160.

[0048] Step 220 is performed for every passenger registering during the journey, and comprises a request for local connection data for the vehicle server 160. The public server 101 returns a message 222 with the requested data, and the user terminal 112 is able to connect directly to vehicle server 160. There is no need for manual input or reconfiguration for WiFi, Bluetooth etc. in the user terminal 112 and/or vehicle server 160. This facilitates use of the present invention for the driver and regular passengers as well as for a random passenger registering for one journey in the vehicle 10.

[0049] In step 230, the passenger's user terminal 112 submits a passenger ID unique to the person possessing the user terminal 112. The vehicle server 160 may respond 234 with a receipt for registering as passenger for the journey. The optional step 234 enables the owner of user terminal 112 to document several journeys in a certain period and/or collect a small amount for motivating people to register as passengers, e.g. in commuter traffic.

[0050] One of the processes 163 in the vehicle server 160 checks for duplicate passenger IDs in a passenger list. For example, a passenger ID associated with the driver of the vehicle 10 should not increase the passenger count. A passenger submitting his or her passenger ID more than once during a journey, possibly from different user terminals 112, should receive a message that he or she is already registered for the journey. Thus, there is no need for fines or other expensive enforcement to prevent fraud, and a function to confirm registration on the user terminal 112 becomes optional.

[0051] In step 240, the vehicle server 160 submits the passenger count to the public server 101. The passenger list containing passenger IDs and other private data are not needed for counting a number of passengers, and are thus deleted from the vehicle server 160.

[0052] In a passenger discount system, the vehicle ID and an expiration time are required to identify a journey, and the passenger count is needed for computing the discount. A public server 101 is required to collect and compute fees and discounts

[0053] A HOT/HOV system may further comprise fixed and/or mobile control points. Each control point may comprise a camera connected to an automatic number-plate recognition (ANPR) system. The camera may be placed near the ground to avoid taking pictures of passengers, and also to focus on the HOT-lane rather than adjacent ordinary lanes. The registration number can later be checked against the passenger count stored in the public server 101. Alternatively, the vehicle server 160 might be required to report the current passenger count in real time. However, the value of real time reporting over comparing e.g. three hours later is limited, unless the passenger count is controlled manually a few hundred meters past the control point. Either way, a public server 101 is required to collect fees or record violators.

[0054] The scheme illustrated in FIG. 2 eliminates the need for entering local connection data manually and/or reconfiguring the vehicle server 160 to accommodate a random passenger. As the public server 101 is required anyway, it is relatively inexpensive to make it provide local connection data.

[0055] The communication over the public network 140 may be conducted on any network layer using any suitable protocol. For example, the driver's request in step 210 might use SMS on a mobile network 140 to send a code word and vehicle ID to a predefined number, e.g. jstart AB12345 to number 9876. Alternatively, the request 210 may connect to a webserver on the application layer, e.g. by an URI such as https://example.com/AB12345, which includes the vehicle ID. The URI may be available from the Favourites folder in a web browser, a QR-code on a console or a sticker in the vehicle 10, etc.

[0056] A dedicated application downloaded from a central store and installed on the user terminal is a practical alternative regardless of protocol and algorithm. Such an application may have options for registering as a driver or a passenger, and use system calls to access data and functions, e.g. the passenger ID or functions for encryption, decryption and hashing. A dedicated application may be signed by the issuer, and thereby cryptographically hard to modify. Proven cryptographic techniques may easily make the cost of reading or altering data or the software orders of magnitude larger than the gain obtainable from reading or altering a passenger count, and thus make eavesdropping or malicious alteration uninteresting or impossible for everyone with the possible exception of state level adversaries.

[0057] Specifically, encryption keeps the content of a message confidential, whereas hashing ensures the integrity of the contents. Digital nonrepudiation includes determining origin of data with reasonable certainty. For example, encryption ensures that an eavesdropper on the network 140 cannot see a passenger's approximate position at a certain time. Hashing ensures that neither software nor the passenger count sent to the public server can be altered without being detection. Thus, the driver cannot be suspected for manipulating the passenger count. Nonrepudiation enables the authority operating the public server 101 to prove that a certain vehicle server 160 sent a certain passenger count, and that the authority could not possibly have altered the passenger count after reception.

[0058] For encryption, hashing and providing nonrepudiation, the public server 101, vehicle server 160 and each user terminal 112 are provided with unique pairs of cryptographic keys. Each key pair comprises a private key and a corresponding public key. A message encrypted with a public key can only be decrypted using the associated private key. The public key cannot decrypt the message, and is available to all communication partners, e.g. as part of a message or on request. Similarly, the public key can decrypt a message encrypted with a private key. Thus, if a message decrypted with a public key is readable, the sender must have access to the private key. The key pair eliminates a need for a central register of secret keys and secure channels, e.g. couriers, to distribute secret keys. The security depends on that the private key remains secret at all times.

[0059] Keys preinstalled in the SIM-card of a mobile device are usually not used for authentication, as there is no way to know if the alleged private keys are actually secret. However, current SIM-cards may comprise useful cryptographic primitives, e.g. secure functions for encryption, decryption, hashing or a combination. These functions run in a protected smart card, and are invoked by some mobile banking applications. The transport layer security (TLS) protocols for Internet applications define suitable algorithms and recommendations for encryption, hashing etc.

[0060] A first implementation may use readymade functions for handshaking, encryption and hashing, e.g. as defined in current TLS protocols. For example, messages may be provided with a digital signature. However, computing a digital signature involves hashing and encryption, and hence requires relatively large computing resources and thereby battery power. Alternatively, a Diffie-Hellman handshaking algorithm may be used to establish a secure channel through a public network. Once established, the secure channel is suitable for exchanging large amounts of data, e.g. by combining hashing and encryption in the Galois/Counter mode (GCM) of the AES block cipher defined in TLS from version 1.2. However, secure channels are not needed for the small amounts of data in the present application. Rather, a minimal connection procedure is preferred to save battery power, e.g. for environmental reasons.

[0061] FIG. 3 is a block diagram illustrating details of a minimal secure embodiment using user terminals 112 with private and public keys. A verifiable, unique passenger ID is required in all embodiments, e.g. in the user terminals 112 and the personal cards 151 described above. A social security number is a good candidate for a passenger ID, because it is preassigned to all citizens and may be verified by a lookup in a central database. If desired, the social security number may be encrypted for use as a passenger ID.

[0062] In FIG. 3, a dashed vertical line represent the public network 140. Steps performed in the vehicle or over local, short-range network associated with the vehicle server 160 are shown to the left of the dashed line 140. Steps performed in the public server 101 are shown to the right of the dashed line 140.

[0063] Step 201 represents steps performed before starting the journey, e.g. installing a application on user terminals 112 and the vehicle server 160. The application may be secure in the sense that it will not run without a valid signature to prove origin and integrity. Step 201 may also include an option to associate a vehicle ID with a driver to facilitate later use, e.g. such that the public server 101 uses the vehicle ID as default if the driver logs in. The vehicle ID may be associated with a mobile number and/or a passenger ID on a secure website using any web browser.

[0064] The passenger ID and secure keys are also initialised in step 201. According to best practice, a user may generate a key pair and submit the public key along with his social security number and name to the traffic authority operating the public server 101. In return, the user gets a signed public key certificate with a passenger ID. The certificate cannot be altered without detection, and thereby associates the public key with a passenger ID corresponding to a user that at least can connect a name and a social security number. The private key does not leave the user terminal during this process. The certificate can be copied to several devices along with the private key, e.g. by using a memory stick, and thereby associate the user with several user terminals. Thus, the passenger may register using a personal smart phone one day and his job phone the next, but neither the passenger nor the driver can increase the passenger count by using several devices with the same passenger ID.

[0065] Block 210 illustrates steps performed in the vehicle server 160 when creating a new journey data structure. Specifically, step 211 defines the journey ID as a vehicle ID and an expiration, and step 212 creates an empty passenger list on the vehicle server 160 as explained previously. Step 213 includes collecting and sending local connection data for the short range network associated with vehicle server 160. The local connection data could be, for example, an SSID and a catchphrase for a WiFi network or a pin for a Bluetooth connection.

[0066] The expiration sets a latest time for registering as passenger for the journey, and for submitting the passenger count to the public server 101. The expiration will not change if the driver manually stops the passenger count, and ensures that the vehicle server 160 submits the passenger count if the driver forgets or ignores to submit the passenger count manually.

[0067] The expiration may be set relative to the start of the journey, e.g. three hours from the driver's request 210 for a new journey. Alternatively, the expiration could be a fixed time of day, e.g. 11:00 on working days for commuter traffic in the morning and 19:00 on working days for commuter traffic in the afternoon. In both examples, the expiration separates morning traffic from evening traffic.

[0068] The vehicle server 160 encrypts the request message with its private key, i.e. Priv160, and sends the encrypted message over the public network 140 to the public server 101. Only the vehicle server 160 knows its private key, so the private key proves the origin of data with one encryption as illustrated by step 216 below. In contrast, using the public server's 101 public key for encryption would require further steps to validate the vehicle server 160 and/or the vehicle ID.

[0069] Block 215 shows steps performed in public server 101. Block 215 may advantageously comprise steps to terminate any previous journey for the vehicle ID in order to prevent a driver or passenger to register in several journeys in one vehicle at any time. This does not exclude a passenger from registering for a new journey before the expiration of the previous journey, because passengers may legitimately ride along with two vehicles within the fixed expiration time associated with the first journey.

[0070] Specifically, step 216 includes decrypting the message using the public key of vehicle server 160. If the decrypted message is readable, the sender must have had access to the corresponding private key for encryption. This establishes the vehicle server 160 as origin of the request, and thereby validates the vehicle ID for the journey.

[0071] In step 218, the public server 101 stores the local connection data provided from block 210. Thereby the local connection data becomes available for user terminals 112 from the public server 101. This eliminates the need to enter local connection data manually and/or to reconfigure devices as explained above.

[0072] Block 220 illustrates that one or more passengers may connect to the vehicle server 160 before expiration. The connection from a user terminal 112 to the server 160 is over a short-range network, so no user terminal 112 outside the range can register a passenger.

[0073] Step 221 illustrates a waiting loop that does nothing until a passenger requests registration for the journey. The passenger request must of course contain data identifying the vehicle server 160 to enable the public server 101 to return the appropriate local connection data. This may be achieved in a practical manner by sending an SMS text message, scanning a QR code etc. as described with reference to the journey request 210. Optionally, the request message may comprise the public key Pub112 of the user terminal 112 for encryption in step 224. For clarity of illustration, the passenger request message is not shown explicitly in FIG. 3.

[0074] The passenger request message is encrypted with the appropriate user terminal's 112 private key. The passenger is not responsible for the passenger count, so nonrepudiation is not required. Thus, the public server's public key Pub101 could equally well be used for encryption. The user terminal's 112 private key Priv112 is used to save a lookup for Pub101. A step of decrypting the message with the corresponding public key Pub112 is required, but not shown for clarity of illustration.

[0075] In step 222, the public server 101 returns a message containing local connection data for connecting to the vehicle server 160 over the short-range network. The message may optionally contain the expiration and/or other information. The expiration enables the user terminal 112 to inform a passenger that he or she is already registered as passenger for the journey without asking the vehicle server 160 for confirmation.

[0076] Step 224 illustrates encryption of the return message from step 222 with the user terminal's 112 public key Pub112. The public key Pub112 may be part of the passenger request message as explained above. Alternatively, the server 101 may request Pub101 from the requesting user terminal 112 using an address implicit in the request, e.g. a mobile phone number in the SMS example or an IP-address in the Internet example.

[0077] In step 225, the user terminal 112 decrypts the return message using its private key Priv112. The local connection data from the decrypted return message enables the user terminal 112 to connect to the vehicle server 160 over the short-range local network. User terminals 112 without access to the appropriate private key Priv112 are unable to decrypt the return message. Any user terminal 112 may connect to the vehicle server 160 by manual input of local connection data, so the public server 101 does not authenticate the user terminal 112.

[0078] In step 230, the user terminal 112 submits a passenger ID to the vehicle server 160. The associated message is encrypted with the public key Pub160 of the vehicle server 160. In step 231, the message containing the passenger ID is decrypted using the corresponding private key Priv160. Apart from hiding the passenger ID from an eavesdropper within range of the local short-range network, the encryption in step 230 forces an adversary to obtain the public key Pub160 and encrypt a message with Pub160. If the message is not properly encrypted, the decryption in step 231 will return garbage. Successful decryption may be determined by testing the passenger ID. For example, the vehicle server 160 may reject a decrypted passenger ID that does not match a predefined pattern of ASCII-characters representing digits and/or characters in a real passenger ID, or does not compare to a passenger ID fetched from a certificate in the user terminal 112. The cost of providing a proper encryption or modifying the software of vehicle server 160 can easily be made to exceed the obtainable benefit as discussed previously.

[0079] Step 232 adds a unique passenger ID to a passenger list. The list may have a maximum length corresponding to the number of seats in the vehicle 10. The appropriate number of seats can, for example, be fetched from a central database and stored during installation of the vehicle server 160. If the passenger ID submitted in step 230 is already present in the list, the submitted passenger ID is not unique in the list, and will not be added. In other words, duplicate passenger IDs will be rejected to ensure that one passenger registers once per journey. Preferably, the vehicle server 160 or user terminal 112 informs a passenger registering for the second or subsequent time that he or she is already a registered passenger for the journey. Thus, a separate confirmation function is not needed in the user interface.

[0080] In an optional step 233, the vehicle server 160 issues a receipt for the journey to the requesting user terminal 112. Such a receipt may be used to provide a benefit to the owner in order to motivate people to register as passengers. Step 234 illustrates encrypting the optional message with the public key Pub112 of the user terminal 112. The user terminal 112 may decrypt the message as in step 231, and store the receipt in optional step 235 for later use.

[0081] The driver may end the journey manually in step 241. Then, the vehicle server 160 immediately counts 242 the passenger IDs in the passenger list, and then deletes 243 private data. If the driver does not end the journey manually, the vehicle server 160 executes step 242 to submit the passenger count at the expiration time. Either way, the vehicle server 160 encrypts the message containing the passenger count with its private key Priv160.

[0082] Block 250 illustrates end of journey, where the public server executes step 252 to record the passenger count for the journey identified by the vehicle ID and expiration. As noted, the expiration is unaffected by a manual request to end the journey in step 241. Step 253 deletes private data, e.g. the local connection data, from the public server 101 as they are no longer needed.

[0083] The process ends in step 260, which includes any subsequent steps required for computing a passenger discount, verifying passenger count after a an automatic control in a HOT lane, etc. from the fees charged during a journey and the passenger count.

[0084] While the invention has been described by way of examples, various alternatives and modifications will be apparent to one skilled in the art. The invention is defined by the accompanying claims.