EP3673466A1 - Verfahren zur vergabe von zugangs- und fahrberechtigungen - Google Patents

Verfahren zur vergabe von zugangs- und fahrberechtigungen

Info

Publication number
EP3673466A1
EP3673466A1 EP18733565.8A EP18733565A EP3673466A1 EP 3673466 A1 EP3673466 A1 EP 3673466A1 EP 18733565 A EP18733565 A EP 18733565A EP 3673466 A1 EP3673466 A1 EP 3673466A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
driving
data
data format
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP18733565.8A
Other languages
English (en)
French (fr)
Inventor
Dirk Hassert
Thomas Hartmann
Christian Rupert
Frank-Peter PESL
Gerd Scheidhauer
Christian Heikamp
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
Daimler AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Daimler AG filed Critical Daimler AG
Publication of EP3673466A1 publication Critical patent/EP3673466A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00Individual registration on entry or exit
    • G07C9/00174Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00309Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/08Interaction between the driver and the control system
    • B60W50/12Limiting control by the driver depending on vehicle state, e.g. interlocking means for the control input for preventing unsafe operation
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60RVEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20Means to switch the anti-theft system on or off
    • B60R25/2018Central base unlocks or authorises unlocking
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60RVEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20Means to switch the anti-theft system on or off
    • B60R25/24Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W40/00Estimation or calculation of non-directly measurable driving parameters for road vehicle drive control systems not related to the control of a particular sub unit, e.g. by using mathematical models
    • B60W40/08Estimation or calculation of non-directly measurable driving parameters for road vehicle drive control systems not related to the control of a particular sub unit, e.g. by using mathematical models related to drivers or passengers
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/08Interaction between the driver and the control system
    • B60W50/10Interpretation of driver requests or demands
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/008Registering or indicating the working of vehicles communicating information to a remotely located station
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00Individual registration on entry or exit
    • G07C9/00174Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00571Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated by interacting with a central unit
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00Individual registration on entry or exit
    • G07C9/20Individual registration on entry or exit involving the use of a pass
    • G07C9/27Individual registration on entry or exit involving the use of a pass with central registration
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W40/00Estimation or calculation of non-directly measurable driving parameters for road vehicle drive control systems not related to the control of a particular sub unit, e.g. by using mathematical models
    • B60W40/08Estimation or calculation of non-directly measurable driving parameters for road vehicle drive control systems not related to the control of a particular sub unit, e.g. by using mathematical models related to drivers or passengers
    • B60W2040/0809Driver authorisation; Driver identity check

Definitions

  • the invention relates to a method for awarding access and driving permissions according to the closer defined in the preamble of claim 1.
  • the invention is intended to make the use of vehicles more flexible.
  • the method is particularly advantageous for vehicles used. which can drive partially autonomously or completely autonomously. Here then manual operation of the vehicle and autonomous or teilautonomer operation of the vehicle can be combined.
  • communication content particularly includes a driving task that the driver enters in the vehicle so that the vehicle autonomously or partially autonomously carries out a subsequent parking maneuver including access to a parking garage with the assistance of a data center. Access rights to the vehicle and
  • Driving permissions for the vehicle are not awarded by the aforementioned method.
  • DE 10 2012 012 389 A1 discloses a method for distributing access authorizations for the vehicle and driving authorizations for the vehicle. Here are both the access rights and the
  • the mobile terminal here has a protected Memory area to which the data is transferred.
  • the disposal over the protected storage area can be assigned to different user groups, so that a mobile driving authorization and conditional access system can be realized which takes into account different vehicle users.
  • DE 10 2013 201 168 A1 discloses a remote control system for motor vehicles, in which the driver can switch between manual operation of the vehicle and autonomous or partially autonomous operation of the vehicle. In autonomous or semi-autonomous operation, the driver gives the control to a remote monitoring or to a
  • Driving agents who then controls the vehicle.
  • the vehicle user can determine which persons should be involved in the remote monitoring.
  • a center comparable to a vehicle backend mediates the data connection between a personal data terminal of the vehicle user and the
  • Programs are provided by the head office.
  • the center provides for the communication link between mediated operator, vehicle and personal data terminal of the vehicle user.
  • remote monitoring systems is a permanent and trouble-free communication link between the vehicle, data terminal of the vehicle user and the mediated operator for the
  • US Pat. No. 9,494,938 B1 discloses a method for operating an autonomously driving vehicle
  • This token contains the necessary data to do this ordered taxi clearly assign the requesting customer and make this clear on arrival at the customer.
  • the signal is used to allow the robotaxi to authenticate the customer for the particular travel order.
  • This method requires no change over the control of the vehicle. The vehicle remains in autonomous driving even if the customer has boarded. A master computer in the vehicle retains full control of the vehicle all the time and guides the vehicle to the detected position of the customer's mobile terminal via a position adjustment of the vehicle. The driving authorization therefore does not need to be checked. Nor does the customer need to be granted access to the vehicle.
  • the token allocation can only be done by a dispatching system at the taxi operator. An independent certificate release by the authorizing party via the vehicle is therefore not available.
  • the creation of the token is always tied to the Dispatching System of the taxi operator. Thus, the method is limited in its applications to this application. The
  • Dispatching System establishes communication interfaces to the vehicle and the customer. Additional communication links to additional central
  • Data processing systems such as Vehicle Backend of the vehicle manufacturer.
  • Access authorization, driving authorization and issuing of driving commands for autonomous driving are not limited to autonomous driving.
  • none of the aforementioned methods can drive a vehicle in autonomous driving to a potential user and then continue driving the user in manual driving.
  • Vehicle is the vehicle can be moved autonomously, but then everyone can take over the vehicle. A theft protection would not exist anymore. The vehicle owner or owner would have no control over the vehicle. Is the identification element with the current vehicle owner or the owner can only start the vehicle. An autonomous drive without present current owner of the identification element is not possible because the immobilizer immediately intervene when no identification element is detected in the vehicle.
  • a service provider such as a car rental can not drive the vehicle in the theft-proof state driverless and autonomous to the customer and the customer takes over the vehicle and continues. He would not be able to use the previous access authorizations since he would first have to hand over a physical identification element.
  • the solution succeeds with a method in which several data processing systems of different user groups (eg car rental company, central background system of the manufacturer of the vehicle, user authentication, vehicle backend, potential vehicle user) exchange a data format over several communication links, which can also be called a certificate, and an exchange (eg the vehicle back end) takes over the distribution of the data format among the respectively involved user groups and into the respective vehicle.
  • the data format here contains data for the access authorization, for the driving authorization and for the travel command to be executed in autonomous driving mode.
  • a major advantage of the method is that no physical identification transmitter is necessary for the implementation, and nevertheless the physical identification transmitters for the vehicle, such as vehicle key or keyless go card, can be used in parallel without the access authorization codes and block or interfere with drive authorization codes from the keyless procedure with the codes in the physical identification transmitter. This is also achieved by using the data format in the method own driving permissions and
  • Access authorizations generated and distributed. That is, process-specific hash codes are generated and consumed. What the consumption of hash codes in
  • the data processing system of the potential vehicle user is a mobile one
  • a further advantageous embodiment of the method according to the invention provides that the data processing systems exchange the data format with each other and fill with the necessary data. If necessary, the data format must be filled with further necessary data.
  • the data processing systems of the respective user groups involved exchange the data format with each other and fill it, so that ultimately the completely filled data format at least in the area of the exchange, for example, the vehicle back end is present and can be transmitted as a completely filled data format to the vehicle. This procedure makes it possible for the individual
  • Data processing systems to trigger the generation of data formats even if they do not have all the necessary data. These can then be supplemented elsewhere, for example by having a person entitled to dispose of the vehicle O.K. for vehicle use, for example, issued by another user or the like.
  • the filled-in data format then enters the vehicle and can be used here accordingly.
  • Another great advantage of the method developed in accordance with the invention is then the increased availability of the vehicle and, in particular, the increased speed
  • the driving order can be combined with another support system, e.g. one
  • Data processing systems can be independent of each other on the separate communication paths. Basically, therefore, it does not need a permanent online connection in autonomous driving to perform the autonomous driving.
  • the data format transmitted to the vehicle and stored in the vehicle includes data for a plurality of access and driving authorizations that can be used successively in time, as well as operating commands to be executed.
  • Switching center such as the vehicle back end, so not only a data format can be projected to the vehicle, but several, which can be used sequentially in time. This makes it possible to transmit a group of data formats to the vehicle, for example ten individual ones
  • the sole attached figure shows the individual functions and tasks of the participating data processing systems in a schematic example.
  • the figure shows an indicated vehicle 1 and a designated 2 potential vehicle users.
  • This has a designated mobile terminal 3, for example, a smartphone as a data processing system.
  • Vehicle user 2 or his smartphone 3 is connected via a communication link indicated in principle, for example, with a user authentication 5 in connection.
  • This is exemplified here as a desktop computer and can, for example, in the office or at home in the on the vehicle 1
  • This data processing system for user authentication is in turn in contact with a designated 6 switch, which is designed as a vehicle back end and is also referred to as DaiVB (Daimler Vehicle Back End).
  • This exchange 6 in turn is in contact with a data processing system of one or more service providers for vehicle-related services 7. This may, for example, be a car-sharing system, a car rental or similar.
  • the exchange 6 is connected to a designated 8 background server of the vehicle manufacturer. These connections can be made, for example, via Internet connections, preferably secure Internet connections.
  • the user authentication 5 is operated and executed by the authorized person of the subject vehicle 1.
  • the authorized person gives e.g. on
  • the authentication is performed via the service Mercedes-me, another Internet portal associated with the vehicle and / or a parallel app,
  • the DaiVB 6 receives the released data format 9 and takes over the others
  • the most important task of the DaiVB 6 is then the transfer of the fully filled data format 9 into the relevant vehicle 1 or into a secure element 10 (protected data area) in the vehicle 1.
  • the central background system 8 provides in particular access data and
  • Driving authorization data ready and filled the data format 9 with the specific for the vehicle 1 access data and driving authorization data.
  • the driving authorization data (hash codes for the driving authorization system) can in this case be routed from the DaiVB 6 into the vehicle 1, so that the vehicle 1 can be started and moved with these codes.
  • the routing from the DaiVB 6 in the vehicle 1 is indicated accordingly via an air interface.
  • the access authorizations are also routed from the DaiVB 6 to the mobile terminal 3 of the user 2. Either directly via mobile or indirectly via the
  • the user 2 can then select the vehicle 1, e.g. is sent to him in autonomous driving, with his mobile terminal 3 open.
  • the hash codes for the driving authorization were already transferred to the vehicle 1 before the time of use.
  • a control unit 1 checks a or a
  • Control unit network whether the DaiVB 6 transmitted to the vehicle 1 data format 9 contains the same identifier as the data format 9 on the mobile terminal 3 of the user 2. If so, the transmitted to the vehicle 1 driving permissions are released and the vehicle 1 can by the user 2 per Start button to be started and driven. Appropriately, a sufficient number of
  • the transmitted access and driving permissions may also be temporal or local. e.g. related to the position of the vehicle 1, limited.
  • the service provider 7, eg landlord, car sharing, such as Car2Go, etc., or private citizen offers the vehicle 1, over which he is authorized to dispose, for example, on the Internet.
  • the service provider 7 with the user authentication 5 in the figure coincide.
  • the filling of the data format can also be started by the service provider 7. He can then issue the release himself.
  • the switching center 6 takes over the distribution of the compliant data format 9 to the vehicle 1 and to the user 2. In this case too, access and driving authorization data are transmitted from the central one
  • Background system 8 written in the data format 9. If the vehicle 1 is to drive autonomously to the user 2, a driving order for the autonomous journey must be created and written into the data format 9. If an autonomous journey is to be carried out, the vehicle 1 carries out this journey with the information in the driving order. In this case, the vehicle 1 can start itself with the driving authorizations likewise transmitted by data format 9 as soon as a certificate release from the user authentication 5 is present, which is likewise contained in the data format 9 and can be checked by the control unit 11 in the vehicle 1.
  • Vehicle 1 wants to drive autonomously. e.g. at the end of the production process or for loading or shipping the vehicle 1. Then the vehicle manufacturer with its central background system 8 starts the procedure in which of this

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • General Physics & Mathematics (AREA)
  • Transportation (AREA)
  • Human Computer Interaction (AREA)
  • Mathematical Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Traffic Control Systems (AREA)
  • Control Of Driving Devices And Active Controlling Of Vehicle (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen sowie auszuführender Fahrbefehle, in Form eines Datenformats (9), für ein Fahrzeug (1). Das erfindungsgemäße Verfahren ist dadurch gekennzeichnet, dass mehrere Datenverarbeitungssysteme unterschiedlicher Nutzergruppen (2, 5, 6, 7, 8), welche über mehrere Kommunikationsverbindungen das Datenformat (9) austauschen, genutzt werden, wobei eine Vermittlungsstelle (6) die Verteilung des Datenformats unter den jeweils involvierten Nutzergruppen (2, 5, 6, 7, 8) und in das Fahrzeug übernimmt.

Description

Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen
Die Erfindung betrifft ein Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen nach der im Oberbegriff von Anspruch 1 näher definierten Art.
Durch die Erfindung soll die Nutzung von Fahrzeugen flexibler gemacht werden. Hierzu werden insbesondere die Überprüfung und die Vergabe von Zugangsberechtigungen zum Fahrzeug, Fahrberechtigungsvergaben für das Fahrzeug sowie die Vergabe von
Fahrbefehlen an das Fahrzeug mit dem erfindungsgemäßen Verfahren ermöglicht und bewirkt. Das Verfahren ist hierbei besonders vorteilhaft bei Fahrzeugen einsetzbar. die teilautonom oder vollständig autonom fahren können. Hier können dann manueller Betrieb des Fahrzeugs und autonomer bzw. teilautonomer Betrieb des Fahrzeugs kombiniert werden.
Die Vergabe von Fahrbefehlen an autonom fahrfähige Fahrzeuge ist beispielsweise aus der DE 10 2014 001 836 A1 bekannt. Hier wird vorgeschlagen über ein zwischen dem Fahrzeug und einer Infrastruktureinheit auszutauschendes Signal Authentifizierungscodes und weitere Kommunikationsinhalte zu übermitteln. Zu den weiteren
Kommunikationsinhalten gehört gemäß Absatz 18 dieser Schrift insbesondere ein Fahrauftrag, den der Fahrer im Fahrzeug eingibt, damit das Fahrzeug ein anschließendes Parkmanöver inklusive Zufahrt in ein Parkhaus mit Unterstützung eines Rechenzentrums autonom bzw. teilautonom ausführt. Zugangsberechtigungen zum Fahrzeug und
Fahrberechtigungen für das Fahrzeug werden mit dem vorgenannten Verfahren nicht vergeben.
Des Weiteren ist aus der DE 10 2012 012 389 A1 ein Verfahren für das Verteilen von Zugangsberechtigungen zum Fahrzeug und von Fahrberechtigungen für das Fahrzeug bekannt. Hier werden sowohl die Zugangsberechtigungen als auch die
Fahrberechtigungen von einem Datenbankserver im sogenannten Vehicle Backend des Fahrzeugherstellers an ein mobiles Endgerät in der Hand des potentiellen
Fahrzeugnutzers übertragen. Das mobile Endgerät weist hierbei einen geschützten Speicherbereich auf, in den die Daten übertragen werden. Die Verfügung über den geschützten Speicherbereich kann verschiedenen Nutzergruppen zugeordnet werden, so dass ein mobiles Fahrberechtigungs- und Zugangsberechtigungssystem realisiert werden kann, welche verschiedene Fahrzeugnutzer berücksichtigt. Die Vergabe von
Fahrbefehlen und damit die sinnvolle Einbindung von autonomen oder teilautonomen Fahrzeugen ist mit dem vorgenannten Verfahren nicht möglich, da stets der potentielle Fahrer das Fahrzeug Öffnen, Starten und Fahren muss.
Mit der DE 10 2013 201 168 A1 ist ein Fernsteuerungssystem für Kraftfahrzeuge bekannt, bei dem der Fahrer zwischen manuellem Betrieb des Fahrzeug und autonomem bzw. teilautonomem Betrieb des Fahrzeugs wechseln kann. Im autonomen bzw. teilautonomen Betrieb gibt der Fahrer die Kontrolle an eine Fernüberwachung oder an einen
Fahragenten ab, die oder der dann das Fahrzeug steuert. Der Fahrzeugnutzer kann hierbei bestimmen welche Personen an der Fernüberwachung beteiligt sein sollen.
Umgekehrt kann die Fernüberwachung die Kontrolle über das Fahrzeug übernehmen, wenn der Fahrer erkennbar nicht mehr geeignet ist, das Fahrzeug sicher zu führen. Eine Zentrale vergleichbar einem Vehicle Backend vermittelt die Datenverbindung zwischen einem persönlichen Datenendgerät des Fahrzeugnutzers und dem
Fernüberwachungssystems. Zudem vermittelt die Zentrale Angebote für die Durchführung der Fernüberwachung an verschiedene Operatoren. Die notwendigen Software
Programme werden von der Zentrale zur Verfügung gestellt. Ebenso sorgt die Zentrale für die Kommunikationsverbindung zwischen vermitteltem Operator, Fahrzeug und persönlichem Datenendgerät des Fahrzeugnutzers. Für diese Fernüberwachungssysteme ist eine permanente und störungsfreie Kommunikationsverbindung zwischen Fahrzeug, Datenendgerät des Fahrzeugnutzers und dem vermittelten Operator für die
Fernüberwachung essentiell, wie es in Absatz 26 dieser Schrift ausgeführt ist.
Aus der US 9 494 938 B1 ist ein Verfahren zu Betrieb eines autonom fahrenden
Fahrzeugs, eines Robotaxis, bekannt, das zu einem, das Fahrzeug anfragenden, Kunden geführt wird. Erreicht das autonom fahrende Fahrzeug den Kunden wird dem Kunden eine Information angezeigt, entweder am Fahrzeug oder in einem mobilen Datenendgerät des Kunden, die dem Kunden das Fahrzeug als das bestellte Taxi identifiziert. Zu diesem Zweck wird ein einzigartiges Datensignal, ein sogenannter Token. zwischen
verschiedenen Datenverarbeitungsanlagen beim Taxibetreiber, bei Kunden und im Fahrzeug ausgetauscht und verteilt. Dieser Token enthält die notwendigen Daten, um das bestellte Taxi eindeutig dem anfragenden Kunden zuzuordnen und diesem bei Eintreffen beim Kunden kenntlich zu machen. Ebenso wird das Signal genutzt, um dem Robotaxi die Authentifizierung des Kunden für den betreffenden Fahrauftrag zu ermöglichen. Dieses Verfahren erfordert keinen Wechsel über die Kontrolle des Fahrzeugs. Das Fahrzeug verbleibt im autonomen Fahrbetrieb auch wenn der Kunde eingestiegen ist. Ein Leitrechner im Fahrzeug behält die ganze Zeit die vollständige Kontrolle über das Fahrzeug und führt das Fahrzeug über einen Positionsabgleich des Fahrzeugs an die erfasste Position des mobilen Endgeräts des Kunden. Die Fahrberechtigung muss daher nicht überprüft werden. Ebenso wenig muss dem Kunden eine Zugangsberechtigung in das Fahrzeug vermittelt werden. Die Token Vergabe kann nur von einem Dispatching System beim Taxibetreiber erfolgen. Eine eigenständige Zertifikatsfreigabe durch den Verf üg u ngsberechtigten über das Fahrzeug ist daher nicht vorhanden. Die Erstellung des Token ist immer an das Dispatching System des Taxibetreibers gebunden. Damit ist das Verfahren in seinen Anwendungsfällen auf diese Anwendung beschränkt. Das
Dispatching System baut Kommunikationsschnittstellen zum Fahrzeug und zum Kunden auf. Weitere Kommunikationsverbindungen zu zusätzlichen zentralen
Datenverarbeitungssystemen wie Vehicle Backend des Fahrzeugherstellers.
Autovermietungen oder zentrale Hintergrundsysteme eines Herstellers, mit denen die Fahrberechtigungssysteme und Zugangsberechtigungssysteme des Fahrzeugs bedatet werden, existieren nicht. Das Verfahren aus der US 9 494 938 B1 ist daher auf den Betrieb von Robotaxis ohne Wechsel in der Kontrolle über das Fahrzeug beschränkt.
Zusammenfassend kann gesagt werden, dass keine der vorgenannten technischen Lehren in der Lage ist in einem einheitlichen Verfahren die Themen
Zugangsberechtigung, Fahrberechtigung und Erteilen von Fahrbefehlen für den autonomen Fahrbetrieb zu behandeln. Beispielsweise kann keines der vorgenannten Verfahren ein Fahrzeug im autonomen Fahrbetrieb zu einem potentiellen Nutzer fahren lassen und dann der Nutzer im manuellen Fahrbetrieb weiter fahren. Dies scheitert bereits an den Fahrberechtigungssystemen, die bisher immer eine Übergabe eines dem Fahrzeugeigentümer zugeordneten Identifikationselements in Form eines Schlüssels oder einer Keyless-Go Card verlangen. D.h. wenn das Identifikationselement im
Fahrzeug ist kann das Fahrzeug zwar autonom bewegt werden, jedoch kann dann jeder das Fahrzeug übernehmen. Ein Diebstahlschutz wäre überhaupt nicht mehr gegeben. Der Fahrzeugbesitzer oder der Eigentümer hätten keine Kontrolle mehr über das Fahrzeug. Befindet sich das Identifikationselement beim aktuellen Fahrzeugbesitzer oder beim Eigentümer kann jeweils nur dieser das Fahrzeug starten. Eine autonome Fahrt ohne anwesenden aktuellen Besitzer des Identifikationselements ist nicht möglich, da sofort die Wegfahrsperren eingreifen, wenn im Fahrzeug kein Identifikationselement detektiert wird.
Ein anderes ungelöstes Problem aus dem bisher genannten Verfahren ist die
Kontrollfrage über die Fahrbefehle im autonomen Fahrbetrieb und die Frage der
Zugangsberechtigung in das Fahrzeug im autonomen Fährbetrieb bzw. beim Wechsel zum manuellen Fahrbetrieb. Bisher sind die Ausführung von Fahrbefehlen und die Zugangsberechtigung ebenfalls an die physikalische Anwesenheit eines
Identifikationselements gebunden. Ein Dienstleister wie eine Autovermietung kann das Fahrzeug nicht im diebstahlgesicherten Zustand führerlos und autonom zum Kunden fahren lassen und der Kunde übernimmt das Fahrzeug und fährt weiter. Mit den bisherigen Zugangsberechtigungen könnte er nicht einsteigen, da ihm ja zunächst ein physikalisches Identifikationselement übergeben werden müsste.
Erfindungsgemäße Aufgabe ist es daher, ein Verfahren anzugeben, mit dem der Wechsel zwischen führerlosem autonomen Fahrbetrieb und manuellem Fahrbetrieb besser kombiniert werden können, ohne dass es zu Problemen mit Fahrberechtigungssystemen, Zugangsberechtigungen oder dem Erteilen von Fahrbefehlen kommt.
Die Lösung gelingt mit einem Verfahren, bei dem mehrere Datenverarbeitungssysteme unterschiedlicher Nutzergruppen (z.B. Autovermieter, Zentrales Hintergrundsystem des Herstellers des Fahrzeugs. Benutzerauthentifizierung , Vehicle Backend, potentieller Fahrzeugnutzer) über mehrere Kommunikationsverbindungen ein Datenformat, welches auch als Zertifikat bezeichnet werden kann, austauschen und eine Vermittlungsstelle (z.B. das Vehicle Back End) die Verteilung des Datenformats unter den jeweils involvierten Nutzergruppen und in das betreffende Fahrzeug übernimmt. Das Datenformat enthält hierbei Daten für die Zugangsberechtigung, für die Fahrberechtigung und für den auszuführenden Fahrbefehl im autonomen Fahrbetrieb.
Ein großer Vorteil des Verfahrens ist, dass für die Durchführung kein physikalischer Identifikationsgeber notwendig ist und trotzdem die für das Fahrzeug vorhandenen physikalischen Identifikationsgeber, wie Fahrzeugschlüssel oder Keyless Go Card, parallel dazu genutzt werden können, ohne dass sich die Zugangsberechtigungscodes und Fahrberechtigungscodes aus dem schlüssellosen Verfahren mit den Codes im physikalischen Identifikationsgeber blockieren oder stören. Dies wird auch damit erreicht, das mit dem Datenformat in dem Verfahren eigene Fahrberechtigungen und
Zugangsberechtigungen, erzeugt und verteilt werden. Sprich es werden verfahrenseigene Hashcodes erzeugt und verbraucht. Was den Verbrauch von Hashcodes im
physikalischen Identifikationsgeber unberührt lässt. Das Fahrzeug erkennt dabei, ob es über ein übertragenes Datenformat zugänglich gemacht und gestartet werden soll oder mittels physikalischen Identifikationsgeber, der ein Zertifikat überträgt. Entsprechend werden fahrzeugseitig entweder die Berechtigungsdaten aus dem Datenformat oder die Berechtigungsdaten aus dem physikalischen Identifikationsgeber geprüft und nach erfolgreicher Prüfung genutzt.
Gemäß einer sehr günstigen Ausgestaltung ist es dabei zweckmäßiger Weise so, dass das Datenverarbeitungssystem des potentiellen Fahrzeugnutzers ein mobiles
Kommunikationsgerät ist.
Eine weitere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht es vor, dass die Datenverarbeitungssysteme das Datenformat untereinander austauschen und mit den notwendigen Daten befüllen. Das Datenformat muss gegebenenfalls noch mit weiteren notwendigen Daten befüllt werden. Die Datenverarbeitungssysteme der jeweils involvierten Nutzergruppen tauschen dazu das Datenformat untereinander aus und befüllen dieses, sodass letztlich das komplett ausgefüllte Datenformat zumindest im Bereich der Vermittlungsstelle, beispielsweise des Vehicle Back End entsprechend vorliegt und als vollständig ausgefülltes Datenformat an das Fahrzeug übertragen werden kann. Diese Vorgehensweise ermöglicht es dabei, den einzelnen
Datenverarbeitungssystemen die Erzeugung von Datenformaten anzustoßen, auch wenn ihnen nicht alle notwendigen Daten vorliegen. Diese können dann anderweitig ergänzt werden, beispielsweise indem ein Verfügungsberechtigter über das Fahrzeug sein O.K. zu einer Fahrzeugnutzung beispielsweise durch einen anderen Nutzer erteilt oder dergleichen. Das fertig befüllte Datenformat gelangt dann in das Fahrzeug und kann hier entsprechend genutzt werden.
Gemäß einer sehr vorteilhaften Weiterbildung des Verfahrens kann es vorgesehen sein, dass das an das Fahrzeug übermittelte Datenformat in dem Fahrzeug, insbesondere in einem geschützten Speicherbereich, gespeichert wird. Ein weiterer großer Vorteil des so weitergebildeten erfindungsgemäßen Verfahrens ist dann die erhöhte Verfügbarkeit des Fahrzeugs und insbesondere die erhöhte
Betriebssicherheit im autonomen Fahrbetrieb, Im Unterschied zu den vorbekannten Überwachungsverfahren bzw. Fernsteuerungsverfahren im autonomen Fahrbetrieb ist keine permanente Online Verbindung, die nicht abbrechen darf, notwendig. Dies wird erreicht durch die Platzierung des Datenformats bzw. Zertifikat im Fahrzeug. Eine Online Verbindung ist nur für die Zeitdauer der Übertragung notwendig. Nach erfolgter
Übertragung verfügt das Fahrzeug über alle notwendigen Daten, um
Zugangsberechtigung, Fahrberechtigung und Fahrauftrag auszuführen. Der Fahrauftrag kann gegebenenfalls mit einem weiteren U nterstützung ssystem z.B. einem
Navigationssystem durchgeführt werden. Ebenso wenig braucht der Nutzer eine permanente oder zeitlich koordinierte Datenverbindung zu einem der beteiligten
Datenverarbeitungssysteme. Die Verteilung des Datenformats an die beteiligten
Datenverarbeitungssysteme kann auf den getrennten Kommunikationswegen zeitlich unabhängig voneinander erfolgen. Grundsätzlich braucht es daher im autonomen Fahrbetrieb keine permanente Onlineverbindung, um die autonome Fahrt durchzuführen.
Eine günstige Weiterbildung dieser Ausgestaltung des erfindungsgemäßen Verfahrens sieht es dabei ferner vor, dass das an das Fahrzeug übermittelte und in dem Fahrzeug gespeicherte Datenformat Daten für mehrere zeitlich nacheinander nutzbare Zugangsund Fahrberechtigungen sowie auszuführende Fahrbefehle umfasst. Von der
Vermittlungsstelle, wie beispielsweise dem Vehicle Back End, kann also nicht nur ein Datenformat an das Fahrzeug überragen werden, sondern gleich mehrere, welche zeitlich nacheinander genutzt werden können. Hierdurch ist es möglich, eine Gruppe von Datenformaten an das Fahrzeug zu übertragen, beispielsweise zehn einzelne
Datenformate. Mit jedem dieser Datenformate kann dann, ohne dass eine Online- Verbindung des Fahrzeugs zu der Vermittlungsstelle besteht, eine Zugangsberechtigung oder eine Fahrberechtigung erteilt, sowie ein auszuführender Fahrbefehl freigegeben werden. Auch wenn das Fahrzeug über einen längeren Zeitraum keine Online- Verbindung zur Vermittlungsstelle hat, kann es dennoch über das vorzugsweise mobile Endgerät als Datenverarbeitungssystem des potenziellen Fahrzeug nutzers zu dessen Identifikation genutzt werden, auch mehrfach hintereinander, sodass eine Fahrt beispielsweise unterbrochen und nach einer gewissen Wartezeit, einer Übernachtung oder dergleichen fortgesetzt werden kann, ohne dass dazwischen eine Online- Verbindung zwischen dem Fahrzeug und der Vermittlungsstelle notwendig wäre. Dies ist hinsichtlich der Nutzung insbesondere dann ein entscheidender Gewinn an Komfort, wenn keine durchgehende Online-Verbindung zwischen dem Fahrzeug und der
Vermittlungsstelle möglich ist.
Weitere vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den weiteren abhängigen Unteransprüchen und aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figur näher erläutert werden.
Die einzige beigefügte Figur zeigt dabei die einzelnen Funktionen und Aufgaben der beteiligten Datenverarbeitungsanlagen in einem schematischen Beispiel.
Die Figur zeigt ein angedeutetes Fahrzeug 1 sowie einen mit 2 bezeichneten potenziellen Fahrzeug nutzer. Dieser verfügt über ein mit 3 bezeichnetes mobiles Endgerät, beispielsweise ein Smartphone als Datenverarbeitungssystem. Der potenzielle
Fahrzeugnutzer 2 bzw. sein Smartphone 3 steht über eine prinzipmäßig angedeutete Kommunikationsverbindung beispielsweise mit einer Benutzerauthentifizierung 5 in Verbindung. Diese ist hier beispielhaft als Desktop-Rechner dargestellt und kann beispielsweise im Büro oder zu Hause bei dem über das Fahrzeug 1
Verfügungsberechtigten positioniert sein. Dieses Datenverarbeitungssystem für die Benutzerauthentifizierung steht wiederum in Kontakt mit einer mit 6 bezeichneten Vermittlungsstelle, welche als Vehicle Back End ausgebildet ist und nachfolgend auch als DaiVB (Daimler Vehicle Back End) bezeichnet wird. Diese Vermittlungsstelle 6 steht wiederum mit einem Datenverarbeitungssystem eines oder mehrerer Dienstleister für fahrzeugbezogene Dienstleistungen 7 in Kontakt. Hierbei kann es sich beispielsweise über ein Car-Sharing-System , eine Autovermtetung oder ähnliches handeln. Außerdem steht die Vermittlungsstelle 6 mit einem mit 8 bezeichneten Hintergrundserver des Fahrzeug herstellers in Verbindung. Diese Verbindungen können beispielsweise über Internetverbindungen, vorzugweise gesicherte Internetverbindungen, ausgeführt werden.
Die Benutzerauthentifizierung 5 wird vom Verfügungsberechtigten des betreffenden Fahrzeugs 1 bedient und ausgeführt. Der Verfügungsberechtigte gibt z.B. ein
anfragendes Datenformat 9 frei und dokumentiert seine Zustimmung im Datenformat 9. Zweckmäßiger Weise erfolgt die Authentifizierung über den Dienst Mercedes-me, ein anderes dem Fahrzeug zugeordnetes Internet Portal und/oder eine parallel App, Das DaiVB 6 erhält das freigegebene Datenformat 9 und ubernimmt die weitere
Verteilung des Datenformats und die weiteren, eventuell notwendigen Anfragen, um das Datenformat 9 mit weiteren Daten zu befüllen. Wichtigste Aufgabe des DaiVB 6 ist dann der Transfer des voll befüllten Datenformats 9 in das betreffende Fahrzeug 1 bzw. in ein Secure Element 10 (geschützter Datenbereich) im Fahrzeug 1.
Das zentrale Hintergrundsystem 8 stellt insbesondere Zugangsdaten und
Fahrberechtigungsdaten bereit und befüllt das Datenformat 9 mit den für das Fahrzeug 1 spezifischen Zugangsdaten und Fahrberechtigungsdaten. Die Fahrberechtigungsdaten (Hash Codes für das Fahrberechtigungssystem) können hierbei vom DaiVB 6 in das Fahrzeug 1 geroutet werden, so dass das Fahrzeug 1 mit diesen Codes gestartet und bewegt werden kann. Das Routing vom DaiVB 6 in das Fahrzeug 1 ist dabei über eine Luftschnittstelle entsprechend angedeutet.
Die Zugangsberechtigungen werden außerdem vom DaiVB 6 an das mobile Endgerät 3 des Nutzers 2 geroutet. Entweder direkt über Mobilfunk oder indirekt über die
Benutzerauthentifizierung 5. wie es hier angedeutet ist. Der Nutzer 2 kann dann das Fahrzeug 1 , das z.B. in autonomer Fahrt zu ihm geschickt wird, mit seinem mobilen Endgerät 3 öffnen.
Die Hash Codes für die Fahrberechtigung wurden vor dem Zeitpunkt der Nutzung bereits in das Fahrzeug 1 transferiert. Im Fahrzeug 1 prüft ein Steuergerätl 1 oder ein
Steuergeräteverbund, ob das vom DaiVB 6 ins Fahrzeug 1 übertragene Datenformat 9 die gleiche Kennung enthält wie das Datenformat 9 auf dem mobilen Endgerät 3 des Nutzers 2. Wenn ja, werden die ins Fahrzeug 1 übertragenen Fahrberechtigungen freigegeben und das Fahrzeug 1 kann vom Nutzer 2 per Startknopf gestartet und gefahren werden. Zweckmäßiger Weise wird eine genügende Anzahl von
Fahrberechtigungen (Hash Codes) übertragen, so dass das Fahrzeug 1 mehrfach gestartet werden kann, bis alle Hash Codes verbraucht sind. Alternativ können die übertragenen Zugangs- und Fahrberechtigungen auch zeitlich oder örtlich. z.B. auf die Position des Fahrzeugs 1 bezogen, beschränkt werden.
Der Dienstanbieter 7, z.B. Vermieter, Carsharing, wie Car2Go, usw. , oder Privatmann bietet das Fahrzeug 1 , über das er verfügungsberechtigt ist, z.B. im Internet an. In diesem Fall kann der Dienstleister 7 mit der Benutzerauthentifizierung 5 in der Figur zusammenfallen. Wird ein angebotenes Fahrzeug 1 vom Nutzer 2 angefragt, kann die Befüllung des Datenformats auch vom Dienstanbieter 7 gestartet werden. Die Freigabe kann er dann gleich selbst erteilen. Wieder übernimmt die Vermittlungsstelle 6 die Verteilung des befüliten Datenformats 9 an Fahrzeug 1 und an den Nutzer 2. Zugangsund Fahrberechtigungsdaten werden auch in diesem Fall von dem zentralen
Hintergrundsystem 8 in das Datenformat 9 geschrieben. Soll das Fahrzeug 1 autonom zum Nutzer 2 fahren, muss ein Fahrauftrag für die autonome Fahrt erstellt und in das Datenformat 9 geschrieben werden. Soll eine autonome Fahrt durchgeführt werden, führt das Fahrzeug 1 diese Fahrt mit den Angaben im Fahrauftrag durch. Das Fahrzeug 1 kann sich hierbei mit den ebenfalls per Datenformat 9 übertragenen Fahrberechtigungen selbst starten, sobald eine Zertifikatfreigabe von der Benutzerauthentifizierung 5 vorliegt, die ja ebenfalls in dem Datenformat 9 enthalten ist und von dem Steuergerät 11 im Fahrzeug 1 überprüft werden kann.
Ein weiterer Anwendungsfall ergibt sich, wenn der Fahrzeughersteller selbst, das
Fahrzeug 1 autonom fahren lassen will. z.B. am Ende des Produktionsprozesses oder zur Verladung oder Verschiffung des Fahrzeugs 1. Dann startet der Fahrzeughersteller mit seinem zentralen Hintergrundsystem 8 das Verfahren, in dem von diesem
Hintergrundsystem 8 ein Datenformat 9 erstellt wird. In diesem Fall erfolgt die
Authentifizierung durch den Fahrzeughersteller, so dass das Hintergrundsystem 8 und die Benutzerauthentifizierung 5, unter Wegfall des Dienstleisters 7, zusammenfallen. Das DaiVB 6 übernimmt auch hier das Routing des Datenformats 9 an die weiteren beteiligten Datenverarbeitungssysteme. Der Fahrauftrag muss dann vom Fahrzeugherstelle über das zentrale Hintergrundsystem 8 erstellt werden. Der weitere Ablauf des Verfahrens läuft wie zuvor für das autonome Fahren bereits beschrieben.

Claims

Patentansprüche
1 . Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen sowie
auszuführender Fahrbefehle, in Form eines Datenformats (9), für ein Fahrzeug (1 ), dadurch gekennzeichnet, dass
mehrere Datenverarbeitungssysteme unterschiedlicher Nutzergruppen (2, 5, 6, 7, 8), welche über mehrere Kommunikationsverbindungen das Datenformat (9) austauschen, genutzt werden, wobei eine Vermittlungsstelle (6) die Verteilung des Datenformats unter den jeweils involvierten Nutzergruppen (2, 5, 6, 7, 8) und in das Fahrzeug übernimmt.
2. Verfahren nach Anspruch 1 ,
dadurch gekennzeichnet, dass
die Nutzergruppen (2, 5, 6, 7, 8) zumindest einem potenziellen Fahrzeugnutzer (2), einer Benutzerauthentifizierung (5) und einem Anbieter von fahrzeugbezogenen Dienstleistungen (7) und/oder dem Hersteller des Fahrzeugs (8) zugeordnet werden.
3. Verfahren nach Anspruch 1 oder 2,
dadurch gekennzeichnet, dass
zumindest eines der Datenverarbeitungssysteme des potenziellen Fahrzeugnutzers (2) als mobiles Endgerät (3) ausgebildet ist.
4. Verfahren nach einem der Ansprüche 1 , 2 oder 3,
dadurch gekennzeichnet, dass
die Datenverarbeitungssysteme das Datenformat (9) untereinander austauschen und mit den notwendigen Daten befüllen.
5. Verfahren nach einem der Ansprüche 1 bis 4,
dadurch gekennzeichnet, dass ein Fahrzeug-Backend-Server (6) als Vermittlungsstelle genutzt wird.
6. Verfahren nach einem der Ansprüche 1 bis 5,
dadurch gekennzeichnet, dass
das an das Fahrzeug (1 ) übermittelte Datenformat (9) in dem Fahrzeug (1 ) gespeichert wird.
7. Verfahren nach Anspruch 6,
dadurch gekennzeichnet, dass
das Speichern in einem geschützten Speicherbereich (1 1 ) erfolgt.
8. Verfahren nach Anspruch 6 oder 7,
dadurch gekennzeichnet, dass
das an das Fahrzeug (1 1 ) übermittelte und in dem Fahrzeug gespeicherte Datenformat (9) Daten für mehrere zeitlich nacheinander nutzbare Zugangs- und Fahrberechtigungen sowie auszuführende Fahrbefehle umfasst.
EP18733565.8A 2017-08-25 2018-06-20 Verfahren zur vergabe von zugangs- und fahrberechtigungen Withdrawn EP3673466A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017008084.4A DE102017008084A1 (de) 2017-08-25 2017-08-25 Verfahren zur Vergabe von Zugangs- und Fahrberechtigungen
PCT/EP2018/066368 WO2019037922A1 (de) 2017-08-25 2018-06-20 Verfahren zur vergabe von zugangs- und fahrberechtigungen

Publications (1)

Publication Number Publication Date
EP3673466A1 true EP3673466A1 (de) 2020-07-01

Family

ID=62712986

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18733565.8A Withdrawn EP3673466A1 (de) 2017-08-25 2018-06-20 Verfahren zur vergabe von zugangs- und fahrberechtigungen

Country Status (6)

Country Link
US (1) US11292485B2 (de)
EP (1) EP3673466A1 (de)
JP (1) JP7257343B2 (de)
CN (1) CN110914876B (de)
DE (1) DE102017008084A1 (de)
WO (1) WO2019037922A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11945447B2 (en) * 2020-02-13 2024-04-02 Toyota Motor North America, Inc. Transport boundary expansion
US11772672B2 (en) * 2020-02-13 2023-10-03 Toyota Motor North America, Inc. Unsafe transport operation
WO2022250951A1 (en) * 2021-05-27 2022-12-01 Nuro, Inc. Method and apparatus for vehicle sharing
KR20230124399A (ko) * 2022-02-18 2023-08-25 현대자동차주식회사 로보택시의 주행모드 제어 장치 및 그 방법

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4367986B2 (ja) * 1998-10-28 2009-11-18 富士通テン株式会社 オートロック機構制御用送信機および受信機とその運用方法
JP4202005B2 (ja) * 2001-07-27 2008-12-24 本田技研工業株式会社 車両共同利用システム
EP2273719A3 (de) * 2003-01-28 2012-04-25 Cellport Systems, Inc. Verfahren und Vorrichtung zum sicheren Gewähren eines Zugriffs auf und der Benutzung eines Zieldienstes unter Einbeziehung eines Fahrzeugs mit einem Sicherheitssteuergerät
JP4432578B2 (ja) * 2004-01-15 2010-03-17 マツダ株式会社 キーレスエントリー装置、システム及び方法
JP4887877B2 (ja) 2006-04-07 2012-02-29 トヨタ自動車株式会社 遠隔操作システムおよびそのシステムを構成する車載端末装置
CN101448340B (zh) * 2007-11-26 2011-12-07 联想(北京)有限公司 一种检测移动终端状态的方法、系统及该移动终端
JP5021801B2 (ja) * 2010-10-08 2012-09-12 信義 武藤 電気自動車のレンタルシステム及びレンタル方法
CN102582574B (zh) 2012-02-23 2015-05-27 浙江吉利汽车研究院有限公司 汽车借用远程授权启动装置及方法
DE102012012389A1 (de) 2012-06-21 2013-01-24 Daimler Ag Vorrichtung und Verfahren zum Steuern einer Zugangsberechtigung und/oder Fahrberechtigung für ein Fahrzeug
US10055694B2 (en) 2012-08-07 2018-08-21 Hitachi, Ltd. Use-assisting tool for autonomous mobile device, operation management center, operation system, and autonomous mobile device
KR20140043536A (ko) * 2012-09-24 2014-04-10 현대자동차주식회사 자율주행 차량의 차량 제어권 전환 방법
DE102013201168A1 (de) 2013-01-24 2014-07-24 Ford Global Technologies, Llc Bedarfsweise aktivierbares Fernsteuerungssystem für Kraftfahrzeuge
US20140303837A1 (en) * 2013-04-09 2014-10-09 Navteq Method and apparatus for authorizing access and utilization of a vehicle
CN103507809B (zh) * 2013-09-27 2016-05-18 奇瑞汽车股份有限公司 一种控制车辆行驶的方法和装置
WO2015056530A1 (ja) * 2013-10-17 2015-04-23 みこらった株式会社 自動運転車、自動運転車の盗難防止システム、自動運転車の盗難防止プログラム、端末制御用プログラム及び自動運転車のレンタル方法
WO2015099679A1 (en) * 2013-12-23 2015-07-02 Intel Corporation In-vehicle authorization for autonomous vehicles
DE102014001836A1 (de) 2014-02-11 2014-08-14 Daimler Ag Verfahren zum automatischen Betrieb eines Fahrzeuges
US9494938B1 (en) 2014-04-03 2016-11-15 Google Inc. Unique signaling for autonomous vehicles to preserve user privacy
DE102014104881A1 (de) * 2014-04-07 2015-10-08 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren und Zentralrecheneinheit zum unbemannten Steuern eines Fahrzeugs
JPWO2015166811A1 (ja) 2014-04-30 2017-04-20 みこらった株式会社 自動運転車及び自動運転車用プログラム
US9399445B2 (en) * 2014-05-08 2016-07-26 International Business Machines Corporation Delegating control of a vehicle
US9631933B1 (en) * 2014-05-23 2017-04-25 Google Inc. Specifying unavailable locations for autonomous vehicles
JP6330509B2 (ja) 2014-06-20 2018-05-30 住友電気工業株式会社 駐車管理システム、管理装置、及び駐車管理方法
JP6168636B2 (ja) * 2014-06-30 2017-07-26 みこらった株式会社 移動体呼び寄せシステム、呼び寄せ装置及び無線通信装置
DE102014221749A1 (de) 2014-10-27 2016-04-28 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Fahrzeugs
US20160189098A1 (en) * 2014-12-30 2016-06-30 Here Global B.V. Method and apparatus for providing access to contextually relevant vehicles for delivery purposes
US9805605B2 (en) * 2015-08-12 2017-10-31 Madhusoodhan Ramanujam Using autonomous vehicles in a taxi service
EP3345148A1 (de) * 2015-09-04 2018-07-11 Robert Bosch GmbH Werbetafelanzeige und verfahren zur selektiven anzeige von werbungen durch erfassung demografischer informationen von fahrzeugeninsassen
CN109074688A (zh) * 2016-02-04 2018-12-21 苹果公司 用于车辆授权的系统和方法
US9990783B2 (en) * 2016-02-16 2018-06-05 GM Global Technology Operations LLC Regulating vehicle access using cryptographic methods
CN105788333B (zh) * 2016-05-25 2018-02-02 四川化工职业技术学院 具有无人驾驶及回场充电功能的智能交通系统及实现方法

Also Published As

Publication number Publication date
US20210155256A1 (en) 2021-05-27
US11292485B2 (en) 2022-04-05
CN110914876A (zh) 2020-03-24
DE102017008084A1 (de) 2019-02-28
JP7257343B2 (ja) 2023-04-13
CN110914876B (zh) 2023-07-28
WO2019037922A1 (de) 2019-02-28
JP2020526824A (ja) 2020-08-31

Similar Documents

Publication Publication Date Title
EP0870654B1 (de) Vorrichtung und Verfahren zur fahrerspezifischen Einstellung von Fahrzeugeinrichtungen
DE102015013318B4 (de) Verfahren zur Entfernung eines Kraftfahrzeugs von einer Zielfläche, Kommunikationssystem und Kraftfahrzeug
EP2762988B1 (de) Bedarfsweise aktivierbares Fernsteuerungssystem und/oder Fernüberwachungssystem für Kraftfahrzeuge
DE19508370C2 (de) Verfahren zur Sicherung von Fahrzeugen, insbesondere Leasing- oder Mietfahrzeugen, vor unbefugter Nutzung
DE102013201169B4 (de) Fernüberwachungs- und/oder Fernsteuerungssystem für Kraftfahrzeuge
EP3673466A1 (de) Verfahren zur vergabe von zugangs- und fahrberechtigungen
DE10015644A1 (de) Vorrichtung zum Datenaustausch mit einem Kraftfahrzeug
DE112016007345T5 (de) Verfahren und vorrichtungen zum ermöglichen der fahrzeug-zu-fahrzeug-führung und -ortung
DE102015010203A1 (de) Verfahren zum Betreiben eines Kraftfahrzeugs und System zum Betreiben eines Kraftfahrzeugs
DE102019207547A1 (de) Verfahren und Vorrichtung zum Teleoperieren eines Fahrzeuges
DE202013100347U1 (de) Bedarfsweise aktivierbares Fernsteuerungssystem für Kraftfahrzeuge
DE102007024877A1 (de) Verfahren zur Bildung und Steuerung eines Fahrzeugverbandes
DE102013006087A1 (de) Verfahren um Einstellen von fahrer- und kraftfahrzeugspezifischen Konfigurationsparameter in einem Kraftfahrzeug gemäß einem Nutzerprofil mittels eines mobilen Kommunikationsendgeräts
DE102017217720B4 (de) Verfahren zum automatisierten Bereitstellen eines Kraftfahrzeugs
DE102013224198A1 (de) Verfahren zum Ausparken eines zugeparkten Fahrzeugs, Computerprogrammprodukt, Fahrzeug, Fernbedienereinrichtung, Server und System
DE102020207739A1 (de) Automatisches Valetparksystem, automatisches Valetparkprogramm und Speichermedium
DE102012013450A1 (de) Verfahren zum Steuern einer Zugangsberechtigung oder Fahrberechtigung für ein Fahrzeug
EP3821627B1 (de) Verfahren zum kontrollieren eines datenaustauschs zwischen einer steuereinrichtung eines kraftfahrzeugs und einer externen einrichtung, steuereinrichtung für ein kraftfahrzeug sowie kraftfahrzeug mit einer derartigen steuereinrichtung
WO2020074324A1 (de) Verfahren zum betreiben einer steuervorrichtung für ein kraftfahrzeug, steuervorrichtung für ein kraftfahrzeug sowie kraftfahrzeug mit einer derartigen steuervorrichtung
DE112013005761T5 (de) System und Verfahren zum Verwenden eines Autoradios zum Steuern der Lieferung von Premiuminhalt an ein Smartphone
WO2018197135A1 (de) Verfahren zum umparken eines fahrzeugs
DE102014011329A1 (de) Kraftfahrzeug und Verfahren zum Betreiben eines Fahrerassistenzsystem
DE102022127480A1 (de) Verfahren zum Erzeugen einer Freischaltinformation für mehrere Personen und Servereinrichtung
EP1075995B1 (de) Verfahren zum fahrzeugbewirkten Stellen von Weichen
DE102017205211A1 (de) Verfahren zum Betrieb eines automatisierten Kraftfahrzeugs und Kraftfahrzeug

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20191009

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
18D Application deemed to be withdrawn

Effective date: 20201013