DE102010012565A1 - Method for transmission of data to vehicle key for activating vehicle, involves receiving data of service provider by vehicle key, and charging data of service provider by vehicle into vehicle key - Google Patents

Abstract

The method involves receiving data of a service provider (106) by a vehicle key (103), and charging the data of the service provider by the vehicle (102) into the vehicle key. The service provider comprises a computer or a computer network, which is temporarily connected by radio interfaces (104,105) or with the vehicle. The radio interfaces comprise a Wireless local area networkinterface, a Worldwide interoperability for microwave accessinterface, Radio-frequency identificationinterface, or Bluetoothinterface. An independent claim is also included for a vehicle key comprises a processing unit.

Description

The invention relates to a method for transmitting data to a vehicle key, a vehicle key and a vehicle for activation via such a vehicle key.

An existing vehicle key (including, for example, an electronic radio-enabled access key) has a fixed association with the vehicle for which it provides a locking function. The vehicle key receives this assignment ex works. A change of the assignment does not usually take place.

Depending on the equipment of a vehicle, the vehicle key may provide different functions: opening and closing the vehicle, opening the trunk, comfort access (the vehicle recognizes that the key is nearby, thus allowing access to the vehicle and starting the vehicle).

There are different communication connections between the vehicle key and the vehicle: A unidirectional communication interface at 125 kHz serves to localize the vehicle key and a so-called near-field emergency start function. A bidirectional communication interface in the UHF range (in Europe at 868 MHz) enables authentication of the vehicle key and access control ("opening and closing the vehicle by radio").

Near field communication (NFC) includes a transmission method for the contactless exchange of data over short distances. One known approach to NFC technology relates to a combination of a smart card and a contactless connection technology. It operates in a frequency range of 13.56 MHz and offers a data transfer rate of up to 424 kBit / s with a range of up to 10 centimeters. NFC is through ISO 18092 . ISO 21481 ECMA 340, 352, 356, 362 respectively ETSI TS 102 190 standardized. Communication between NFC-enabled devices can be both active-passive and active-active (peer-to-peer).

Radio Frequency Identification (RFID) applications are also known, comprising an RFID transponder (also referred to as RFID tag) and an RFID reader (also referred to as RFID base station). The RFID transponders can be active as well as passive (see eg http://de.wikipedia.org/wiki/RFID ).

For example, the following applications currently use NFC technology: electronic tickets, non-contact payment systems, access systems and identification systems. These applications are partly regionally specific. In order for the customer to be able to use several of the functions mentioned, he needs various smart cards or RFID transponders.

The object of the invention is to avoid the above-mentioned disadvantages and in particular to provide a flexible solution by means of which a customer can use a large number of different services.

This object is achieved according to the features of the independent claims. Further developments of the invention will become apparent from the dependent claims.

• – bei dem der Fahrzeugschlüssel Daten von einem Dienstanbieter erhält,
• – wobei die Daten von dem Dienstanbieter über das Fahrzeug in den Fahrzeugschlüssel geladen werden.

To achieve the object, a method for transmitting data to a vehicle key is specified,

• In which the vehicle key receives data from a service provider,
• - The data are loaded by the service provider via the vehicle in the vehicle key.

Thus, it is possible to flexibly provide different functions in the vehicle key. The vehicle key can be dynamically loaded with different data. In particular, it is possible to supplement the vehicle key with additional functionalities. This can be application-dependent, user-friendly and / or region-specific.

It is advantageous that the customer the vehicle key z. B. can use as a mobile access medium or that location-dependent different functions for the customer by means of the vehicle key are perceptible. Due to the loadable on the vehicle key data, especially programs, a variety of different applications of the vehicle key can also be used outside the vehicle.

It should be noted that the vehicle key is preferably an access medium to a vehicle. In this case, the vehicle key may be a purely electronic vehicle key or may additionally have a mechanical key.

It should also be noted that here the terms NFC and RFID denote comparable technologies and here instead of the NFC technology, the RFID technology can be used or vice versa.

A further development is that the service provider at least one computer or a Computer network, which is or at least temporarily connected to the vehicle via a first radio interface.

• – eine WLAN-Schnittstelle;
• – eine WIMAX-Schnittstelle;
• – eine Mobilfunk-Schnittstelle.

Another development is that the first radio interface is one of the following radio interfaces:

• A WLAN interface;
• A WIMAX interface;
• - a mobile interface.

In particular, the first radio interface may be a LAN (Local Area Network) interface or a MAN (Metropolitan Area Network) interface.

• – ein Programm oder ein Programmteil;
• – eine auf einem Betriebssystem des Fahrzeugschlüssel ablauffähige Applikation;
• – ein kryptographisches Verfahren;
• – eine Berechtigungsinformation;
• – eine Zugangsinformation;
• – verschlüsselte Daten;
• – ein elektronisches Ticket.

In particular, it is a development that the data include:

• - a program or a program part;
• - An executable on an operating system of the vehicle key application;
• A cryptographic method;
• An authorization information;
• - an access information;
• - encrypted data;
• - an electronic ticket.

The program or program part may be a (sub) program executable on an operating system of the vehicle key. In particular, the program can be loaded onto the key and, if necessary, provide the customer with a specific application (eg ticket purchase, room key for hotel) with additional or additional data (already) loaded with the program. The existing communication infrastructure (radio interfaces) of the vehicle key can be used here.

Cryptographic methods can, for. B. used in conjunction with other applications to ensure protection of (stored on the vehicle key or store) data from attacks. For example, the data may be encrypted and / or the components involved in the communication may be authenticated and / or authorized.

It is also a development that the data is loaded from the vehicle via a second radio interface in the vehicle key.

• – eine NFC-Schnittstelle;
• – eine RFID-Schnittstelle;
• – eine Bluetooth-Schnittstelle;
• – eine WLAN-Schnittstelle;
• – eine UHF-Schnittstelle.

Furthermore, it is a development that the second radio interface is one of the following interfaces:

• An NFC interface;
• An RFID interface;
• - a Bluetooth interface;
• A WLAN interface;
• - a UHF interface.

In the context of an additional development, the vehicle key to an active or a passive NFC or RFID transponder, wherein the data by means of the NFC or RFID transponder are at least partially transferable to a control device.

The control device may be an RFID base station that can activate the RFID transponder. Also, the controller may be a communication station based on one of the second radio interfaces. Data can be transferred between the control device and the vehicle key. For example, the control device can authenticate itself to the vehicle key, then an application can be started which causes the transmission of a pre-stored electronic ticket to the control device.

A next development is that the service provider is a vehicle manufacturer or a central service provider.

In particular, the service provider may assume an intermediary role between the vehicle and a plurality of possible service providers, which may be accessible via the Internet, for example.

One refinement is that the data is forwarded by another service provider to the service provider and from there via the vehicle to the vehicle key.

An alternative embodiment is that context-based data is loaded into the vehicle key.

Depending on a specific context, eg. For example, when a given event or condition occurs (eg, the vehicle reaches a parking lot), an action (eg, purchase of a parking ticket) is triggered that results in data (eg, the electronic parking ticket). be loaded into the vehicle key. The vehicle key can then z. B. can be used as an RFID transponder to get to an automatic machine access to a locked parking area or to unlock the exit at an automatic teller of the parking area.

It should be noted that a variety of different applications is possible. It is also possible to determine or recognize various events based on the vehicle (eg by means of a navigation system, a state and / or a sensor of the vehicle). With the occurrence of a predetermined event, an application can be started, which - if necessary with the consent of the customer - Performs a predetermined action while data transfers to the vehicle key or updated existing data.

A next refinement is that the transmission of the data to the vehicle key is at least partially (or temporarily) encrypted.

It is also an embodiment that an authentication and / or an authorization is performed before the transmission of the data to the vehicle key / is.

In this case, the individual communication partners vehicle, service provider, vehicle key can (partially) mutually authenticate and / or authorize each other.

A further development consists in that at least part of the data is tunneled into the vehicle key by the service provider via the vehicle.

Preferably, the part of the data that can be used as confidential information or as electronic access information can be transmitted directly end-to-end to the vehicle key. For this purpose, a tunnel is established between the service provider (or another service provider) and the vehicle key via the vehicle, and the (confidential) data is transmitted via the tunnel directly into the vehicle key. For example, an end-to-end encryption of the data takes place correspondingly so that the intermediary communication partners (eg the service provider and / or the vehicle) can not decrypt the data.

The above object is also achieved by means of a vehicle key having a processing unit which is set up such that the steps described here can be carried out.

In particular, the processing unit may comprise a processor unit, a microcontroller, or the like with a memory. In particular, the processing unit can have an operating system platform to which data can be transmitted (eg programs, applets, access data, etc.).

For example, the vehicle key may have a display unit and / or an operating unit. The display unit may comprise a display or at least one light-emitting diode, which provides a predetermined feedback to the customer (for example, upon successful redemption of an electronic ticket or upon successful transmission of data to the vehicle key). The control unit allows the user to perform predetermined actions on the vehicle key, for. B. to initiate a transfer of data to an RFID base station.

The above object is also achieved by a vehicle for activation via a vehicle key as described herein.

Activation may include opening, closing, transmission of profile information regarding e.g. B. the customer or start the vehicle.

Embodiments of the invention are illustrated and explained below with reference to the drawings.

Show it:

1 an example scenario including a backend, a vehicle, and a vehicle key;

2 a schematic structure of the vehicle key.

The solution presented here makes it possible in particular to extend a vehicle key by additional functions. For this purpose, data of different types, u. a. Programs or software parts are transferred to the vehicle key. For example, the functions can be loaded into a memory or into an NFC and / or RFID part of the vehicle key. The functions can be loaded via a communication connection, eg. B. via a wired or via a wireless connection. Thus, the vehicle key can be connected to the vehicle via an NFC or via a UHF interface, and the data (eg access data, tickets, programs, applets, etc.) can be obtained therefrom. It is also possible that the vehicle key receives the data via a computer providing an NFC interface. For example, the computer may have an NFC device with a corresponding communication interface which is connected to the computer via a USB interface.

For the transmission of the function (eg data, programs) in the vehicle key different transmission methods or protocols can be used. Furthermore, it is possible that the transfer is secured or unsecured. In particular, correspondingly known methods for encryption, authentication and / or authorization can be used.

The function of the vehicle key may be extended or changed by varying depending on particular applications Data is transmitted to the vehicle key. Some scenarios are described below by way of example (these can be used individually or in combination with one another).

Context-based transfer to the vehicle key:

For example, a context-based update of a vehicle key can be triggered by predetermined environmental parameters, the z. B. be provided by the vehicle or a system of the vehicle. Examples of environmental parameters detectable by the vehicle are: a location, a (clock) time, a traffic volume or a traffic situation, a journey, etc.

Thus, it can be recognized by the vehicle as soon as it reaches a parking space. The customer (or driver) is then offered a purchase of an electronic parking ticket. The customer accepts the offer that the electronic parking ticket is purchased via a backend system (eg at least one computer of a network with which the vehicle establishes a communication link), transmitted to the vehicle and stored by the vehicle on the vehicle key. For this purpose, preferably wireless communication links are used.

In another example, the vehicle's navigation system detects entering a Park & Ride car park. The customer is z. B. offered by an application of the vehicle to select an electronic train ticket from the current station to any destination or frequently chosen by him goals. The customer can choose the destination and request the electronic train ticket. This is transmitted from the backend system to the vehicle and further to the vehicle key. It is also an advantage here that the customer does not have to laboriously work on a search for the right ticket through a widely varying tariff system. The solved electronic train ticket can z. B. be read and verified contactlessly from the vehicle key when accessing the platforms or the train.

Manually initiated transfer to the vehicle key:

Also, the customer himself can perform a predetermined action and thus start the process of providing data to the vehicle key.

For example, the customer can book a hotel room while driving. The electronic access key to the hotel room is transmitted via the backend system to the vehicle and from the vehicle to the vehicle key. Upon arrival at the hotel, the customer can open the booked hotel room directly with his vehicle key.

The customer can also book a ticket for public transport or a train ticket. After selecting the start and destination, the ticket or ticket is paid for and transferred to the vehicle via the backend system. The vehicle transmits the information to the vehicle key.

If the vehicle key does not yet have a required software for filing (and using) an electronic access, tickets, etc. and / or a corresponding payment program, then the respective required software or the payment program (eg from the vehicle or from the backend system via the vehicle) to the vehicle key (and possibly installed there).

Depending on the service used or the region, the software required may vary. Through the approach presented here, it is possible that the vehicle key can be used flexibly for different programs. Thus, an update or a change of the software is easy to accomplish by the newer software is loaded on the car key.

Schematic overview of possible components involved:

1 shows an example scenario including a backend 101 , a vehicle 102 and a vehicle key 103 ,

At the backend 101 it may be at least one computer of a service provider or vehicle manufacturer, via a communication interface 104 with the vehicle 102 connected is. The vehicle 102 and the vehicle key 103 are via a communication interface 105 connected with each other. The communication interface 104 may include: a cellular, a WLAN, WIMAX or a Bluetooth interface. The communication interface 105 may include: an active or passive RFID interface, a UHF interface, an NFC interface, a Bluetooth interface, or the like.

The backend 101 can include several computers from different service providers. For example, a backend of the vehicle manufacturer can be provided, by means of which the (radio) connection to the vehicle can be established. Furthermore, several service providers 106 , comprising z. For example, a ticket seller with the backend 101 (eg the vehicle manufacturer), the backend 101 summarize multiple services from multiple service providers and appropriately to the vehicle 102 (or the available vehicles) can provide or offer. Advantageously, such an infrastructure allows a uniform administration concerning a plurality of services for a plurality of vehicles via the backend 101 , The symbolically shown service providers 106 Can connect via wireless or wired interfaces with the backend 101 communicate.

The car key 103 so can from the backend 101 about the vehicle 102 be modified. In this case, data can be written, deleted or changed in the vehicle key. The data may include: programs (so-called applets, ie executable applications), authorization information, access data, ticket or ticket information, etc. Based on a vehicle key 103 loadable program, it is possible that the vehicle key receives additional functionality or an existing functionality changed (possibly also deleted) or adapted. The communication with the vehicle key 103 and / or the storage of (partial) data on the vehicle key 103 can be done using cryptographic mechanisms (eg, encryption, public-key cryptography, authentication, authorization, etc.). In particular, the vehicle key can have a memory area which is protected against manipulation or encrypted data can be stored in the vehicle key.

In addition is in 1 a control device 108 shown using a wireless or via a wired connection (eg, a contact of the vehicle key) data with the vehicle key 103 can exchange. In the control device, it may, for. B. an RFID base station, the RFID or NFC chip of the vehicle key 103 activated and can read previously stored data. Basically, a bidirectional communication between the vehicle key 103 and the control device 108 possible; For example, also data of the vehicle key 103 from the control device 108 be changed or deleted. Furthermore, the control device 108 Data on the vehicle key 103 transfer. This communication 107 between the vehicle key 103 and the control device 108 can be encrypted. For example, before the actual data exchange (redemption of a ticket or a ticket) the vehicle key 103 opposite the control device 108 can be authenticated, then (possibly encrypted) the electronic ticket or the electronic ticket from the vehicle key 103 to the control device 108 be transmitted.

The communication 107 can by inserting the vehicle key in the control unit 108 (or in a reading recording of the recording device 108 ) respectively. Also could be the vehicle key 108 be kept close to an NFC base station. Alternatively, it is possible that an RFID communication takes place by the customer being in the vicinity of a reader or a corresponding base station. This has the advantage that the vehicle key can remain in the bag and still allow access or a ticket is redeemed.

Data (software, programs, partial programs, data for programs, authorization or access information, etc.) can be displayed in different ways on the vehicle key 103 to be provided. For example, if a parking ticket is to be solved, this can be done by the backend 101 in the customer order (eg the vehicle key has 103 and / or the vehicle 102 previously authenticated to the backend and the customer - eg. By a user input - a transaction agreed) and an electronic ticket from the service provider (e.g., one of the ones in the block 106 shown service providers) are loaded. So the purchased and downloaded ticket from the backend 101 about the vehicle 102 on the vehicle key 103 be transmitted.

It is also possible that, due to predetermined security requirements, an end-to-end connection between the ticket vendor (ie one of the service providers shown 106 ) and the vehicle key is required. This can be achieved by using a corresponding application on the vehicle key 103 expires and the end-to-end connection through the backend 101 (and the vehicle 102 ) is tunneled. Preferably, the backend remains 101 however involved in the transactions, only the electronic ticket is transmitted by the service provider (through the established tunnel) directly to the vehicle key 103 ,

Advantageously, the backend acts 101 as an intermediary for the transactions between the vehicle key 103 and the service providers 106 , Will the backend 101 For example, operated by the vehicle manufacturer, he can offer the customer in addition to existing services and the extended functionality of the vehicle key and support the customer in the administration. For example, the vehicle manufacturer can at any time provide the customer with an overview of the transactions carried out and possibly also the status of the individual transaction or related access data.

The described function of the backend 101 as a mediator can alternatively (or additionally) of the vehicle 102 be perceived.

It should be noted that instead of the vehicle manufacturer mentioned here, another service provider can provide or offer a mediating function.

Through the mediating function of the backend 101 (or the vehicle 102 ) it is possible to lock all data or transactions concerned if a car key should be lost or blocked. For example, all potentially installed on the vehicle key applications can be switched inactive or disabled at once. Likewise, the function of the vehicle key for shooting or locking the vehicle can be deactivated.

2 shows a schematic structure of the vehicle key 103 ,

So includes the vehicle key 103 for example, several radio interfaces 201 , z. For example, at least one UHF interface, NFC interface, RFID interface, low-frequency interface (eg for locating the vehicle key inside or outside the vehicle to realize the comfort access or starting the vehicle without the vehicle key taken out of his pocket would have to be, eg for the realization of an emergency start function of the vehicle). The car key 103 has a closing application 206 on, the appropriate radio interfaces 201 uses to open, close and possibly start the vehicle. The closing application 206 can via controls 204 (eg buttons or switches). Furthermore, an ad 205 be provided by the closing application 206 is controlled accordingly and thus provides the customer feedback on an attempted or performed closing operation.

Furthermore, vehicle data 207 be stored on the vehicle key; this vehicle data 207 be via the radio interface 201 received by the vehicle and updated accordingly. An example is a mileage of the vehicle. Also, the vehicle data 207 be displayed on the display.

Furthermore, the vehicle key comprises an operating system platform (OS platform) 202 , z. JCOP (Java Card Operating Platform) to which executable applications can be loaded. The operating system platform 202 has access to a memory 203 in which data (software, access data, etc.) can be stored. The operating system platform 202 receives over the radio interfaces 201 the required programs and / or data and manages them using the memory 203 corresponding. Optionally, at least one control element 204 of the key as input to the operating system platform 202 serve and / or there may be an issue on the ad 205 respectively.

Also, the vehicle key 103 an energy store (eg, a battery or an accumulator) (not in 1 shown). In this respect, the vehicle key 103 be used as active or passive (RFID) transponder.

Other advantages:

The approach described here allows for flexible handling of the vehicle key beyond the mere use in the vehicle. In particular, it becomes possible to dynamically supplement the vehicle key with additional functionalities. This can be application-dependent, user-friendly and / or region-specific.

The function of the vehicle key can be supplemented or changed via the radio interface. In this case, data (programs, access data, etc.) can be loaded into the vehicle key, modified or deleted there. The applications on the vehicle key can thus be adapted to regional conditions or to a regional infrastructure (also to a corresponding (regional) customer requirement). The customer thus has the opportunity to use the NFC scenarios that are suitable for him or her in his region.

Another advantage is that the locking functionality of the vehicle key can be extended in different ways, without the hardware of the vehicle key must be changed. The applications or data of the vehicle key can be added dynamically. The applications can be processed serially or several applications can be used on the vehicle key (almost or completely) simultaneously.

Also, operation and handling of the vehicle key or the additional functionalities for the customer are easy and comfortable. So the customer can directly and z. B. contextually dependent from the vehicle required data or access information (including programs for using the data) load. For example, the vehicle or the backend can offer the customer an overview of the (loaded) functions of the vehicle key. The customer can z. B. manage these functions centrally (eg delete, lock, activate, update, move, etc.). Also can in case of loss of the vehicle key these functions central, z. B. via the backend, are blocked.

The customer always has an overview of the status of his functions on the vehicle key. This can be z. B. realized via a portal or an application in the vehicle. For example, a central display unit in the vehicle can have a menu item "functions vehicle key", via which these functions can be viewed and managed by the customer. In particular, under individual applications (eg parking ticket (s)), a list of the processes carried out (for example, dissolved tickets: date, time duration, price, debiting via credit card xy) can be stored and offered for retrieval. Optionally, the customer can also send out a list or a part of the list as an email or port it via a removable memory (eg a connectable USB memory). Thus, the customer has at all times an overview of performed operations and / or a period of validity of time-bound or tied tickets (remaining duration of an annual ticket, number of free rides through a car wash, if, for example, a ticket "washing 10 times" was solved in advance).

The presented solution can be used for any type of functions, which can be loaded, in particular, contextually and / or on an operating environment of the vehicle key. If required, the vehicle key can be extended to include functions relevant to the customer.

Dealing with the vehicle key is easy and straightforward for the customer. The customer can use a variety of services, regardless of his wallet or mobile phone only by means of the vehicle key.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited non-patent literature

• ISO 18092 [0005]
• ISO 21481 [0005]
• ETSI TS 102 190 [0005]
• http://en.wikipedia.org/wiki/RFID [0006]

Claims (15)

Method for transmitting data to a vehicle key, In which the vehicle key receives data from a service provider, - The data are loaded by the service provider via the vehicle in the vehicle key. The method of claim 1, wherein the service provider comprises at least one computer or a computer network, which is or at least temporarily connected to the vehicle via a first radio interface. Method according to Claim 2, in which the first radio interface is one of the following radio interfaces: A WLAN interface; A WIMAX interface; - a mobile interface. The method of any one of the preceding claims, wherein the data comprises: - a program or a program part; - An executable on an operating system of the vehicle key application; A cryptographic method; An authorization information; - an access information; - encrypted data; - an electronic ticket. Method according to one of the preceding claims, in which the data are loaded from the vehicle via a second radio interface into the vehicle key. Method according to Claim 5, in which the second radio interface is one of the following interfaces: An NFC interface; An RFID interface; - a Bluetooth interface; A WLAN interface; - a UHF interface. Method according to one of the preceding claims, wherein the vehicle key has an active or a passive NFC transponder, wherein the data by means of the NFC transponder are at least partially transferable to a control device. Method according to one of the preceding claims, in which the service provider is a vehicle manufacturer or a central service provider. Method according to one of the preceding claims, in which the data are forwarded by another service provider to the service provider and from there via the vehicle to the vehicle key. Method according to one of the preceding claims, in which context-based data are loaded into the vehicle key. Method according to one of the preceding claims, wherein the transmission of the data to the vehicle key is at least partially encrypted. Method according to one of the preceding claims, wherein an authentication and / or an authorization is carried out before the transmission of the data to the vehicle key. Method according to one of the preceding claims, in which at least part of the data is tunneled into the vehicle key by the service provider via the vehicle. A vehicle key comprising a processing unit arranged to perform the steps of any one of the preceding claims. Vehicle for activation via a vehicle key according to claim 14.

Images