METHOD FOR SECURELY AUTHORISING VEHICLE OWNERS FOR AN ON-BOARD TELEMATICS FUNCTION IN VEHICLES WITHOUT AN ON-BOARD SCREEN

Abstract

System comprising: a processor configured to: - receive remote vehicle identification information and a vehicle variable value to be confirmed by a user from a remote vehicle data processing system; - receive user input of vehicle identification information and a vehicle variable value to be confirmed by the user, entered in conjunction with a remote access request for a remote operation;- Comparing the vehicle variable value entered by the user with the vehicle variable value received remotely and - providing access to the remote operation if there is a match between the vehicle variable value entered by the user and the vehicle variable value received remotely, wherein the vehicle variable value to be confirmed by the user can be used to verify that a vehicle has actually been physically accessed, and wherein the vehicle variable value to be confirmed by the user includes a tachograph value, or a current fuel level, or a current radio station setting.

Description

[0001] The illustrative embodiments generally relate to a method and a device for remote vehicle verification.

[0002] Vehicle data processing systems that provide support for remote systems via wireless communication, sometimes located away from the vehicle's environment, present challenges in ensuring these systems are not hacked. Since a hacked vehicle can pose a significant security risk, manufacturers are incentivized to find methods to prevent unauthorized remote access to vehicle systems.

[0003] A current challenge is that customers may be required to identify themselves and enter a VIN into a website or mobile application to access a vehicle's system. The cloud can then send a message to the vehicle, which will then display a confirmation message. A driver can then grant or deny access. Vehicles without screens, or without screens equipped to display this information, may have difficulty implementing this procedure.

[0004] US Application No. 2012 / 0262283 generally relates to a system and method for providing tachograph verification for a vehicle. The method performed by the system includes the following steps: (a) receiving authorization from a customer to periodically store tachograph information received from the customer's vehicle; (b) configuring at least one processing device to automatically store tachograph readings and associated correlation parameter values ​​for the vehicle; (c) receiving a request for tachograph verification; (d) analyzing the tachograph readings and associated correlation parameter values ​​in response to the request; (e) determining a verification result based on the analysis; and (f) sending the verification result to a recipient in response to the determination.

[0005] In a first illustrative embodiment, a system includes a processor configured to receive remote vehicle identification information and a user-confirmed vehicle variable value from a remote vehicle data processing system. The processor is also configured to receive user input of vehicle identification information and a user-confirmed variable value, entered in conjunction with a remote access request for a remote operation. Furthermore, the processor is configured to compare the user-input variable value with the variable value received remotely. The processor is additionally configured to grant access to the remote operation if the user-input variable value and the variable value received remotely match.

[0006] In a second illustrative embodiment, a computer-implemented method includes receiving remote vehicle identification information and a user-confirmed vehicle variable value from a remote vehicle data processing system. The method also includes receiving user input of vehicle identification information and a user-confirmed variable value, which is entered in conjunction with a remote access request for a remote operation. Furthermore, the method includes comparing the user-inputted variable value with the variable value received remotely. The method additionally includes granting access to the remote operation if there is a match between the user-inputted variable value and the variable value received remotely.

[0007] In a third illustrative embodiment, a computer-readable storage medium stores instructions which, when executed by a processor, cause the processor to perform a procedure that includes receiving remote vehicle identification information and a user-confirmed vehicle variable value from a remote vehicle data processing system. The illustrative procedure also includes receiving user input of vehicle identification information and a user-confirmed variable value, which is entered in conjunction with a remote access request for a remote operation.The procedure further includes comparing the variable value entered by the user with the variable value received remotely and providing access to the remote operation if there is a match between the variable value entered by the user and the variable value received remotely.

[0008] Fig. Figure 1 shows an illustrative vehicle data processing system;

[0009] Fig. Figure 2 shows an illustrative example of a device or application approval process;

[0010] Fig. Figure 3A shows an illustrative example of a user input process and

[0011] Fig. Figure 3B shows an illustrative example of a vehicle verification process.

[0012] Detailed embodiments of the present invention are disclosed herein where necessary; however, it is understood that the disclosed embodiments are merely exemplary of the invention, which can be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of certain components. Consequently, specific structural and functional details disclosed herein should not be considered limiting, but merely as a representative basis for teaching a person skilled in the art the various uses of the present invention.

[0013] Detailed embodiments of the present invention are disclosed herein where necessary; however, it is understood that the disclosed embodiments are merely exemplary of the invention, which can be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of certain components. Consequently, specific structural and functional details disclosed herein should not be considered limiting, but merely as a representative basis for teaching a person skilled in the art the various uses of the present invention.

[0014] Fig. Figure 1 represents an exemplary block topology for a vehicle-based computing system (VCS). 1 for a vehicle 31This is an example of such a vehicle-based data processing system. 1 This is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based data processing system can have a visual front-end interface. 4 The interface includes the device located within the vehicle. The user may also be able to interact with the interface if, for example, it is equipped with a touchscreen. In another illustrative embodiment, interaction occurs through button presses, acoustic speech, and speech synthesis.

[0015] In the Fig. In the illustrative embodiment shown in 1, a processor controls the device. 3at least part of the operation of the vehicle-based data processing system. The processor provided in the vehicle enables the onboard processing of instructions and routines. Furthermore, the processor is equipped with both non-permanent memory and... 5 as well as a permanent storage device 7 connected. In this illustrative embodiment, the non-permanent storage is random access memory (RAM) and the permanent storage is a hard disk drive (HDD) or flash memory.

[0016] The processor is also equipped with a number of different inputs that allow the user to establish a connection to the processor. In this illustrative embodiment, a microphone is included. 29 , an auxiliary entrance 25 (for an entrance) 33 ), a USB input (USB = Universal Serial Bus) 23, a GPS input (GPS = Global Positioning System) 24 and a BLUETOOTH input 15 All provided. An input selector. 51 It is also designed to allow a user to switch between different inputs. Input to both the microphone and the auxiliary input is processed by a converter. 27 The signal is converted from analog to digital before being sent to the processor. Although not shown, numerous vehicle components and auxiliary components can communicate with the VCS using a vehicle network (such as – but not limited to – a Controller Area Network bus (CAN bus)) to send data to and from the VCS (or components thereof).

[0017] Outputs to the system can include an optical display. 4 and a speaker 13 or include a stereo system output, but are not limited to that. The speaker is equipped with an amplifier.11 connected and receives its signal from the processor 3 through a digital-to-analog converter 9 Output can also be sent to a remote BLUETOOTH device, such as a personal navigation device (PNG). 54 , or a USB device, such as a car navigation system 60 , along the bidirectional data streams that occur at 19 or 21 as shown, will take place.

[0018] In an illustrative embodiment, the system uses 1 the BLUETOOTH transceiver 15 , in order to use a nomadic device 53 to communicate with the user (e.g., mobile phone, smartphone, personal digital assistant (PDA), or any other device with wireless remote network connectivity). 17 The nomadic device can then be used to connect to a network. 61 outside the vehicle 31 for example through communication 55with a mobile phone mast 57 to communicate 59 In some embodiments, the mast can 57 be a WiFi access point.

[0019] An example of communication between the nomadic device and the BLUETOOTH transceiver is shown by a signal. 14 depicted.

[0020] Pairing a nomadic device 53 and the BLUETOOTH transceiver 15 can be done by pressing a button 52 or a similar input. Accordingly, the central processing unit (CPU) is instructed to pair the onboard Bluetooth transceiver with a Bluetooth transceiver in a mobile device.

[0021] Data can be transferred between the CPU 3 and the network 61 using, for example, a data plan, data-over-voice or DTMF tones (DTMF = dual-tone multi-frequency), which are compatible with the nomadic device 53related information will be transmitted. Alternatively, it may be desirable to use an onboard modem. 63 with an antenna 18 to integrate data between the CPU 3 and the network 61 to transmit via the voice line 16 The nomadic device 53 can then be used to connect a network 61 outside the vehicle 31 for example through communication 55 with a mobile phone mast 57 to communicate 59 In some embodiments, the modem can 63 a communication 20 with the mast 57 to communicate with the network 61 manufacture. A modem can serve as a non-restrictive example. 63 a USB mobile modem and the communication 20 It could be mobile communication.

[0022] In an illustrative embodiment, the processor is equipped with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to establish wireless communication with a remote Bluetooth transceiver (such as one found in a mobile device). Bluetooth is a subset of the IEEE 802 PAN protocols (PAN = personal area network). IEEE 802 LAN protocols (LAN = local area network) include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Other communication methods that can be used in this area include free-space optical communication (such as Infrared Data Association (IrDA)) and non-standard consumer IR protocols (IR = infrared).

[0023] In another embodiment, the nomadic device includes 53A modem for voice-band or broadband data communication. In the data-over-voice (D-OV) implementation, a technique known as frequency-division multiplexing (FDM) can be used, allowing the owner of the mobile device to speak while data is being transmitted. At other times, when the owner is not using the device, the data transfer can utilize the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although FDM may be common and still used for analog cellular communication between the vehicle and the internet, it has been largely replaced by hybrid code-domain multiple access (CDMA), time-domain multiple access (TDMA), and space-domain multiple access (SDMA) techniques for digital cellular communication.These are all ITU-IMT-2000 compliant (3G-compliant) standards, and they offer data transmission speeds of up to 2 MB / s for stationary or walking users and 385 KB / s for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G), which offers 100 MB / s for users in a vehicle and 1 GB / s for stationary users.

[0024] If the user has a data plan associated with the nomadic device, it's possible that the data plan allows for broadband transmission, and the system could utilize a much wider bandwidth (thereby speeding up data transmission). In yet another embodiment, the nomadic device 53 replaced by a mobile communication device (not shown) attached to the vehicle 31 is installed. In yet another embodiment, the NG can 53be a wireless LAN device (LAN = local area network) capable of communicating via, for example (and without limitation), an 802.11g network (i.e., WiFi) or a WiMax network.

[0025] In one embodiment, incoming data can be received by the nomadic device via a data-over-voice connection or data plan, through the onboard Bluetooth transceiver, and into the internal processor. 3 the vehicle's data. In the case of certain temporary data, for example, the data can be stored on the HDD or another storage medium. 7 The data will be stored until a time when it is no longer needed.

[0026] Additional sources that can establish a connection with the vehicle include a personal navigation device. 54 with, for example, a USB connection 56 and / or an antenna 58 , a vehicle navigation device 60with a USB connection 62 or another connection, an on-board GPS device 24 or a remote navigation system (not shown) with connectivity to the network 61 USB is one of a class of serial networking protocols. IEEE 1394 (FireWire), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the framework of serial device-to-device standards. Most of these protocols can be implemented for either electrical or optical communication.

[0027] Furthermore, the CPU could communicate with a variety of other auxiliary devices. 65 These devices can be connected wirelessly. 67 or a wired connection 69 be connected. The auxiliary device 65It may include, but is not limited to, personal media players, wireless health devices, portable computers and the like.

[0028] In addition, or alternatively, the CPU could be connected to a vehicle-based wireless router. 73 using, for example, a WiFi transceiver 71 to be connected. This could allow the CPU to connect to remote networks within range of the local router. 73 to connect.

[0029] In addition to exemplary operations performed by a vehicle data processing system located in a vehicle, in certain embodiments the exemplary operations may be performed by a data processing system in communication with a vehicle data processing system. Such a system may include, but is not limited to, a wireless device (e.g., and without limitation, a mobile phone) or a remote data processing system (e.g., and without limitation, a server) connected by the wireless device. Collectively, such systems may be referred to as vehicle-associated computing systems (VACS). In certain embodiments, specific components of the VACS may perform specific parts of an operation, depending on the particular implementation of the system.By way of example, and not as a limitation, if an operation involves a step of sending or receiving information with a paired wireless device, it is likely that the wireless device will not perform the operation, since the wireless device would not "send and receive" information to or from itself. A person skilled in the art will understand when it is inappropriate to apply a particular VACS to a given solution. All solutions consider that at least the vehicle computing system (VCS) located within the vehicle itself is capable of performing the exemplary operations.

[0030] In the illustrative embodiments, a customer can enter a Vehicle Identification Number (VIN) through a mobile application or website in an attempt to access or communicate with the vehicle. The user is then instructed to start the vehicle (if it is not already started). Once started, the vehicle can send location information, tachograph data, or any other appropriate information to the cloud.

[0031] The customer can then enter information that matches the information submitted. This information can include any data a user with vehicle access can obtain (e.g., without limitation, tachograph readings, fuel gauge data, or any other information accessible from a user-serviceable vehicle system). If this information matches the submitted vehicle information, the user will be considered verified as having possession of the vehicle (and will consequently request access accordingly).

[0032] Fig. Figure 2 shows an illustrative example of a device or application approval process. In this illustrative example, there are three elements of the vehicle system, including, but not limited to, a customer (via an application, website, etc.). 201 , the cloud 203(e.g., a remote data processing system in wireless communication with the application / website) and the vehicle) and a telematics device or other vehicle-based data processing system 205 .

[0033] In this example, the customer will first enter a VIN or other unique vehicle identifier. 207 This information can be used to identify vehicle information sent from an online information repository. The remote server receiving the VIN can then request relevant vehicle information (in this case, the tachograph). 209 Additionally or alternatively, the information can be sent automatically every time the vehicle is started and has access to the cloud. 211 .

[0034] To verify that the customer is legitimately requesting vehicle access, the customer will be asked to enter the information. 213, which correspond to the vehicle information sent to the cloud. In this case, the customer is asked to enter vehicle tachograph information, although any vehicle information that can be used to identify a vehicle and to verify that a vehicle has actually been physically accessed can be used.

[0035] If the entered information is correct, the process will be granted to the vehicle. 215 In this case, for example, the customer is granted access for a limited period until a more robust improvement process can be implemented. Feedback in the form of verification, approval, or denial can also be provided to a driver. 217 .

[0036] Fig. Figure 3A shows an illustrative example of a user input process. In this example, the user first accesses an application or other website designed to communicate with a vehicle data processing system. To prevent hacking of the vehicle, some form of identification is required. In this case, the user first enters a VIN. 301 , in order to identify the specific vehicle.

[0037] Since information from the vehicle is required in this example, the process will instruct the user to start the vehicle so that the information can be transferred. 303 If the vehicle is already started or has sent information because the VIN has been entered, the request can be avoided.

[0038] As soon as the vehicle is started and / or the vehicle has attempted to communicate with the server, a message of vehicle communication will be received. 305 Once this information is actually received 307 (which includes identification information sent by the vehicle), the process will receive the tachograph input (input of the fuel level, current radio station or other identification variable) from the user. 309 . This entered information is then compared with the received message information from the vehicle, and a match status is determined. 311 .

[0039] If a match is found, the process will verify the user as a valid user. 319If no match is found, the process will check whether a maximum time limit and / or number of attempts has been exceeded. 313 If the timeout period / number of attempts has been exceeded, the process will lock the user out of the vehicle for a suitable period of time. 315 A notification can also be sent to a customer at this time. 317 , which can be used to warn the customer that an attempt to access the vehicle has failed.

[0040] Fig. Figure 3B shows an illustrative example of a vehicle verification process. In this illustrative example, the vehicle only sends information to a remote server if there is an outstanding request for that information. This occurs when the vehicle is switched on ("key-on"). 321The process checks to determine if a request is outstanding. 323 If there are no pending requests, the process can be wound up until a request is received. 325 .

[0041] Once a request is received, the process will retrieve vehicle position information and any other relevant vehicle system information. 327 Any appropriate information that can be used to associate a user with a vehicle, along with vehicle identification information (such as a VIN), can be sent to the remote server. 329 .

[0042] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are descriptive and not limiting, and it is understood that various modifications can be made without deviating from the meaning and scope of protection of the invention. Furthermore, the features of different implementation forms can be combined to form further embodiments of the invention. QUOTES INCLUDED IN THE DESCRIPTION

[0043] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited non-patent literature

[0044] IEEE-802-PAN-Protocols

[0022] IEEE-802-LAN-Protocols

[0022] IEEE 802 PAN

[0022] IEEE 1394

[0026] IEEE 1284

[0026]

Claims

[1] System comprising the following: a processor configured to do the following: Receiving remote vehicle identification information and a vehicle variable value to be confirmed by a user from a remote vehicle data processing system; Receiving user input of vehicle identification information and a variable value to be confirmed by the user, entered in conjunction with a remote access request for a remote operation; Comparing the variable value entered by the user with the variable value received remotely and providing access to the remote operation if there is a match between the variable value entered by the user and the variable value received remotely. [2] System according to claim 1, wherein the vehicle variable value to be confirmed by the user includes a tachograph value. [3] System according to claim 1, wherein the vehicle variable value to be confirmed by the user includes a current fuel level. [4] System according to claim 1, wherein the vehicle variable value to be confirmed by the user includes a current radio station setting. [5] System according to claim 1, wherein the remote operation involves a website attempting to access the vehicle. [6] System according to claim 1, wherein the remote operation includes a device application attempting to access the vehicle. [7] System according to claim 1, wherein the provided access includes a time sequence.

Images