DE102017114586A1 - On-demand driver systeme und -verfahren - Google Patents

On-demand driver systeme und -verfahren Download PDF

Info

Publication number
DE102017114586A1
DE102017114586A1 DE102017114586.9A DE102017114586A DE102017114586A1 DE 102017114586 A1 DE102017114586 A1 DE 102017114586A1 DE 102017114586 A DE102017114586 A DE 102017114586A DE 102017114586 A1 DE102017114586 A1 DE 102017114586A1
Authority
DE
Germany
Prior art keywords
vehicle
odc
din
softkey
odd
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.)
Pending
Application number
DE102017114586.9A
Other languages
English (en)
Inventor
Dave A. Herman
David Joseph Orris
Nunzio DeCia
Stephen Jay Orris
Nicholas Scheufler
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.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
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 Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102017114586A1 publication Critical patent/DE102017114586A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20—Means to switch the anti-theft system on or off
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME 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/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00182—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with unidirectional data transmission between data carrier and locks
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20—Means to switch the anti-theft system on or off
    • B60R25/24—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
    • B60R25/241—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user whereby access privileges are related to the identifiers
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/01—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles operating on vehicle systems or fittings, e.g. on doors, seats or windscreens
    • B60R25/04—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles operating on vehicle systems or fittings, e.g. on doors, seats or windscreens operating on the propulsion system, e.g. engine or drive motor
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/10—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles actuating a signalling device
    • B60R25/102—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles actuating a signalling device a signal being sent to a remote location, e.g. a radio signal being transmitted to a police station, a security company or the owner
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20—Means to switch the anti-theft system on or off
    • B60R25/24—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3407—Route searching; Route guidance specially adapted for specific applications
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3407—Route searching; Route guidance specially adapted for specific applications
    • G01C21/3423—Multimodal routing, i.e. combining two or more modes of transportation, where the modes can be any of, e.g. driving, walking, cycling, public transport
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3407—Route searching; Route guidance specially adapted for specific applications
    • G01C21/343—Calculating itineraries, i.e. routes leading from a starting point to a series of categorical destinations using a global route restraint, round trips, touristic trips
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3667—Display of a road map
    • G01C21/3676—Overview of the route on the road map
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0645—Rental transactions; Leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME 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
    • G07C2209/00—Indexing scheme relating to groups G07C9/00 - G07C9/38
    • G07C2209/60—Indexing scheme relating to groups G07C9/00174 - G07C9/00944
    • G07C2209/63—Comprising locating means for detecting the position of the data carrier, i.e. within the vehicle or within a certain distance from the vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mechanical Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Traffic Control Systems (AREA)
  • Lock And Its Accessories (AREA)
  • Navigation (AREA)

Abstract

Hierin werden beispielhafte On-Demand-Driver(ODD)-Systeme und -Verfahren beschrieben. Ein beispielhaftes Verfahren schließt, mit einem ODD-System, das Generieren eines Softkeys für ein Fahrzeug, der mit einer Vereinbarung zwischen einem Driver-In-Need (DIN) und einem ODD verknüpft ist, mit dem ODD-System, das Überwachen einer Position einer ODD-Vorrichtung, die von dem ODD getragen wird, und mit dem ODD-System, das Übertragen des Softkeys zu der ODD-Vorrichtung ein, wenn detektiert wird, dass sich die ODD-Vorrichtung in der Nähe des Fahrzeugs befindet. In dem beispielhaften Verfahren wird der Softkey verwendet, um das Fahrzeug zu entriegeln.

Description

  • GEBIET DER OFFENBARUNG
  • Diese Offenbarung betrifft im Allgemeinen Fahrer und insbesondere On-Demand-Driver-Systeme und -Verfahren.
  • HINTERGRUND
  • Es gibt viele Situationen, in denen ein Individuum nicht dazu in der Lage ist, sein/ihr Fahrzeug zu fahren, wie etwa nach einem Krankenhausaufenthalt, wenn das Individuum unter Alkoholeinfluss steht oder wenn ein medizinischer Zustand das Individuum am Fahren hindert. In anderen Situationen kann ein Individuum wünschen, dass sein Fahrzeug von einer Position zu einer anderen Position gefahren wird. Demnach wünschen sich Individuen oftmals einen Fahrer, der sein/ihr Fahrzeug mit dem oder ohne das Individuum in dem Fahrzeug von einer Position zu einer anderen fährt.
  • KURZDARSTELLUNG
  • Hierin werden beispielhafte On-Demand-Driver-Systeme und -Verfahren offenbart. Ein beispielhaftes hierin offenbartes Verfahren schließt, mit einem On-Demand-Driver(ODD; dt.: abrufbarer Fahrer)-System, das Generieren eines Softkeys für ein Fahrzeug, der mit einer Vereinbarung zwischen einem Driver-In-Need (DIN; dt.: anfordernder Fahrer) und einem ODD verknüpft ist, mit dem ODD-System, das Überwachen einer Position einer ODD-Vorrichtung, die von dem ODD getragen wird und mit dem ODD-System, das Übertragen des Softkeys zu der ODD-Vorrichtung ein, wenn detektiert wird, dass sich die ODD-Vorrichtung in der Nähe des Fahrzeugs befindet. In dem beispielhaften Verfahren wird der Softkey verwendet, um das Fahrzeug zu entriegeln.
  • Ein anderes beispielhaftes hierin offenbartes Verfahren schließt, mit einem On-Demand-Driver(ODD)-System, das Generieren eines ersten Softkeys und eines zweiten Softkeys für ein Fahrzeug, die mit einer Vereinbarung zwischen einem Driver-In-Need (DIN) und einem ODD verknüpft sind und mit dem ODD-System, das Übertragen des ersten Softkeys zu einer ODD-Vorrichtung, die von dem ODD getragen wird und des zweiten Softkeys zu einer DIN-Vorrichtung ein, die von dem DIN getragen wird. In dem beispielhaften Verfahren werden der erste Softkey und der zweite Softkey benötigt, um das Fahrzeug zu entriegeln.
  • Ein beispielhaftes hierin offenbartes Gerät schließt eine Vereinbarungsdatenbank, um eine On-Demand-Driver(ODD)-Vereinbarung zwischen einem Driver-In-Need (DIN) und einem ODD für den Transport eines Fahrzeugs zu speichern und eine Positionsüberwachungsvorrichtung zum Verfolgen einer Position einer ODD-Vorrichtung ein, die von dem ODD getragen wird. Das beispielhafte Gerät schließt außerdem einen Softkey-Manager ein, um einen Softkey zum Starten des Fahrzeugs zu generieren und den Softkey zu der ODD-Vorrichtung zu übertragen, wenn detektiert wird, dass sich die ODD-Vorrichtung in der Nähe des Fahrzeugs befindet.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 veranschaulicht ein beispielhaftes On-Demand-Chauffeur(ODC)-System, in dem die Lehren dieser Offenbarung umgesetzt werden können.
  • 2 veranschaulicht eine beispielhafte Schnittstelle, die auf einer beispielhaften Driver-In-Need(DIN)-Vorrichtung zum Erstellen einer Anfrage für einen ODC-Service mit dem beispielhaften ODC-System aus 1 angezeigt wird.
  • 3 veranschaulicht eine beispielhafte Schnittstelle, die auf einer beispielhaften ODC-Vorrichtung zum Betrachten einer Anfrage für einen ODC-Service von dem beispielhaften ODC-System aus 1 angezeigt wird.
  • 4 veranschaulicht eine beispielhafte Schnittstelle, die auf einer beispielhaften ODC-Vorrichtung zum Eingeben eines Angebotspreises für die Durchführung eines ODC-Services von dem beispielhaften ODC-System aus 1 angezeigt wird.
  • 5A veranschaulicht eine beispielhafte Schnittstelle, die auf einer beispielhaften DIN-Vorrichtung zum Betrachten und Annehmen eines Angebots für die Durchführung eines ODC-Services über das beispielhafte ODC-System aus 1 angezeigt wird.
  • 5B, 5C und 5D veranschaulichen beispielhafte Schnittstellen, die auf einer beispielhaften DIN-Vorrichtung zum Autorisieren des Erstellens eines Softkeys über das beispielhafte ODC-System aus 1 angezeigt werden.
  • 6 veranschaulicht eine beispielhafte Schnittstelle, die auf einer beispielhaften ODC-Vorrichtung zum Bestätigen eines ODC-Services von dem beispielhaften ODC-System aus 1 angezeigt wird.
  • 7 veranschaulicht eine beispielhafte Schnittstelle, die auf einer beispielhaften ODC-Vorrichtung zum Entriegeln eines Fahrzeugs angezeigt wird, das mit einem ODC-Service von dem beispielhaften ODC-System aus 1 verknüpft ist.
  • 8 veranschaulicht eine beispielhafte Warnung, die einem ODC über ein Fahrzeugkombiinstrument angezeigt wird, wenn der ODC von einer angewiesenen Route von dem beispielhaften ODC-System aus 1 abweicht.
  • 9 veranschaulicht eine beispielhafte Schnittstelle, die auf einer beispielhaften DIN-Vorrichtung angezeigt wird, wenn sich der DIN nicht in dem Fahrzeug befindet und ein ODC von einer angewiesenen Route von dem beispielhaften ODC-System aus 1 abgewichen ist.
  • 10 veranschaulicht eine beispielhafte Schnittstelle, die auf einer beispielhaften DIN-Vorrichtung angezeigt wird, wenn sich der DIN in dem Fahrzeug befindet und ein ODC von einer angewiesenen Route von dem beispielhaften ODC-System aus 1 abgewichen ist.
  • 11 ist ein Ablaufdiagramm, das ein Beispielverfahren veranschaulicht, das von dem beispielhaften ODC-System aus 1 zum Anordnen eines ODC-Services umgesetzt werden kann.
  • 12 ist ein Ablaufdiagramm, das ein Beispielverfahren veranschaulicht, das von dem beispielhaften ODC-System aus 1 umgesetzt werden kann, um es einem ODC zu ermöglichen, auf ein Fahrzeug zuzugreifen und dieses zu starten.
  • 13 ist ein Ablaufdiagramm, das ein Beispielverfahren veranschaulicht, das von dem beispielhaften ODC-System aus 1 zum Überwachen eines ODC umgesetzt werden kann, während ein Fahrzeug von einer Fahrzeugabholposition zu einer Fahrzeugabstellposition überführt wird.
  • 14 ist ein Ablaufdiagramm, das ein Beispielverfahren veranschaulicht, das von dem beispielhaften ODC-System aus 1 umgesetzt werden kann, wenn ein ODC während eines ODC-Services von einer angewiesenen Route abweicht.
  • 15 ist ein Blockdiagramm eines beispielhaften Prozessorsystems, das strukturiert ist, um beispielhafte maschinenlesbare Anweisungen auszuführen, die zumindest teilweise von 11–14 dargestellt werden, um das beispielhafte ODC-System aus 1 umzusetzen.
  • Bestimmte Beispiele werden in den zuvor identifizierten Figuren gezeigt und nachfolgend ausführlich beschrieben. Bei der Beschreibung dieser Beispiele werden ähnliche oder identische Bezugszeichen verwendet, um die gleichen oder ähnliche Elemente zu identifizieren. Die Figuren sind nicht zwingend maßstabsgetreu und bestimmte Merkmale und bestimmte Ansichten der Figuren können zum Zwecke der Eindeutigkeit und/oder Exaktheit vergrößert oder schematisch gezeigt werden. Zusätzlich wurden in dieser Patentschrift verschiedene Beispiele beschrieben. Beliebige Merkmale aus einem beliebigen Beispiel können mit, als Ersatz für andere(n) Merkmale(n) aus anderen Beispielen oder auf andere Weise damit kombiniert, eingeschlossen sein.
  • DETAILLIERTE BESCHREIBUNG
  • Beispielhafte Verfahren, Systeme/Geräte und Erzeugnisse werden hierin offenbart, um einen On-Demand-Driver(ODD)-Service zwischen einem Driver-In-Need (DIN) und einem ODD zu vereinfachen. Wie hierin verwendet, steht ein Driver-In-Need (DIN) für eine beliebige Person, die einen Fahrer (z. B. einen Chauffeur) einsetzen möchte, um ein Fahrzeug von einer Position zu einer anderen zu transportieren. Der DIN kann der Eigentümer des Fahrzeugs sein oder nicht. Wie hierin verwendet, können die Begriffe Fahrer, On-Demand-Driver (ODD), Chauffeur und On-Demand-Chauffeur (ODC) synonym verwendet werden und für eine beliebige Person stehen, die dazu bereit ist, ein Fahrzeug mit oder ohne den DIN von einer Position zu einer anderen zu fahren. Wie hierin verwendet, steht ein ODC-Service für einen Transfer eines Fahrzeugs zwischen zwei Positionen, mit oder ohne den DIN.
  • Es gibt viele Fälle, in denen ein DIN wünschen kann, dass sein/ihr Fahrzeug von einer Position zu einer anderen transportiert wird. Zum Beispiel kann der DIN beeinträchtigt oder nicht dazu in der Lage sein, das Fahrzeug zu fahren, wie etwa zum Beispiel nach einem Krankenhausaufenthalt oder wenn der DIN unter Alkoholeinfluss steht oder sich in einem beeinträchtigten Zustand befindet (z. B. betrunken). In solchen Fällen möchte der DIN möglicherweise, einen Fahrer anstellen, um das Fahrzeug für den DIN zu fahren. In anderen Beispielen kann der DIN dazu in der Lage sein, das Fahrzeug zu fahren, kann aber dennoch wünschen, dass ein Fahrer das Fahrzeug von einer Position zu einer anderen transportiert. Zum Beispiel kann ein DIN eine Kanufahrt machen und wünschen, dass jemand das Fahrzeug von einer Position, stromaufwärts, zu einer anderen Position, stromabwärts, fährt, wo der DIN wieder auf das Fahrzeug treffen kann. Anders ausgedrückt, gibt es zahlreiche Situationen, in denen ein Individuum wünschen oder benötigen kann, dass sein/ihr Fahrzeug (oder das Fahrzeug einer anderen Person) von einer Position zu einer anderen gefahren wird.
  • Es werden hierin beispielhafte ODC-Systeme offenbart, die eine Vereinbarung zwischen einem DIN und einem ODC und die Ausführung eines ODC-Services vereinfachen. In den offenbarten Beispielen kommuniziert ein DIN über eine DIN-Vorrichtung, wie etwa ein Mobiltelefon, mit dem ODC-System und erstellt eine Anfrage für einen ODC-Service. Die Anfrage schließt Anfragekriterien, wie etwa die Fahrzeugabholposition, die Fahrzeugabstellposition, zeitliche Einschränkungen usw. ein. Andere Kriterien können zum Beispiel ein bevorzugtes Geschlecht des ODC, eine minimale Bewertungsrate des ODC, einen flexiblen Modus für die Zeitplanung, eine Obergrenze für den Mindestpreis und/oder eine Geofence-Nähe zu dem Fahrzeug einschließen. Das ODC-System empfängt die Anfrage (z. B. über eine Internetverbindung), sucht nach potenziellen ODCs und überträgt die Anfrage zu den ODCs, welche die Anfragekriterien erfüllen. Die ODCs kommunizieren mit dem ODC-System über eine ODC-Vorrichtung, die ebenfalls ein Mobiltelefon sein kann. Die ODCs schauen sich die Anfrage an und geben, falls sie bereit sind, ein Angebot ein, um den angeforderten Fahrzeugtransfer abzuschließen. Das ODC-System trägt dann das eine oder die mehreren Angebote von den ODCs zusammen und überträgt sie zu der DIN-Vorrichtung. Der DIN kann eines der Angebote auswählen, um die ODC-Dienstleistungsvereinbarung abzuschließen. In einigen Beispielen sendet das ODC-System, nachdem ein DIN ein Angebot von einem ODC ausgewählt hat, eine abschließende Bestätigungsanfrage zu dem ODC, um zu überprüfen, ob der ODC immer noch dazu bereit und/oder in der Lage ist, den ODC-Service auszuführen. Bei einer Bestätigung wird eine Vereinbarung erreicht.
  • Um zu ermöglichen, dass der ODC auf das Fahrzeug zugreifen und das Fahrzeug starten kann (z. B. wenn der DIN nicht anwesend ist), generieren beispielhafte ODC-Systeme einen Softkey (z. B. einen digitalen Schlüssel), der zu dem Fahrzeug gehört und senden den Softkey zu der ODC-Vorrichtung. Wenn der ODC in der Nähe des Fahrzeugs ist, kann der ODC (z. B. über Bluetooth®, WLAN, Mobilfunkdaten usw.) den Softkey von der ODC-Vorrichtung zu dem Fahrzeug übertragen, welcher die Türen des Fahrzeugs entriegelt. In einigen Beispielen ermöglicht der Softkey außerdem, dass der ODC das Fahrzeug starten kann. Folglich ermöglichen die beispielhaften ODC-Systeme, dass ein ODC das Fahrzeug entriegeln und das Fahrzeug ohne Zugriff auf den physischen Schlüssel zu dem Fahrzeug fahren kann. In einigen Beispielen schließt der Softkey als ein Sicherheitsmerkmal eine Einschränkung hinsichtlich der Nähe ein. Der Softkey wird nicht zu der ODC-Vorrichtung übertragen, bis detektiert wird, dass sich der ODC innerhalb einer festgelegten Nähe zu dem Fahrzeug befindet. Zusätzlich oder alternativ kann der Softkey eine zeitliche Einschränkung einschließen. Wenn der ODC das Fahrzeug nicht innerhalb einer festgelegten Zeitspanne erreicht, verfällt der Softkey und wird nicht zu der ODC-Vorrichtung gesendet.
  • In einigen Beispielen kann, wenn der DIN das Fahrzeug während des ODC-Services begleiten soll, ein doppelter Softkey erforderlich sein. Insbesondere wird ein erster Softkey für die ODC-Vorrichtung generiert und ein zweiter Softkey wird für die DIN-Vorrichtung generiert. Beide Softkeys sind erforderlich, um das Fahrzeug zu entriegeln und/oder das Fahrzeug zu starten. Die Verwendung eines doppelten Softkeys ermöglicht es dem DIN, aus dem ODC-Service auszusteigen, nachdem er den ODC am Fahrzeug getroffen hat. Zum Beispiel kann der DIN, wenn der ODC nicht fahrtüchtig zu sein scheint, ablehnen, den zweiten Softkey zu aktivieren, wodurch der ODC daran gehindert wird, auf das Fahrzeug zuzugreifen.
  • Mit beispielhaften hierin offenbarten ODC-Systemen wird die Position des Fahrzeugs während des Transports überwacht oder verfolgt. In einigen Beispielen bestimmt das ODC-System eine Navigationsroute und stellt die Navigationsroute für die ODC-Vorrichtung und/oder das Fahrzeug bereit, sodass der ODC zu der Fahrzeugabstellposition geleitet werden kann. In einigen Beispielen überträgt das ODC-System, wenn detektiert wird, dass das Fahrzeug von der Route oder einem Korridor der Route abweicht (z. B. um eine vordefinierte Distanz oder einen vordefinierten Radius von der Route), eine Warnung zu dem Fahrzeug. Die Warnung kann zum Beispiel auf einem Kombiinstrument des Fahrzeugs angezeigt werden. Mit der Warnung wird der ODC benachrichtigt, dass er/sie von der angewiesenen Route abgewichen ist und wieder zu der Route zurückkehren sollte. In einigen Beispielen wird eine Option bereitgestellt, um den DIN zu kontaktieren, um eine Autorisierung zum Abweichen von der Route zu erhalten. Wenn der ODC nicht innerhalb eines Zeitraums zu der angewiesenen Route zurückkehrt, wird eine Warnung oder Benachrichtigung zu der DIN-Vorrichtung übertragen, die den DIN warnt, dass das Fahrzeug von der angewiesenen Route abgewichen ist. In einigen Beispielen ermöglicht die Warnung dem DIN, den ODC zu kontaktieren (z. B. um den Grund zu ermitteln oder von der angewiesenen Route abzuweichen). Wenn der DIN es genehmigt, kann der DIN den ODC dazu autorisieren, auf der abweichenden Route fortzufahren. Andernfalls ermöglicht es die Warnung dem DIN, die Behörden zu kontaktieren und/oder das Fahrzeug zu deaktivieren.
  • Nun veranschaulicht 1 ausführlich in Bezug auf die Figuren ein Beispielsystem 100, das ein On-Demand-Chauffeur(ODC)-System 102 einsetzt, um die Planung und Ausführung eines ODC-Services zu vereinfachen. In dem veranschaulichten Beispiel wünscht ein Driver-In-Need (DIN) 104, dass sein/ihr Fahrzeug 106 mit oder ohne den DIN 104 von einer Position (einer Fahrzeugabholposition) zu einer anderen Position (einer Zielposition oder Fahrzeugabstellposition) transportiert wird. Das ODC-System 102 kann unter Verwendung eines Servers umgesetzt werden, der ein(e) oder mehrere Anwendungen oder Programme betreibt. Der DIN 104 kommuniziert mit dem ODC-System 102 unter Verwendung einer DIN-Vorrichtung 108. In dem veranschaulichten Beispiel ist die DIN-Vorrichtung 108 ein mobiles Smartphone. Jedoch kann die DIN-Vorrichtung 108 eine beliebige elektronische Vorrichtung, wie etwa ein Computer (z. B. ein Desktop-Computer, ein tragbarer Computer oder Laptop), ein Handgerät (z. B. ein Smartphone, ein Tablet usw.), eine tragbare Vorrichtung (z. B. eine Smartwatch), ein Infotainmentsystem in dem Fahrzeug 106 und/oder eine beliebige andere elektronische Vorrichtung sein, die eine Anzeige und einen Prozessor aufweist. In einigen Beispielen schließt die DIN-Vorrichtung 108 ein globales Navigationssatellitensystem (GNSS) (z. B. einen Global-Position-System(GPS)-Sensor), um eine Position der DIN-Vorrichtung 108 zu verfolgen und/oder einen drahtlosen Sendeempfänger (z. B. einen Bluetooth®-Sendeempfänger), wie hierin ausführlicher erörtert, ein.
  • Das beispielhafte ODC-System 102 sucht nach einer oder mehreren Personen, die als ODCs registriert sind, die dazu bereit und in der Lage sind, den ODC-Service auszuführen und vereinfacht einen ODC-Service, wie von dem DIN 104 angefordert. Ein beispielhafter ODC 110 wird in 1 veranschaulicht. Der ODC 110 kommuniziert mit dem ODC-System 102 über eine ODC-Vorrichtung 112. Ähnlich der DIN-Vorrichtung 108 wird die ODC-Vorrichtung 112 als ein Mobiltelefon implementiert, kann jedoch eine beliebige elektronische Vorrichtung, wie etwa ein Computer (z. B. ein Desktop-Computer, ein tragbarer Computer oder Laptop), ein Handgerät (z. B. ein Smartphone, ein Tablet usw.), eine tragbare Vorrichtung (z. B. eine Smartwatch) und/oder eine beliebige andere elektronische Vorrichtung sein, die eine Anzeige und einen Prozessor aufweist. In einigen Beispielen schließt die ODC-Vorrichtung 112 ein GNSS, um eine Position der ODC-Vorrichtung 112 zu verfolgen und/oder einen drahtlosen Sendeempfänger (z. B. einen Bluetooth®-Sendeempfänger) ein. Obwohl lediglich ein ODC 110 abgebildet ist, versteht es sich, dass eine beliebige Anzahl von ODCs mit dem ODC-System 102 verbunden sein und/oder in Kommunikation stehen kann.
  • In dem veranschaulichten Beispiel aus 1 kommunizieren das Fahrzeug 106, die DIN-Vorrichtung 108 und die ODC-Vorrichtung 112 über ein Netzwerk 114 mit dem ODC-System 102. Das beispielhafte Netzwerk 114 von dem veranschaulichten Beispiel aus 1 ist das Internet. Jedoch kann das beispielhafte Netzwerk 114 unter Verwendung eines geeigneten drahtgebundenen und/oder drahtlosen Netzwerks bzw. geeigneter drahtgebundener und/oder drahtloser Netzwerke umgesetzt werden, einschließend zum Beispiel einen oder mehrere Datenbusse, ein oder mehrere lokale Netzwerke (LANs), ein oder mehrere drahtlose LANs, ein oder mehrere zellulare Netze, ein oder mehrere private Netzwerke, ein oder mehrere öffentliche Netzwerke usw. Das beispielhafte Netzwerk 114 ermöglicht, dass das ODC-System 102 mit dem Fahrzeug 106, der DIN-Vorrichtung 108 und der ODC-Vorrichtung 112 in Kommunikation steht. Wie hierin verwendet, umschließt die Wendung „in Kommunikation“, einschließend Varianten davon, eine direkte Kommunikation und/oder indirekte Kommunikation durch eine oder mehrere Zwischenkomponenten und macht keine direkte physische (z. B. drahtgebundene) Kommunikation und/oder konstante Kommunikation erforderlich, sondern schließt vielmehr eine selektive Kommunikation in regelmäßigen oder unregelmäßigen Intervallen sowie einmalige Ereignisse ein.
  • In dem veranschaulichten Beispiel wird eine Anzahl von Software-, Firmware- und/oder Hardwarekomponenten des Fahrzeugs 106 veranschaulicht. In anderen Beispielen kann das Fahrzeug 106 mehr oder weniger der beispielhaften Komponenten umsetzen. In dem veranschaulichten Beispiel schließt das Fahrzeug 106 eine Sensorfusion-Motorsteuereinheit (ECU) 116, eine Telekommunikationssteuereinheit (TCU) 118, ein Bordnetzsteuermodul (BCM) 120, eine Antriebsstrangsteuereinheit (PCU) 122, ein Zusatzprotokollschnittstellenmodul (APIM) 124, eine Anzeige oder Mensch-Maschine-Schnittstelle (HMI) 126, eine Audiokopfeinheit (AHU) 128, einen Audioausgang 130, ein Kombiinstrument 132 und ein Frontdisplay (HUD) 134 ein.
  • Die Sensorfusion-ECU 116 weist Schnittstellen zu einer oder mehreren Vorrichtungen oder einem oder mehreren Sensoren auf und vereinigt die Informationen von der bzw. den Vorrichtung(en) oder dem bzw. den Sensor(en), um ein Bewusstsein über den Raum, den das Fahrzeug 106 einnimmt und die Umgebung des Fahrzeugs 106 aufrechtzuerhalten. In dem veranschaulichten Beispiel schließt das Fahrzeug ein GNSS 136, einen drahtlosen Sendeempfänger 138 und eine Kamera 140 ein. Das GNSS 136 kann zum Beispiel einen GPS-Sensor einschließen und wird zum Verfolgen der Position des Fahrzeugs 106 verwendet. Das GNSS 136 kann auf einer beliebigen Konstellation von Satelliten basieren, die zur Ortung verwendet werden, wie etwa GPS, Glonass, Galileo, Beidou usw. Der drahtlose Sendeempfänger 138 kann zum Beispiel einen Bluetooth®-Sendeempfänger oder eine beliebige andere Vorrichtung für die Nahfeldkommunikation (NFC) einschließen und wird verwendet, um eine drahtlose Kommunikation mit anderen Vorrichtungen, wie etwa der DIN-Vorrichtung 108 und/oder der ODC-Vorrichtung 112 einzurichten. Zusätzlich oder alternativ kann der drahtlose Sendeempfänger 138 verwendet werden, um andere Vorrichtungen, wie etwa die DIN-Vorrichtung 108 und/oder die ODC-Vorrichtung 112, zu detektieren, zu identifizieren und/oder zu verfolgen. Die Kamera 140 wird verwendet, um Menschen zu verfolgen und/oder zu identifizieren, wenn sie sich dem Fahrzeug 106 nähern. In anderen Beispielen kann das Fahrzeug 106 mehr oder weniger Sensoren oder Vorrichtungen einschließen. Die Sensorfusion-ECU 116 verarbeitet die Signale von den Vorrichtungen 136, 138, 140 und kommuniziert mit den anderen Komponenten des Fahrzeugs 106.
  • In dem veranschaulichten Beispiel stellt die TCU 118 eine Verbindung zu einem zellularen Netz bereit, um Daten zwischen dem Fahrzeug 106 und dem Netzwerk 114 zu übertragen. In einigen Beispielen kommuniziert die TCU 118 durch ein geschütztes Netzwerk (z. B. ein privates Netzwerk), das von dem Hersteller des Fahrzeugs 106 (oder einer anderen Entität) betrieben wird, mit dem Netzwerk 114, um den Datenschutz und die Leistung der verschiedenen telematischen Funktionen zu garantieren. Das BCM 120 ist eine ECU, die einen oder mehrere Schlüssel (z. B. einen Softkey oder einen digitalen Schlüssel) authentifiziert, die ein Verriegeln/Entriegeln und/oder Starten des Fahrzeugs 106 ermöglichen, wie hierin ausführlicher offenbart. Die PCU 122 (z. B. ein Antriebsstrangsteuermodul) ist eine ECU, die den Motor steuert (z. B. Starten und Stoppen des Motors).
  • Das APIM 124 verwaltet den Zustand eines Infotainmentsystems in dem Fahrzeug 106. Das APIM 124 ist für das Generieren der Inhalte der HMI oder grafischen Benutzeroberfläche (GUI) und für die Pflege der Geschäftslogik des Fahrzeugs 106 verantwortlich. In einigen Beispielen schließt das APIM 124 eine WLAN- und/oder Bluetooth®-Konnektivität ein. Die Anzeige 126 ist ein Endgerät (z. B. ein Bildschirm, eine HMI, eine GUI usw.) zum Anzeigen der HMI/GUI-Inhalte, die von dem APIM 124 generiert werden. Die Anzeige 126 kann Berührungsantworteingaben, Audio usw. einschließen.
  • Die AHU 128 ist eine ECU, die AM/FM-Signale und/oder andere Audiosignale empfängt und die Signale zu der Audioausgabe 130 leitet. Die Audioausgabe 130 ist ein Fahrzeuglautsprechersystem und schließt einen oder mehrere Lautsprecher ein. In einigen Beispielen werden die Audiosignale zunächst durch einen Verstärker geleitet. Das Kombiinstrument 132 zeigt die Informationen aus dem Federal Motor Vehicle Safety Standard (FMVSS) (z. B. Tachometer, Kilometerzähler, Kraftstoffanzeige usw.) an. Das Kombiinstrument 132 generiert außerdem die HMI/GUI-Inhalte für das HUD 134, welches ein projiziertes Bild ist, das auf einer Windschutzscheibe oder einem Armaturenbrett des Fahrzeugs 106 angezeigt wird. In dem veranschaulichten Beispiel können die Komponenten des Fahrzeugs 106 durch ein beliebiges drahtgebundenes oder drahtloses Netzwerk, wie etwa einen Controller-Area-Network-Bus (CAN-Bus), einen Ethernet-Link oder einen Low Voltage Differential Signaling (LVDS) Link, kommunikativ gekoppelt sein.
  • In einigen Beispielen richten sowohl der DIN 104 als auch der ODC 110 vor dem Verhandeln eines ODC-Services mit dem ODC-System 102 ein Service-Konto ein, um die notwendige Kommunikation zwischen der DIN-Vorrichtung 108, der ODC-Vorrichtung 112 und dem Fahrzeug 106 zu vereinfachen. In dem veranschaulichten Beispiel schließt das ODC-System 102 eine Kontodatenbank 142 ein, die Konten für Personen einschließt, die als potenzielle DINs und/oder ODCs registriert sind. Für einen ODC kann der Kontoerstellungsprozess eine Überprüfung eines gültigen Führerscheins (der z. B. mit den Richtlinien des jeweiligen Staats übereinstimmt) und/oder anderer Altersbeschränkungen je nach lokaler Stadtverordnung (z. B. Ausgangssperre) einschließen. In einigen Beispielen können andere Informationen für ein ODC-Konto erforderlich sein, wie etwa eine Überprüfung einer gültigen Versicherung, eine Hintergrundüberprüfung hinsichtlich der Anzahl von Verkehrsverstößen usw. Ein DIN-Konto kann Informationen im Hinblick auf das Fahrzeug des DIN, die Position des Fahrzeugs, die Überprüfung einer gültigen Kennzeichenregistrierung usw. einschließen. Ferner können die Konten für die DINs und ODCs in einigen Beispielen Bilder der Individuen, Bewertungsraten für die Individuen und/oder andere bibliografische und/oder identifizierende Informationen einschließen. Die Konten der zertifizierten ODCs und der DINs werden in der Kontodatenbank 142 gespeichert.
  • Wenn der DIN 104 einen ODC-Service planen möchte, erstellt der DIN 104 eine Anfrage (z. B. eine ODC-Anfrage) über die DIN-Vorrichtung 108. Die DIN-Vorrichtung 108 schließt einen Bildschirm mit einer Schnittstelle zum Kommunizieren mit dem ODC-System 102 ein. Die Schnittstelle kann eine Anwendung (z. B. eine ODC-Anwendung) sein, die in der DIN-Vorrichtung 108 gespeichert ist (und von dem ODC-System 102 versorgt wird). In anderen Beispielen kann die Schnittstelle über einen Internetbrowser in der DIN-Vorrichtung 108 bereitgestellt werden. 2 veranschaulicht eine beispielhafte Schnittstelle 200, die auf der DIN-Vorrichtung 108 angezeigt wird, um eine Anfrage für einen ODC-Service (z. B. eine ODC-Anfrage) zu erstellen. Die Anfrage schließt Kriterien oder Parameter zum Definieren des gewünschten ODC-Services ein. In dem veranschaulichten Beispiel schließt die Schnittstelle 200 eine Fahrzeugabholpositionseingabe 202 ein. In einigen Beispielen kann der DIN 104 manuell die gewünschte Fahrzeugabholposition spezifizieren (z. B. wenn die Fahrzeugabholposition nicht die aktuelle Position des Fahrzeugs 106 ist). Zusätzlich oder alternativ kann die aktuelle Position, wenn die Fahrzeugabholposition die aktuelle Position des Fahrzeugs 106 ist, über das GNSS 136 (1) detektiert und in der Fahrzeugabholpositionseingabe 202 eingegeben werden. Die Schnittstelle 200 schließt außerdem eine Fahrzeugabstellpositionseingabe 204 ein, wobei der DIN 104 die gewünschte Fahrzeugabstellposition (z. B. das Zuhause des DIN, ein Büro usw.) spezifiziert. In dem veranschaulichten Beispiel schließt die Schnittstelle 200 eine Anfragedauereingabe 206 zum Eingeben eines Zeitraums für die Anfragedauer ein. Der Zeitraum für die Anfragedauer ist ein Zeitraum, in dem die Anfrage bestätigt und/oder ausgeführt werden muss, andernfalls verfällt die Anfrage.
  • In dem veranschaulichten Beispiel schließt die Schnittstelle 200 eine Fahrzeugeigenschafteneingabe 208 ein. Der DIN 104 kann identifizierbare Eigenschaften des Fahrzeugs 106, wie etwa die Marke des Fahrzeugs 106, das Modell des Fahrzeugs 106, die Farbe des Fahrzeugs 106, die Kennzeichennummer usw., eingeben, was dem ODC 110 beim Identifizieren des Fahrzeugs 106 helfen kann. Die Schnittstelle 200 schließt eine DIN-Anwesenheitskennung 210 ein. Der DIN 104 spezifiziert, ob der DIN 104 mit dem Fahrzeug 106 anwesend sein wird. Wie zuvor erwähnt, kann der DIN 104 in einigen Situationen wünschen, in dem Fahrzeug 106 gefahren zu werden, während der DIN 104 in anderen Situationen wünschen kann, dass das Fahrzeug 106 ohne die Anwesenheit des DIN 104 überführt wird. In dem veranschaulichten Beispiel schließt die Schnittstelle 200 eine Eingabe 212 zu zeitlichen Einschränkungen ein, welche es dem DIN 104 ermöglicht, zeitliche Einschränkungen, wie etwa den Zeitraum, zu definieren, in dem der DIN 104 den ODC-Service wünscht. In einigen Beispielen definiert der DIN 104 ein spezifisches Zeitfenster um den angeforderten ODC-Service. Zum Beispiel kann der DIN 104 spezifizieren, dass die Fahrt innerhalb der nächsten 20 Minuten stattfinden soll. In anderen Beispielen definiert der DIN 104 ein Zeitfenster um die angeforderte Zeit (z. B. plus oder minus 10 Minuten). In einigen Beispielen kann ein voreingestelltes Zeitfenster (z. B. ein Standardzeitfenster) eingesetzt werden.
  • In einigen Beispielen können andere Anfragekriterien über die Schnittstelle 200 spezifiziert und mit der Anfrage bereitgestellt werden. Zum Beispiel kann der DIN 104 ein bevorzugtes Geschlecht des ODC (z. B. kann sich ein weiblicher DIN mit einem weiblichen ODC wohler fühlen als mit einem männlichen ODC), eine minimale Bewertungsrate des ODC, einen flexiblen Modus für die Zeitplanung, eine Obergrenze für den Mindestpreis und/oder eine Geofence-Nähe zu dem Fahrzeug 106 spezifizieren.
  • Sobald die gewünschten Anfragekriterien spezifiziert sind, wählt der DIN 104 eine Anfrageschaltfläche 214 aus, um die Anfrage abzuschicken. Die Anfrage wird zusammen mit den Anfragekriterien von der DIN-Vorrichtung 108 zu dem ODC-System 102 gesendet. Andernfalls kann der DIN 104 eine Abbruchschaltfläche 216 auswählen, um die Anfrage abzubrechen.
  • Erneut in Bezug auf 1 schließt das ODC-System 102 einen Anfrage-Parser 144 ein. Der Anfrage-Parser 144 analysiert die Anfragekriterien, bestimmt, welche ODCs die Anfragekriterien erfüllen oder diesen genügen (z. B. auf Grundlage der Verfügbarkeit, des Geschlechts, der Bewertungsrate usw.) und überträgt die Anfrage zu den geeigneten ODCs. In einigen Beispielen wird die Anfrage nur innerhalb einer definierten geocodierten Region (z. B. in der Nähe des Fahrzeugs 106) zu ODCs gesendet.
  • Sobald die Anfrage verbreitet wurde, kann die Anfrage auf der ODC-Vorrichtung 112 angeschaut werden. Ähnlich der DIN-Vorrichtung 108 schließt die ODC-Vorrichtung 112 einen Bildschirm zum Anzeigen einer Schnittstelle zum Kommunizieren mit dem ODC-System 102 ein. Die Schnittstelle kann eine Anwendung (z. B. eine ODC-Anwendung) sein, die in der ODC-Vorrichtung 112 gespeichert ist (und von dem ODC-System 102 versorgt wird). In anderen Beispielen kann die Schnittstelle über einen Internetbrowser in der ODC-Vorrichtung 112 bereitgestellt werden. 3 veranschaulicht eine beispielhafte Schnittstelle 300, die auf der ODC-Vorrichtung 112 angezeigt wird, um eine Anfrage für einen ODC-Service zu betrachten. In dem veranschaulichten Beispiel wird die Anfrage auf einer Karte 302 angezeigt, welche die Position des Fahrzeugs 106 (z. B. die Fahrzeugabholposition), die Fahrzeugabstellposition und eine geschätzte Dauer zum Fahren des Fahrzeugs 106 zu der Fahrzeugabstellposition zeigt. In anderen Beispielen kann die Karte 302 mehr oder weniger Informationen einschließen. Wenn der ODC 110 mit dem angeforderten ODC-Service fortfahren möchte, kann der ODC 110 eine Annahmeschaltfläche 304 (z. B. „Anfrage annehmen“) auswählen, um ein Angebot für die Anfrage zu platzieren. Andernfalls kann der ODC 110, wenn der ODC 110 nicht mit dem angeforderten ODC-Service fortfahren möchte, eine Abbruchschaltfläche 306 auswählen.
  • In einigen Beispielen können mehrere Anfragen zur gleichen Zeit anstehen. In einem derartigen Beispiel zeigt die Schnittstelle 300 mehrere Anfragen innerhalb eines definierten Radius von dem ODC 110 an (z. B. 1 Meile (= ca. 1,6 Kilometer) von der aktuellen Position des ODC 110). In anderen Beispielen kann bzw. können die Anfrage(n) in einer Liste (z. B. einem Auflistungsformat im „Auktionsstil“) angezeigt werden, die Informationen, wie etwa zum Beispiel die Distanz zu dem Fahrzeug, die Bewertung des DIN, beliebige zeitliche Einschränkungen usw. einschließen kann. Der ODC 110 kann die verfügbare(n) Anfrage(n) durchstöbern, eine Anfrage auswählen und die Annahmeschaltfläche 304 auswählen, um ein Angebot für die ausgewählte Anfrage zu platzieren. In einigen Beispielen wird auf der ODC-Vorrichtung 112 eine Pop-up-Benachrichtigung angezeigt, welche den ODC 110 im Hinblick auf einen möglichen Auftrag in der Nähe benachrichtigt. Der ODC 110 kann auswählen, die Anfrage anzuschauen, die zum Beispiel über die Schnittstelle 300 präsentiert wird.
  • 4 veranschaulicht eine beispielhafte Schnittstelle 400, die auf der ODC-Vorrichtung 112 angezeigt wird, zum Eingeben eines Angebots, das mit der Anfrage verknüpft ist. In dem veranschaulichten Beispiel schließt die Schnittstelle 400 eine Karte 402 (z. B. ähnlich der Karte 302) ein. In dem veranschaulichten Beispiel zeigt die Karte 402 die Position des ODC 110, die Fahrzeugabholposition, eine geschätzte Dauer und eine geschätzte Distanz zu der Fahrzeugabholposition, die Fahrzeugabstellposition und eine geschätzte Dauer und eine geschätzte Distanz zwischen der Fahrzeugabholposition und der Fahrzeugabstellposition. In anderen Beispielen kann die Karte 402 mehr oder weniger Informationen einschließen. In dem veranschaulichten Beispiel schließt die Schnittstelle 400 einen Ziffernblock 404 ein, mit dem der ODC 110 einen gewünschten Preis oder eine gewünschte Gebühr für den Abschluss des ODC-Services eingeben kann. Nachdem das Angebot eingegeben wurde, wählt der ODC 110 eine Schaltfläche 406 zum Eingeben des Angebots aus, um das Angebot abzuschließen und das Angebot zu dem ODC-System 102 zu senden. Andernfalls kann der ODC 110 eine Schaltfläche 408 zum Abbrechen der Anfrage auswählen, um die Anfrage abzubrechen.
  • Erneut in Bezug auf 1 schließt das ODC-System 102 einen Angebotszusammensteller 146 ein, der das eine oder die mehreren Angebote von den ODCs zusammenstellt und das bzw. die Angebot(e) zu dem DIN 104 zum Betrachten durch den DIN 104 auf der DIN-Vorrichtung 108 (z. B. auf einem Telefon, in dem Fahrzeug 106 usw.) überträgt. 5A veranschaulicht eine beispielhafte Schnittstelle 500, die auf der DIN-Vorrichtung 108 angezeigt wird, um das bzw. die Angebot(e) zu betrachten. Die Schnittstelle 500 schließt eine Auflistung des Angebots bzw. der Angebote ein, das bzw. die von dem bzw. den ODC(s) bereitgestellt wird bzw. werden. In dem veranschaulichten Beispiel schließt die Schnittstelle 500 ein erstes Angebot 502, ein zweites Angebot 504 und ein drittes Angebot 506 ein. In anderen Beispielen können mehr oder weniger Angebote aktiv sein. Das erste Angebot 502 kann zum Beispiel mit dem ODC 110 verknüpft sein. In dem veranschaulichten Beispiel schließen die Angebote die jeweiligen Bewertungsraten der ODCs, den jeweiligen Abstand der ODCs zu dem Fahrzeug 106, die angegebenen Preise (d. h. den Angebotspreis) und/oder Bilder der jeweiligen ODCs ein. In anderen Beispielen können mehr oder weniger Informationen über die ODCs angezeigt werden. Der DIN 104 kann die Angebote durchsehen, eines der Angebote auswählen und dann eine Annahmeschaltfläche 508 (z. B. „Angebot annehmen & Softkey übertragen) auswählen. Andernfalls kann der DIN 104 eine Schaltfläche 510 zum Abbrechen des Angebots auswählen, um die ODC-Anfrage abzubrechen. Die Informationen über das ausgewählte Angebot werden von der DIN-Vorrichtung 108 zu dem ODC-System 102 gesendet.
  • In einigen Beispielen wird die DIN-Vorrichtung 108, nachdem eine Vereinbarung zwischen dem DIN 104 und dem ODC 110 erreicht wurde, verwendet, um die Erstellung eines Softkeys für das Fahrzeug 106 zu autorisieren. 5B–5D veranschaulichen beispielhafte Schnittstellen, die auf der DIN-Vorrichtung 108 zum Autorisieren der Erstellung eines Softkeys angezeigt werden und wie nachfolgend ausführlicher beschrieben erwünscht sind.
  • In einigen Beispielen wird, sobald der DIN 104 das Angebot angenommen hat, eine abschließende Überprüfung zu der ODC-Vorrichtung 112 übertragen, um den ODC-Service zu bestätigen. Erneut in Bezug auf 1 schließt das ODC-System 102 ein Bestätigungsmodul 148 ein. Das Bestätigungsmodul 148 empfängt das ausgewählte Angebot von der DIN-Vorrichtung 108 und überträgt eine Bestätigungsmitteilung zu der ODC-Vorrichtung 112. In einigen Beispielen wird es dem ODC 110 dadurch, dass es erforderlich ist, dass der ODC 110 eine abschließende Bestätigung bereitstellen muss, ermöglicht, die endgültige Entscheidung darüber zu treffen, ob mit dem angeforderten ODC-Service fortgefahren werden soll oder nicht. In einigen Beispielen ist zu viel Zeit vergangen, seit der ODC 110 das Angebot eingegeben hat und der ODC 110 ist möglicherweise nicht mehr dazu bereit oder, den angeforderten ODC-Service auszuführen.
  • 6 veranschaulicht eine beispielhafte Schnittstelle 600, die auf der ODC-Vorrichtung 112 angezeigt wird, um den ODC-Service zu bestätigen. In dem veranschaulichten Beispiel schließt die Schnittstelle 600 eine Karte 602 ein. Ähnlich der Karte 402 aus 4 zeigt die Karte 602 die aktuelle Position des ODC 110, die Fahrzeugabholposition, eine vorgeschlagene Route, um sich zu der Fahrzeugabholposition zu bewegen, eine geschätzte Distanz und eine geschätzte Dauer zwischen dem ODC 110 und der Fahrzeugabholposition, die Fahrzeugabstellposition, eine vorgeschlagene zum Fahren des Fahrzeugs 106 und eine geschätzte Distanz und eine geschätzte Dauer zwischen der Fahrzeugabholposition und der Fahrzeugabstellposition. In anderen Beispielen kann die Karte 602 mehr oder weniger Informationen einschließen. Wenn der ODC 110 mit dem ODC-Service fortfahren möchte, wählt der ODC 110 eine Annahmeschaltfläche 604 (z. B. „OK. Bin auf dem Weg.“) aus. Andernfalls kann der ODC 110, wenn der ODC 110 nicht mit dem angeforderten ODC-Service fortfahren möchte, eine Abbruchschaltfläche 606 auswählen, um die Vereinbarung aufzuheben. In einigen Beispielen überträgt das Bestätigungsmodul 148, nachdem der ODC 110 die Anfrage angenommen hat, eine Mitteilung zu der DIN-Vorrichtung 108, um anzuzeigen, dass der ODC-Service von dem ODC 110 ausgeführt wird.
  • In einigen Beispielen schließt die Anfrage eine Ablaufzeit ein, die von dem DIN 104 beim Platzieren der Anfrage (z. B. über die Anfragedauereingabe 206) eingestellt werden kann. Wenn die Anfrage nicht von beiden Parteien vor Ablauf bestätigt wird, kann die Anfrage verfallen. Andernfalls kann der DIN 104 auswählen, die Anfrage zu verlängern oder die Anfrage zu einem späteren Zeitpunkt erneut aufzulisten (z. B. mit anderen Kriterien, wie etwa mit einem höheren Mindestpreis, flexibleren zeitlichen Einschränkungen usw.).
  • Sobald eine Vereinbarung erreicht ist, wird die Vereinbarung (zusammen mit den zugehörigen Informationen (z. B. den Anfragekriterien)) in einer Vereinbarungsdatenbank 150 (1) gespeichert. In einigen Beispielen wird, sobald eine Vereinbarung erreicht wurde, eine Zahlung für den ODC-Service verarbeitet (z. B. über ein zuvor autorisiertes Zahlungsverfahren, das in dem Konto des DIN 104 und des ODC 110 gespeichert ist). Das beispielhafte ODC-System 102 schließt einen Zahlungsprozessor 152 ein, der Zahlungen von dem DIN 104 zu dem ODC 110 verarbeitet. In einigen Beispielen spezifiziert der ODC 110 seine/ihre Zahlungsbedingungen (z. B. bei der Eingabe des Angebots). In einigen Beispielen kann das Konto des DIN 104 vorfinanziert sein und das Geld kann automatisch von dem Konto des DIN 104 auf das Konto des ODC 110 übertragen werden. In anderen Beispielen kann eine Zahlung nach Abschluss des ODC-Services übertragen werden.
  • In einigen Beispielen wird ein Vorabautorisierungsmodus bereitgestellt, um es dem DIN 104 zu ermöglichen, eine Anfrage zu erstellen und die Übertragung der Anfrage bis zu einem späteren Zeitpunkt hinauszuzögern. Zum Beispiel ist der DIN 104 nicht zwangsläufig dazu in der Lage, eine manuelle Anfrage zu dem Zeitpunkt zu erstellen oder einzugeben, zu dem der DIN 104 annimmt, dass er den ODC-Service benötigt. Zum Beispiel kann der DIN 104 einen Termin in einem Krankenhaus haben (z. B. für eine Operation) und ist nicht zwangsläufig dazu in der Lage, die Anfrage nach der Operation zu tätigen (z. B. da der DIN 104 beeinträchtig ist). Als ein anderes Beispiel kann der DIN 104 annehmen, dass er zum Zeitpunkt, zu dem er den ODC-Service benötigt, nicht über eine zellulare Konnektivität verfügt. In derartigen Beispielen kann der DIN 104 eine Anfrage mit einer Einschränkung für die verzögerte Übertragung erstellen (z. B. eingegeben über die Schnittstelle 200 aus 2). Zum Beispiel kann die Anfrage so eingestellt werden, dass sie zu einem bestimmten Zeitpunkt aktiviert wird, wenn die Operation des DIN 104 vorbei ist. Die Anfrage wird von dem Anfrage-Parser 144 empfangen, aber der Anfrage-Parser 144 verzögert die Übertragung der Anfrage zu dem bzw. den verfügbaren ODC(s) bis zu dem spezifizierten Zeitpunkt. Die Anfrage kann außerdem andere voreingestellte Parameter, wie etwa eine automatische Bestätigung beliebiger Angebote, die unter einem festgelegten Betrag liegen, das Auswählen des günstigsten Angebots, das innerhalb einer Schwellenzeit empfangen wird, das Auswählen eines Angebots auf Grundlage der höchsten Bewertungsrate für einen ODC, das Auswählen eines Angebots auf Grundlage der nächsten Nähe zu dem Fahrzeug 106 usw., einschließen.
  • Sobald eine Vereinbarung hinsichtlich des ODC-Services getroffen wurde, gelangt der ODC 110 in der geplanten Zeit zu dem Fahrzeug 106. In einigen Beispielen wird auf der ODC-Vorrichtung 112 eine Karte angezeigt, um den ODC 110 zu dem Fahrzeug 106 zu navigieren (z. B. wie etwa die Karte 602 in der Schnittstelle 600 aus 6). Die Karte stellt eine vorgeschlagene Route bereit, um den ODC 110 bestmöglich zu dem Fahrzeug 106 zu leiten, um die zeitlichen Kriterien der Anfrage zu erfüllen. Die Position des ODC 110 wird über die ODC-Vorrichtung 112 verfolgt und zu dem ODC-System 102 übertragen. In dem veranschaulichten Beispiel aus 1 schließt das ODC-System 102 eine Navigations-/Positionsüberwachungsvorrichtung 154 ein, welche die Position der DIN-Vorrichtung 108, der ODC-Vorrichtung 112 und des Fahrzeugs 106 überwacht. In einigen Beispielen erstellt die Navigations-/Positionsüberwachungsvorrichtung 154 Karten und/oder generiert Routen (z. B. die Karte 302 aus 3, die Karte 402 aus 4, die Karte 602 aus 6 usw.), die zu der DIN-Vorrichtung 108, der ODC-Vorrichtung 112 und dem Fahrzeug 106 übertragen werden. In dem veranschaulichten Beispiel kommuniziert das ODC-System 102 über eine Fahrzeugschnittstelle 156 mit dem Fahrzeug 106.
  • Um es dem ODC-110 zu ermöglichen, die Türen des Fahrzeugs 106 zu entriegeln und das Fahrzeug 106 zu starten, schließt das ODC-System 102 einen Softkey-Manager 158 ein, der einen Softkey (z. B. einen Smartkey) für das Fahrzeug 106 generiert. Der Softkey ist ein digitaler Schlüssel oder eine digitale Bescheinigung, der bzw. die bei einer korrekten Abstimmung auf das Verriegelungssystem des Fahrzeugs (z. B. das BCM 120) die Türen des Fahrzeugs 106 entriegelt und/oder ein Starten des Fahrzeugs 106 ermöglicht. Der Softkey kann zum Beispiel einem digitalen Schlüssel ähneln, der von einem drahtlosen Schlüsselanhänger für das Fahrzeug 106 verwendet wird. In einigen Beispielen schließt der Softkey eine Einschränkung hinsichtlich der Nähe (z. B. eine Distanz) und/oder eine zeitliche Einschränkung (z. B. eine Ablaufzeit) ein, wie hierin ferner erörtert. In einigen Beispielen generiert der Softkey-Manager 158 den Softkey auf Grundlage von Informationen über oder Berechtigungsnachweisen für das Fahrzeug 106, die in der Kontodatenbank 142 (z. B. wie mit dem Konto des DIN 104 verknüpft) gespeichert sind. In anderen Beispielen befragt das ODC-System 102 das BCM 120 des Fahrzeugs 106, um die notwendigen Berechtigungsnachweise zum Generieren des Softkeys zu identifizieren und/oder erhält die Berechtigungsnachweise zum Generieren des Softkeys von einem geschützten Netzwerk (z. B. einem privaten Netzwerk), das von dem Hersteller des Fahrzeugs 106 (oder einer anderen Entität) betrieben wird, in dem der Softkey und/oder zugehörige Berechtigungsnachweise gespeichert sind. In weiteren Beispielen generiert der Softkey-Manager 158 eine einzigartige Zugriffssperre, die (z. B. über die Fahrzeugschnittstelle 156) zu dem Fahrzeug 106 übertragen wird, und einen passenden Softkey, der zu der ODC-Vorrichtung 112 übertragen wird. In einigen Beispielen wird eine Vielzahl von Softkeys für die einmalige Verwendung für das Fahrzeug 106 generiert. Sobald ein Schlüssel verwendet wurde, verfällt er und kann nicht noch einmal verwendet werden, um die Türen zu entriegeln und/oder das Fahrzeug 106 zu starten. In einigen Beispielen wird eine Kopie des Softkeys zu dem Fahrzeug 106 übertragen, sodass das Fahrzeug 106 verfolgen kann, wann ein Softkey verwendet wird und die erneute Verwendung desselben Softkeys einschränken kann. In einigen derartigen Beispielen kann das Fahrzeug 106 außerdem überprüfen, ob der Softkey innerhalb des spezifizierten Zeitraums verwendet wird und falls nicht, kann es den Zugriff auf das Fahrzeug einschränken. In einigen Beispielen wird der Softkey von dem Softkey-Manager 258 zu dem Fahrzeug 106 übertragen, der dann von dem Fahrzeug 106 zu der ODC-Vorrichtung 112 übertragen wird (z. B. auf Grundlage einer zeitlichen Einschränkung und/oder einer Einschränkung hinsichtlich der Nähe). Die Kommunikation von dem Fahrzeug 106 zu der ODC-Vorrichtung 112 kann das Generieren einer HMI (z. B. wie in 6 veranschaulicht) zum Entriegeln der Türen des Fahrzeugs 106 auslösen. In einigen Beispielen werden andere Befehle direkt von dem Fahrzeug 106 zu der ODC-Vorrichtung 112 gesendet. In einigen Beispielen wird der Softkey zwischen dem Softkey-Manager 158, der DIN-Vorrichtung 108, der ODC-Vorrichtung 112 und/oder dem Fahrzeug 106 über ein Händeschütteln oder einen anderen sicheren Kommunikationskanal (z. B. Secure Socket Layer (SSL)) kommuniziert.
  • In einigen Beispielen autorisiert der DIN 104 das Generieren des Softkeys. Dieses Generieren kann vor einer Vereinbarung hinsichtlich eines ODC-Services, während der Verhandlung der Vereinbarung oder nachdem die Vereinbarung erreicht wurde, stattfinden. 5B veranschaulicht eine beispielhafte Schnittstelle 512, die auf der DIN-Vorrichtung 108 angezeigt wird und fragt, ob der DIN 104 einen Softkey für das Fahrzeug 106 generieren möchte. Der DIN 104 kann eine Schaltfläche 514 zum Generieren eines Softkeys auswählen und der Softkey-Manager 158 (1) generiert den Softkey. Andernfalls kann der DIN 104 eine Abbruchschaltfläche 516 auswählen, um das Generieren des Softkeys abzubrechen. 5C veranschaulicht eine beispielhafte Schnittstelle 518, die auf der DIN-Vorrichtung 108 angezeigt wird und den Fortschritt des Generierens des Softkeys zeigt. 5D veranschaulicht eine beispielhafte Schnittstelle 520, die auf der DIN-Vorrichtung 108 angezeigt wird und angibt, dass der Softkey generiert wurde (z. B. aktiv ist) und einen Countdown bis zum Verfall des Softkeys zeigt.
  • Wie zuvor erwähnt, schließt der Softkey in einigen Beispielen eine Einschränkung hinsichtlich der Nähe ein, die es erforderlich macht, dass sich der ODC 110 in der Nähe oder innerhalb eines vordefinierten Abstands oder einer vordefinierten Reichweite zu dem Fahrzeug 106 aufhält, bevor der Softkey gesendet wird. In einigen Beispielen wird die Nähe von dem DIN 104, z. B. während der Anfrage, definiert. In anderen Beispielen kann eine Standardnähe (z. B. 50 Fuß (= ca. 15 Meter)) verwendet werden. Die Navigations-/Positionsüberwachungsvorrichtung 154 überwacht die Position der ODC-Vorrichtung 112, die von dem ODC 110 getragen wird. Wenn detektiert wird, dass sich die ODC-Vorrichtung 112 in der Nähe des Fahrzeugs 106 befindet, überträgt der Softkey-Manager 158 den Softkey zu der ODC-Vorrichtung 112. Zusätzlich oder alternativ schließt der Softkey in einigen Beispielen eine Ablaufzeit (z. B. eine zeitliche Einschränkung) ein. Zum Beispiel verfällt der Softkey und wird nicht zu der ODC-Vorrichtung 112 gesendet, wenn der ODC 110 nicht innerhalb eines vorher festgelegten Zeitraums bei dem Fahrzeug 106 (z. B. in der Nähe) ankommt. Anders ausgedrückt, überträgt der Softkey-Manager 158, wenn die Ablaufzeit vor der Übertragung des Softkeys überschritten wurde, den Softkey nicht zu der ODC-Vorrichtung 112. In einigen Beispielen wird der Softkey automatisch zu der ODC-Vorrichtung 112 gesendet, nachdem die Vereinbarung erreicht wurde. In einigen derartigen Beispielen verfällt der Softkey und kann nicht von der ODC-Vorrichtung 112 zu dem Fahrzeug 106 gesendet werden, wenn der Softkey nicht innerhalb einer zeitlichen Einschränkung verwendet wird, oder der Softkey kann gesendet werden, wird jedoch von dem Fahrzeug 106 abgelehnt.
  • Unter der Annahme, dass der ODC 110 innerhalb der zeitlichen Einschränkung und/oder innerhalb der Einschränkung hinsichtlich der Nähe bei dem Fahrzeug 106 ankommt, überträgt der Softkey-Manager 158 den Softkey zu der ODC-Vorrichtung 112, wodurch die ODC-Vorrichtung 112 die Türen des Fahrzeugs 106 entriegeln kann. 7 veranschaulicht eine beispielhafte Schnittstelle 700, die auf der ODC-Vorrichtung 112 angezeigt wird. Die Schnittstelle 700 zeigt an, dass sich der ODC 110 innerhalb der Einschränkung hinsichtlich der Nähe zu dem Fahrzeug 106 aufhält und fragt an, ob der ODC 110 die Türen des Fahrzeugs 106 entriegeln möchte. Der ODC 110 kann eine Schaltfläche 702 zum Entriegeln (z. B. „Türen jetzt entriegeln“) auswählen, was dazu führt, dass die ODC-Vorrichtung 112 den Softkey zu dem Fahrzeug 106 übertragt, um die Türen zu entriegeln. Wie hierin offenbart, schließt die ODC-Vorrichtung 112 einen drahtlosen Sendeempfänger ein, der mit dem drahtlosen Sendeempfänger 138 des Fahrzeugs 106 kommuniziert. Das Fahrzeug 106 empfängt den Softkey (z. B. über den drahtlosen Sendeempfänger 138) und das BCM 120 entriegelt die Türen des Fahrzeugs 106 (z. B. wenn der Softkey die richtigen Berechtigungsnachweise einschließt). Andernfalls kann der ODC 110 eine Verzögerungsschaltfläche 704 (z. B. „In 5 min erneut fragen“) auswählen, um die Übertragung des Softkeys zu verzögern. In einigen Beispielen überträgt die ODC-Vorrichtung 112, anstatt zu fragen, wann der Softkey übertragen werden soll, automatisch den Softkey zu dem Fahrzeug 106, um die Türen zu entriegeln, wenn die ODC-Vorrichtung 112 den Softkey empfängt. In einigen Beispielen ermöglicht der Softkey außerdem, dass der ODC 110 das Fahrzeug starten kann. In einigen Beispielen bestätigt das ODC-System 102 die Anfragekriterien (z. B. wie von dem DIN 104 während der Anfrage eingestellt), bevor es dem ODC 110 erlaubt wird, das Fahrzeug 106 zu starten. Zum Beispiel überprüft das ODC-System 102 (z. B. über die Navigations-/Positionsüberwachungsvorrichtung 154), wenn der DIN 104 das Fahrzeug 106 begleiten soll, ob sich der DIN 104 in dem Fahrzeug 106 befindet. In anderen Beispielen generiert der Softkey-Manager 158 einen separaten Softkey, um zu erlauben, dass die ODC-Vorrichtung 112 das Fahrzeug 106 starten kann.
  • In einigen Beispielen schließt der Softkey eine Anweisung ein, um die Verwendung von einem oder mehreren Merkmalen in dem Fahrzeug 106 zu beschränken (z. B. deaktivieren). Zum Beispiel kann der Softkey die Verwendung des Radios, der Temperatureinstellungen, des Internets und/oder eines beliebigen anderen Merkmals deaktivieren, für das der DIN 104 eine Einschränkung wünscht. Folglich kann der ODC 110 das bzw. die eingeschränkten Merkmal(e) beim Fahren des Fahrzeugs 106 nicht aktivieren oder verwenden. Zusätzlich oder alternativ kann die Fahrzeugschnittstelle 156 eine Anweisung zu dem Fahrzeug 106 übertragen, um die Verwendung von einem oder mehreren Merkmalen einzuschränken. In einigen Beispielen definiert der DIN 104 zum Beispiel beim Erstellen der Anfragekriterien, für welche(s) Merkmal(e) er/sie eine Deaktivierung wünscht.
  • In einigen Beispielen, wie etwa in dem Szenario, in dem der DIN 104 das Fahrzeug 106 begleiten soll, kann ein doppelter Softkey erforderlich sein, um die Türen des Fahrzeugs 106 zu entriegeln und/oder das Fahrzeug 106 zu starten. Der doppelte Softkey macht einen ersten Softkey von der ODC-Vorrichtung 112 und einen zweiten Softkey von der DIN-Vorrichtung 108 erforderlich. Der erste Softkey und der zweite Softkey sind erforderlich, um das Fahrzeug 106 zu entriegeln und/oder zu starten. In einigen Beispielen wird es dem DIN 104 durch einen doppelten Softkey ermöglicht, eine endgültige Entscheidung darüber zu treffen, ob mit dem ODC-Service fortgefahren werden soll, nachdem er den ODC 110 am Fahrzeug 106 getroffen hat. Wenn der DIN 104 zum Beispiel den ODC 110 am Fahrzeug 106 trifft und sich mit dem ODC-Service unwohl fühlt (z. B. da der ODC 110 nicht fahrtüchtig zu sein scheint), kann der DIN 104 den doppelten Softkey ablehnen, wodurch der ODC 110 daran gehindert wird, auf das Fahrzeug 106 zuzugreifen. In einigen Beispielen wird die Option zum Umsetzen eines doppelten Softkeys während der Anfrage von dem DIN 104 definiert. Ähnlich dem ersten Softkey, der zu der ODC-Vorrichtung 112 gesendet wird, wird ein zweiter Softkey generiert und von dem Softkey-Manager 158 zu der DIN-Vorrichtung 108 übertragen. In einigen Beispielen schließt der zweite Softkey eine Einschränkung hinsichtlich der Nähe und/oder eine zeitliche Einschränkung ein. In anderen Beispielen wird der zweite Softkey automatisch zu der DIN-Vorrichtung 108 übertragen, nachdem die Vereinbarung erreicht wurde. In weiteren Beispielen kann der zweite Softkey zuvor in der DIN-Vorrichtung 108 gespeichert oder in diese eingebettet werden. Die DIN-Vorrichtung 108 kann eine Schnittstelle anzeigen, die der Schnittstelle 700 ähnelt und fragt, ob der DIN 104 die Türen des Fahrzeugs 106 entriegeln möchte, wobei der zweite Softkey zu diesem Zeitpunkt zu dem Fahrzeug 106 übertragen wird.
  • Sobald sich der ODC 110 (und/oder der DIN 104) in dem Fahrzeug 106 befindet und das Fahrzeug 106 gestartet wurde, bestimmt die Navigations-/Positionsüberwachungsvorrichtung 154 eine Navigationsroute für das Fahrzeug 106 und überträgt die Route zu der ODC-Vorrichtung 112 und/oder dem Fahrzeug 106, damit sie auf der Anzeige 126 und/oder dem HUD 134 angezeigt werden kann. In einigen Beispielen wird die Route über die Audioausgabe 130 übertragen. Von daher kann der ODC 110 die vorgeschlagene Route einhalten, um das Fahrzeug 106 zu der Fahrzeugabstellposition zu überführen. Während der ODC 110 das Fahrzeug 106 zu der Fahrzeugabstellposition fährt, verfolgt die Navigations-/Positionsüberwachungsvorrichtung 154 die Position des Fahrzeugs 106 (z. B. über das GNSS 136 in dem Fahrzeug 106 und/oder das GNSS in der ODC-Vorrichtung 112). In einigen Beispielen überträgt das ODC-System 102 die Position des Fahrzeugs 106 zum Anzeigen zu der DIN-Vorrichtung 108, sodass der DIN 104 die Position des Fahrzeugs 106 im Verlauf des ODC-Services überwachen kann.
  • In einigen Beispielen kommuniziert die Fahrzeugschnittstelle 156, sobald der ODC 110 das Fahrzeug 106 gestartet hat, mit dem Fahrzeug 106 und bestimmt, ob das Fahrzeug 106 über ausreichend Kraftstoff oder Ladung verfügt, um die Fahrzeugabstellposition zu erreichen. Wenn das Fahrzeug 106 nicht über ausreichend Kraftstoff oder Ladung verfügt, bestimmt die Navigations-/Positionsüberwachungsvorrichtung 154 eine alternative Route, um den ODC 110 zu einer Tankstelle oder einer Ladestation zu leiten. Die Auswahl einer Tankstelle oder Ladestation kann auf einer Branchenzugehörigkeit, einer Preisoptimierung, einer Distanz (z. B. die nächste Tankstelle) usw. basieren. Der ODC 110 ist dann dazu in der Lage, das Fahrzeug 106 aufzutanken oder aufzuladen und zu der Fahrzeugabstellposition fortzufahren. Die Zahlung kann zum Beispiel durch eine Anwendung in der ODC-Vorrichtung 112 oder durch das Fahrzeug 106 (z. B. über den drahtlosen Sendeempfänger 138) erfolgen. In anderen Beispielen kann der ODC 110 für das Auftanken/Aufladen bezahlen und die Kosten zu einem späteren Zeitpunkt erstattet bekommen.
  • Im Allgemeinen wird erwartet, dass der ODC 110 der angewiesenen Route, wie von der Navigations-/Positionsüberwachungsvorrichtung 154 bereitgestellt, folgt. Die Navigations-/Positionsüberwachungsvorrichtung 154 überwacht das Fahrzeug 106, während das Fahrzeug 106 fährt, um zu bestimmen, ob der ODC 110 von der angewiesenen Route (z. B. der Navigationsroute) abweicht. In einigen Beispielen verfolgt die Navigations-/Positionsüberwachungsvorrichtung 154 die Position, um zu bestimmen, ob sich das Fahrzeug 106 außerhalb eines Korridors der angewiesenen Route oder darüber hinaus bewegt. Der Korridor ist ein vordefinierter Radius oder eine vordefinierte Distanz, in dem bzw. der der ODC 110 von der angewiesenen Route abweichen kann. In einigen Beispielen ist der Korridor relativ strikt und macht es erforderlich, dass der ODC 110 auf einer spezifischen Route ohne jedwede Abweichung navigiert. In anderen Beispielen kann der Korridor breiter sein, sodass der ODC 110 von der Route um eine vordefinierte Distanz oder einen vordefinierten Radius (z. B. zwei Blocks) abweichen kann. In einigen Beispielen wird der Korridor (z. B. der vordefinierte Radius) von dem DIN 104 (z. B. über die Anfragekriterien) definiert. In einigen Beispielen kann der DIN 104 den Korridor auf Grundlage einer Bewertung des ODC 110 definieren. Zum Beispiel kann für einen ODC mit einer hohen Bewertung ein breiterer Korridor erlaubt sein als für einen ODC mit einer niedrigeren Bewertung.
  • Wenn detektiert wird, dass sich das Fahrzeug 106 außerhalb des Korridors der Route bewegt, überträgt eine Warnvorrichtung 160 des ODC-Systems 102 eine Warnung oder Mitteilung zu der ODC-Vorrichtung 112 und/oder dem Fahrzeug 106. In anderen Beispielen wird der Korridor der Route zu dem Fahrzeug 106 heruntergeladen und das Fahrzeug 106 warnt den ODC 110 automatisch. Mit der Warnung wird der ODC 110 benachrichtigt, dass er/sie von der beabsichtigten Route abgewichen ist und der ODC 110 wird angewiesen, wieder zu der Route zurückzukehren. 8 veranschaulicht eine beispielhafte Warnung 800, die auf dem HUD 134 des Kombiinstruments 132 angezeigt wird. In anderen Beispielen kann die Warnung 800 auf der Anzeige 126 angezeigt werden. In dem veranschaulichten Beispiel schließt die Warnung 800 einen Fortschrittsmesser 802 ein und zeigt an, dass, wenn der ODC 110 weiterhin von der Route abweicht, der DIN 104 und/oder eine Behörde (z. B. die Ortspolizei) benachrichtigt wird bzw. werden. Wenn nicht detektiert wird, dass sich das Fahrzeug 106 innerhalb des Zeitraums in dem Korridor der Route befindet, überträgt die Warnvorrichtung 160 eine Benachrichtigung zu der DIN 104 und/oder kontaktiert die Behörden. In einigen Beispielen kann der DIN 104 während des Anfrageprozesses spezifizieren, ob die Behörden im Falle einer Abweichung benachrichtigt werden sollen oder nicht. In dem veranschaulichten Beispiel schließt die Warnung 800 eine Option 804 zum Kontaktieren des Eigentümers ein, wodurch es dem ODC 110 ermöglicht wird, den DIN 104 zu kontaktieren (z. B. über ein Telefon, das mit dem Fahrzeug 106 oder der ODC-Vorrichtung 112 verknüpft ist). Der ODC 110 kann den DIN 104 kontaktieren, um zu erklären, warum er/sie von der Route abgewichen ist.
  • Wenn der ODC 110 das Fahrzeug 106 ohne den DIN 104 fährt, kann das ODC-System 102 den DIN 104 (über die DIN-Vorrichtung 108) benachrichtigen, dass der ODC 110 von der angewiesenen Route abgewichen ist. 9 veranschaulicht eine beispielhafte Schnittstelle 900, die auf der DIN-Vorrichtung 108 angezeigt wird, um den DIN 104 zu warnen, dass das Fahrzeug 106 von der angewiesenen Route abgewichen ist. In dem veranschaulichten Beispiel schließt die Schnittstelle 900 eine Karte 902 ein, welche die aktuelle Position des Fahrzeugs 106 und die angewiesene Route zeigt. Die Schnittstelle 900 stattet den DIN 104 mit einer Schaltfläche 904 zum Kontaktieren der Behörden (z. B. die Polizei, das ODC-System 102 usw.) und einer Option 906 zum Deaktivieren des Fahrzeugs aus. Wenn der DIN 104 auswählt, die Behörden zu benachrichtigen, kontaktiert die Warnvorrichtung 160 die Behörden. Wenn der DIN 104 auswählt, das Fahrzeug zu deaktivieren, überträgt die Fahrzeugschnittstelle 156 eine Anweisung zu dem Fahrzeug 106, um den Motor abzuschalten, was von dem BCM 120 und der PCU 122 umgesetzt werden kann. In dem veranschaulichten Beispiel stattet die Schnittstelle 900 den DIN außerdem mit einer Option 908 zum Kontaktieren des ODC 110 (z. B. über einen Anruf oder eine Textnachricht) aus, sodass der DIN 104 den Grund für das Abweichen von der Route erfragen kann. In einigen Situationen kann eine Abweichung von der angewiesenen Route gerechtfertigt sein, wie etwa bei starkem Verkehr, einer Straßensperrung, einem Notfall usw. Die Schnittstelle 900 schließt eine Option 910 zum Benachrichtigen der Behörden ein, wie etwa wenn die Abweichung autorisiert oder von dem DIN 104 genehmigt ist. In einigen Beispielen kontaktiert die Warnvorrichtung 160, wenn der DIN 104 nicht innerhalb eines vorher festgelegten Zeitraums (z. B. 1 Minute) auf die Schnittfläche 900 reagiert, automatisch die Behörden und/oder deaktiviert das Fahrzeug 106.
  • Wie zuvor erwähnt, bewegt sich der DIN 104 in einigen Szenarien mit dem Fahrzeug 106. Wenn detektiert wird, dass das Fahrzeug 106 von der beabsichtigten Route abweicht und sich der DIN 104 in dem Fahrzeug 106 befindet, sendet das ODC-System 102 eine Nachricht zu dem DIN 104, um anzufragen, ob der DIN 104 in Sicherheit ist. 10 veranschaulicht eine beispielhafte Schnittstelle 1000, die auf der DIN-Vorrichtung 108 angezeigt wird. Die Schnittstelle 1000 warnt den DIN 104, dass das Fahrzeug von der genehmigten Route abgewichen ist und fragt an, ob der DIN 104 die Behörden benachrichtigen möchte oder nicht. Die Schnittstelle 1000 schließt eine Option 1002 zum Benachrichtigen der Behörden, ähnlich der Schaltfläche 904 in 9, und eine Option 1004, um die Behörden nicht zu benachrichtigen, ähnlich der Option 910 aus 9, ein. In einigen Beispielen kontaktiert die Warnvorrichtung 160, wenn der DIN 104 nicht innerhalb eines vorher festgelegten Zeitraums (z. B. 1 Minute) auf die Schnittfläche 1000 reagiert, automatisch die Behörden. In einigen Beispielen kann der DIN 104 eine Standardeinstellung zum Kontaktieren der Behörden definieren, für den Fall, dass der DIN 104 nicht antwortet oder um die Behörden in diesem Fall nicht zu kontaktieren.
  • Andernfalls schaltet der ODC 110 unter der Annahme, dass der ODC 110 und das Fahrzeug 106 an der Fahrzeugabstellposition ankommen, den Motor ab und verlässt das Fahrzeug 106. In einigen Beispielen verfällt der Softkey, sobald detektiert wird, dass sich das Fahrzeug 106 an oder in der Nähe der Fahrzeugabstellposition befindet und ermöglicht kein erneutes Einsteigen in das und/oder Wiederanlassen des Fahrzeug(s) 106. Wenn sich der DIN 104 nicht in dem Fahrzeug 106 aufhält, überträgt die Warnvorrichtung 160 eine Benachrichtigung zu der DIN-Vorrichtung 108, um den DIN 104 zu benachrichtigen, dass das Fahrzeug 106 erfolgreich abgeliefert wurde. Nachdem der ODC-Service abgeschlossen ist, kann der DIN 104 eine Bewertung für den ODC 110 abgeben, die auf dem Konto des ODC 110 in der Kontodatenbank 142 gespeichert werden kann. In einigen Beispielen werden Analysen im Anschluss an die Fahrt, die von dem Fahrzeug 106 aufgezeichnet wurden, in das ODC-System 102 für eine Einstufung/Bewertung der ODC-Erfahrung hochgeladen. In einigen Beispielen werden Informationen, wie etwa die Einhaltung der vorgeschlagenen Route, die Einhaltung von Gesetzen und/oder eine sichere Fahrweise zu der DIN-Vorrichtung 108 übertragen, sodass der DIN 104 wählen kann, ein Trinkgeld für den ODC 110 zu hinterlassen (z. B. am Ende der Fahrt oder zu einem anderen Zeitpunkt). Gleichermaßen kann der ODC 110 eine Bewertung für den DIN 104 abgeben (z. B. auf Grundlage des Zustands des Fahrzeugs, der Erfahrung mit dem DIN 104 usw.), die auf dem Konto des DIN 104 in der Kontodatenbank 142 gespeichert werden kann.
  • Das beispielhafte ODC-System 102 kann außerdem als ein präventives Tool zur Verringerung der Trunkenheit am Steuer verwendet werden. Zum Beispiel kann eine Alkohol ausschenkende Einrichtung verfügen, dass der DIN 104 eine Anfrage für einen ODC erstellt, bevor er anfängt Alkohol zu konsumieren (oder dafür einen Preisnachlass auf Getränke anbieten). Das ODC-System 102 kann den DIN 104 vom Fahren des Fahrzeugs 106 auf Grundlage einer Anzahl von Getränken ausschließen, die der DIN 104 innerhalb eines gegebenen Zeitfensters konsumiert hat (z. B. wie von der Einrichtung gezählt). In einigen Beispielen kann die Einrichtung, sobald der DIN 104 bezahlt oder seine/ihre Rechnung begleicht, die Anzahl von Getränken über einen Computer oder eine andere elektronische Vorrichtung zu dem ODC-System 102 übertragen oder kann die Anzahl von Getränken über die DIN-Vorrichtung 108 übertragen. Zusätzlich oder alternativ kann es erforderlich sein, dass der DIN 104 einen Alkoholtest durchführt. Wenn ermittelt wird, dass der DIN 104 innerhalb des Zeitfensters zu viel getrunken hat, aktiviert das ODC-System 102 automatisch die Anfrage und vereinfacht einen ODC-Service für den DIN 104.
  • Obwohl in 2–7, 9 und 10 beispielhafte Schnittstellen veranschaulicht werden, versteht es sich, dass (eine) andere Schnittstelle(n) umgesetzt werden kann bzw. können, um die hierin offenbarten Beispiele auszuführen. Zusätzlich können mehr oder weniger Informationen und Grafiken auf den Schnittstellen bereitgestellt und/oder anders angeordnet werden. In dem veranschaulichten Beispiel aus 1 ist das ODC-System 102 ein Server, der ein Programm ausführt, das mit dem Netzwerk 114 kommuniziert. Jedoch wird das ODC-System 102 in anderen Beispielen in der DIN-Vorrichtung 108 und/oder dem Fahrzeug 106 umgesetzt oder darin eingebunden.
  • Obwohl eine beispielhafte Art und Weise zur Umsetzung des ODC-Systems 102 in 1 veranschaulicht wird, können einer/eine/eines oder mehrere der Elemente, Prozesse und/oder Vorrichtungen, die in 1 veranschaulicht werden, kombiniert, getrennt, neu angeordnet, weggelassen, beseitigt und/oder auf eine beliebige andere Weise umgesetzt werden. Ferner können die beispielhafte Kontodatenbank 142, der beispielhafte Anfrage-Parser 144, der beispielhafte Angebotszusammensteller 146, das beispielhafte Bestätigungsmodul 148, die beispielhafte Vereinbarungsdatenbank 150, der beispielhafte Zahlungsprozessor 152, die beispielhafte Navigations-/Positionsüberwachungsvorrichtung 154, die beispielhafte Fahrzeugschnittstelle 156, der beispielhafte Softkey-Manager 158, die beispielhafte Warnvorrichtung 160 und/oder allgemeiner das beispielhafte ODC-System 102 aus 1 durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware umgesetzt werden. Demnach können zum Beispiel beliebige der beispielhaften Kontodatenbank 142, des beispielhaften Anfrage-Parsers 144, des beispielhaften Angebotszusammenstellers 146, des beispielhaften Bestätigungsmoduls 148, der beispielhaften Vereinbarungsdatenbank 150, des beispielhaften Zahlungsprozessors 152, der beispielhaften Navigations-/Positionsüberwachungsvorrichtung 154, der beispielhaften Fahrzeugschnittstelle 156, des beispielhaften Softkey-Managers 158, der beispielhaften Warnvorrichtung 160 und/oder allgemeiner des beispielhaften ODC-Systems 102 aus 1 durch Folgendes umgesetzt werden: eine(n) oder mehrere analoge oder digitale Schaltung(en), Logikschaltungen, programmierbare(n) Prozessor(en), anwendungsspezifische integrierte Schaltung(en) (ASIC(s)), programmierbare Logikvorrichtung(en) (PLD(s)) und/oder feldprogrammierbare Logikvorrichtung(en) (FPLD(s)). Wenn beliebige der Geräte- oder Systemansprüche dieses Patents so verstanden werden, dass sie eine reine Software- und/oder Firmwareumsetzung abdecken, wird mindestens eines der beispielhaften Kontodatenbank 142, des beispielhaften Anfrage-Parsers 144, des beispielhaften Angebotszusammenstellers 146, des beispielhaften Bestätigungsmoduls 148, der beispielhaften Vereinbarungsdatenbank 150, des beispielhaften Zahlungsprozessors 152, der beispielhaften Navigations-/Positionsüberwachungsvorrichtung 154, der beispielhaften Fahrzeugschnittstelle 156, des beispielhaften Softkey-Managers 158 und/oder der beispielhaften Warnvorrichtung 160 hiermit ausdrücklich so definiert, dass es eine greifbare computerlesbare Speichervorrichtung oder Speicherplatte, wie etwa einen Speicher, eine Digital Versatile Disk (DVD), eine Compact Disk (CD), eine Blu-Ray Disk usw. einschließt, worauf die Software und/oder Firmware gespeichert ist bzw. sind. Darüber hinaus kann das beispielhafte ODC-System 102 aus 1 einen/eine/ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu den in 1 veranschaulichten oder anstelle davon einschließen und/oder kann mehr als eines von beliebigen oder allen der veranschaulichten Elemente, Prozesse und Vorrichtungen einschließen.
  • Ablaufdiagramme, die für Beispielverfahren zur Umsetzung des ODC-Systems 102 aus 1 repräsentativ sind, werden in 11–14 gezeigt. In diesen Beispielen können die Verfahren durch maschinenlesbare Anweisungen umgesetzt werden, die ein Programm zur Ausführung durch einen Prozessor, wie etwa den Prozessor 1512, umfassen, der in der beispielhaften Prozessorplattform 1500 gezeigt wird, die nachfolgend in Verbindung mit 15 erörtert wird. Das Programm kann in Software ausgeführt werden, die auf einem greifbaren computerlesbaren Speichermedium, wie etwa einer CD-ROM, einer Diskette, einer Festplatte, einer Digital Versatile Disk (DVD), einer Blu-Ray Disk oder einem Speicher gespeichert ist, der mit dem Prozessor 1512 verknüpft ist, das gesamte Programm und/oder Teile davon kann bzw. können jedoch alternativ von einer Vorrichtung ausgeführt werden, die nicht der Prozessor 1512 ist und/oder in Firmware oder dedizierter Hardware ausgeführt werden. Ferner können, obwohl die beispielhaften Verfahren in Bezug auf die Ablaufdiagramme beschrieben werden, die in 11–14 veranschaulicht werden, viele andere Verfahren zur Umsetzung des beispielhaften Systems 102 alternativ verwendet werden. Zum Beispiel kann die Reihenfolge der Ausführung der Blöcke geändert werden, und/oder einige der beschriebenen Blöcke können verändert, beseitigt oder kombiniert werden.
  • Wie zuvor erwähnt, können die beispielhaften Verfahren aus 11–14 unter Verwendung codierter Anweisungen (z. B. computer- und/oder maschinenlesbarer Anweisungen) umgesetzt werden, die auf einem greifbaren computerlesbaren Speichermedium, wie etwa einem Festplattenlaufwerk, einem Flash-Speicher, einem Read-Only Memory (ROM), einer Compact Disk (CD), einer Digital Versatile Disk (DVD), einem Cache, einem Random-Access Memory (RAM) und/oder einer beliebigen anderen Speichervorrichtung oder Speicherplatte gespeichert sind, worauf Informationen für eine beliebige Dauer (z. B. für längere Zeiträume, dauerhaft, kurz, für ein temporäres Puffern und/oder zum Cachen der Informationen) gespeichert sind. Wie hierin verwendet, ist der Begriff greifbares computerlesbares Speichermedium ausdrücklich so definiert, dass er einen beliebigen Typ einer computerlesbaren Speichervorrichtung und/oder Speicherplatte einschließt und das Verbreiten von Signalen und Übertragungsmedien ausschließt. Wie hierin verwendet, werden „greifbares computerlesbares Speichermedium“ und „greifbares maschinenlesbares Speichermedium“ synonym verwendet. Zusätzlich oder alternativ können die beispielhaften Verfahren aus 11–14 unter Verwendung codierter Anweisungen (z. B. computer- und/oder maschinenlesbarer Anweisungen) umgesetzt werden, die auf einem nicht-transitorischen computer- und/oder maschinenlesbaren Medium, wie etwa einem Festplattenlaufwerk, einem Flash-Speicher, einem Read-Only Memory, einer Compact Disk, einer Digital Versatile Disk, einem Cache, einem Random-Access Memory und/oder einer beliebigen anderen Speichervorrichtung oder Speicherplatte gespeichert sind, worauf Informationen für eine beliebige Dauer (z. B. für längere Zeiträume, dauerhaft, kurz, für ein temporäres Puffern und/oder zum Cachen der Informationen) gespeichert sind. Wie hierin verwendet, ist der Begriff nicht-transitorisches computerlesbares Medium ausdrücklich so definiert, dass er einen beliebigen Typ einer computerlesbaren Speichervorrichtung und/oder Speicherplatte einschließt und das Verbreiten von Signalen und Übertragungsmedien ausschließt. Wie hierin verwendet, ist die Wendung „mindestens/zumindest“, wenn sie in einem Oberbegriff eines Anspruchs als der Überleitungsbegriff verwendet wird, auf die gleiche Weise offen wie der Begriff „umfassend“ offen ist.
  • 11 ist ein Ablaufdiagramm, das ein Beispielverfahren 1100 veranschaulicht, das von dem beispielhaften ODC-System 102 aus 1 umgesetzt wird, um einen ODC-Service zwischen einem DIN und einem ODC zu arrangieren. Zum Zwecke der Erörterung wird das Beispielverfahren 1100 in Verbindung mit einem ODC-Service zwischen dem DIN 104 und dem ODC 110 aus 1 beschrieben. Bei Block 1102 empfängt das ODC-System 102 eine Anfrage von dem DIN 104 für einen ODC-Service. Die Anfrage schließt ein(en) oder mehrere Kriterien oder Parameter ein. In einigen Beispielen schließen die Anfragekriterien die Identifizierung der Fahrzeugabholposition und -abstellposition, beliebige zeitliche Einschränkungen (z. B. innerhalb der nächsten 20 Minuten) und ob der DIN 104 während des ODC-Services anwesend sein wird, ein. In einigen Beispielen können andere Kriterien oder Parameter bereitgestellt werden, wie etwa ein Zeitraum für die Anfragedauer, identifizierbare Eigenschaften des Fahrzeugs, ein bevorzugtes Geschlecht des ODC, eine minimale Bewertungsrate des ODC, ein flexibler Modus für die Zeitplanung, eine Obergrenze für den Mindestpreis und/oder eine Geofence-Nähe zu dem Fahrzeug 106. Die Anfrage kann über die Schnittstelle 200 erstellt werden, wie zum Beispiel in 2 veranschaulicht.
  • Bei Block 1104 analysiert der Anfrage-Parser 144 des ODC-Systems 102 die Anfrage und die Anfragekriterien und überträgt die Anfrage auf Grundlage der Anfragekriterien zu einer oder mehreren ODC-Vorrichtungen. Zum Beispiel kann der Anfrage-Parser 144 die Anfrage nur zu ODC-Vorrichtungen senden, für die detektiert wird, dass sie sich innerhalb eines vordefinierten Radius zu der Fahrzeugabholposition befinden und dazu in der Lage sind, den ODC-Service innerhalb der spezifischen Zeitparameter abzuschließen. Andere Kriterien, wie etwa ein bevorzugtes Geschlecht des ODC, eine ODC-Bewertung usw. können ebenso verwendet werden, um geeignete ODCs für den angeforderten ODC-Service auszuwählen. Die potenziellen ODCs können die Anfrage empfangen und betrachten. Wenn ein ODC, wie etwa der ODC 110, den ODC-Service ausführen möchte, gibt der ODC 110 ein Angebot ein und schickt das Angebot zu dem ODC-System 102. Der ODC 110 kann zum Beispiel die Schnittstelle 300 aus 3 verwenden, um eine Anfrage anzunehmen und die beispielhafte Schnittstelle 400 aus 4, um das Angebot einzugeben und abzuschicken.
  • Bei Block 1106 empfängt und analysiert der Angebotszusammensteller 146 das bzw. die Angebot(e) von dem einen oder den mehreren ODCs. Der Angebotszusammensteller 146 trägt die Angebote zusammen und überträgt die Angebote zusammen mit bestimmten Informationen zu der DIN-Vorrichtung 108. Die zusätzlichen Informationen können den Abstand des ODC zum Fahrzeug, ein Bild des ODC, die ODC-Bewertung usw. einschließen. Die Informationen in Bezug auf den ODC 110 werden in der Kontodatenbank 142 gespeichert. Der DIN 104 betrachtet das bzw. die Angebot(e) auf der DIN-Vorrichtung 108 und wählt einen der ODCs aus. Die Schnittstelle 500 (5A) ist eine beispielhafte Schnittstelle, die mehrere Angebote zeigt, aus denen der DIN 104 auswählen kann. Der DIN 104 wählt eines der Angebote aus und die Auswahl wird zu dem ODC-System 102 gesendet. Bei Block 1108 empfängt das Bestätigungsmodul 148 die Angebotsauswahl von der DIN-Vorrichtung 108 und sendet eine abschließende Bestätigung zu der ODC-Vorrichtung 112, welche die Vorrichtung ist, die mit dem ausgewählten Angebot verknüpft ist.
  • Bei Block 1110 wartet das Bestätigungsmodul 148 darauf, eine abschließende Bestätigung von der ODC-Vorrichtung 112 zu empfangen. Wenn das Bestätigungsmodul 148 eine abschließende Bestätigung von der ODC-Vorrichtung 112 empfängt, bestimmt das Bestätigungsmodul 148, ob die Anfrage verfallen ist (Block 1112). Wie zuvor erwähnt, kann die Anfrage in einigen Beispielen eine Grenze für die Ablaufzeit einschließen und wenn nicht beide Parteien innerhalb der Grenze für die Ablaufzeit den ODC-Service vereinbart haben, verfällt die Anfrage. Wenn die Anfrage noch nicht verfallen ist, bringt das Bestätigungsmodul 148 bei Block 1114 die ODC-Dienstleistungsvereinbarung (zwischen dem DIN 104 und dem ODC 110) zum Abschluss und speichert die Vereinbarung in der Vereinbarungsdatenbank.
  • Wenn die Anfrage verfallen ist, fordert das Bestätigungsmodul 148 bei Block 1116 eine Verlängerung von der DIN-Vorrichtung 108 an. Bei Block 1118 bestimmt das Bestätigungsmodul 148, ob der DIN 104 die Verlängerung genehmigt. Wenn die Anfrage verlängert wird, wird die ODC-Dienstleistungsvereinbarung bei Block 1114 zum Abschluss gebracht und in der Vereinbarungsdatenbank 150 gespeichert. Andernfalls endet das Beispielverfahren 1100, wenn der DIN 104 die Verlängerung nicht genehmigt. Nachdem die Vereinbarung zum Abschluss gebracht wurde, schließt der Zahlungsprozessor 152 bei Block 1120 die Transaktion ab und überträgt Geld von dem DIN 104 zu dem ODC 110 (z. B. über eine Kreditkartentransaktion). In anderen Beispielen wird die Zahlung erst nach Abschluss des ODC-Services übertragen (z. B. sobald das Fahrzeug 106 an der Fahrzeugabstellposition abgeliefert wurde).
  • 12 ist ein Ablaufdiagramm, das ein Beispielverfahren 1200 veranschaulicht, mit dem das beispielhafte ODC-System 102 aus 1 umgesetzt wird, um einen Zugriff auf ein Fahrzeug gemäß einer ODC-Dienstleistungsverfahren zu ermöglichen. Das Beispielverfahren 1200 kann durchgeführt werden, nachdem eine ODC-Vereinbarung zum Abschluss gebracht wurde, wie etwa zum Beispiel in 11 offenbart. Zum Zwecke der Erörterung wird angenommen, dass der DIN 104 und der ODC 110 einen ODC-Service vereinbart haben. Bei Block 1202 generiert der Softkey-Manager 158 des beispielhaften ODC-Systems 102 einen Softkey für das Fahrzeug 106, welcher mit der Vereinbarung verknüpft ist. In einigen Beispielen wird bzw. werden eine Einschränkung hinsichtlich der Nähe (z. B. eine Distanz oder eine Reichweite) und/oder eine zeitliche Einschränkung für den Softkey erstellt. In einigen Beispielen kann bzw. können die Einschränkung hinsichtlich der Nähe und/oder die zeitliche Einschränkung von dem DIN 104 definiert werden. Zum Beispiel kann der DIN 104 die Einschränkungen hinsichtlich der Nähe und/oder die zeitlichen Einschränkungen während der Anfrage eingeben oder spezifizieren, wie etwa auf der Schnittstelle 200 in 2. In anderen Beispielen kann eine Standardnähe und/oder eine standardmäßige zeitliche Einschränkung umgesetzt werden.
  • Bei Block 1204 überwacht die Navigations-/Positionsüberwachungsvorrichtung 154 die Position der ODC-Vorrichtung 112, während sich der ODC 110 in der vereinbarten Zeit zu dem Fahrzeug 106 bewegt. Bei Block 1206 bestimmt die Navigations-/Positionsüberwachungsvorrichtung 154, ob sich die ODC-Vorrichtung 112 auf Grundlage der Position der ODC-Vorrichtung 112 und der Position des Fahrzeugs 106 in der Nähe des Fahrzeugs 106 befindet. Wenn sich die ODC-Vorrichtung 112 nicht in der Nähe befindet, verfolgt die Navigations-/Positionsüberwachungsvorrichtung 154 weiterhin die Position der ODC-Vorrichtung 112. Wenn sich die ODC-Vorrichtung 112 in der Nähe des Fahrzeugs 106 befindet, bestimmt der Softkey-Manager 158 auf Grundlage der zeitlichen Einschränkung, ob der Softkey verfallen ist (Block 1208). Wenn der Softkey nicht verfallen ist, überträgt der Softkey-Manager 158 den Softkey zu der ODC-Vorrichtung 112 (Block 1210). Sobald die ODC-Vorrichtung 112 den Softkey empfängt, kann der ODC 110 das Fahrzeug 106 entriegeln.
  • Wenn der Softkey verfallen ist, überträgt der Softkey-Manager 158 bei Block 1212 eine Nachricht zu der DIN-Vorrichtung 108, um eine Autorisierung zum Generieren eines neuen Softkeys oder Verlängern der Ablaufzeit des Softkeys anzufordern. Bei Block 1214 bestimmt der Softkey-Manager 158, ob der DIN 104 einen neuen Softkey autorisiert und/oder den ursprünglichen Softkey verlängert hat. Wenn der DIN 104 den neuen Softkey autorisiert und/oder den ursprünglichen Softkey verlängert, überträgt der Softkey-Manager 158 bei Block 1210 den Softkey zu der ODC-Vorrichtung 112. Andernfalls endet das Beispielverfahren 1200.
  • In einigen Beispielen ist ein doppelter Softkey erforderlich, um das Fahrzeug 106 zu entriegeln. Ein doppelter Softkey kann eingesetzt werden, wenn der DIN 104 das Fahrzeug 106 während des ODC-Services begleiten soll. Bei Block 1216 bestimmt der Softkey-Manager 158, ob eine Authentifizierung mit einem doppelten Softkey erforderlich ist. In einigen Beispielen wird die Notwendigkeit eines doppelten Softkeys von dem DIN 104 während des Anfrageprozesses eingestellt und mit der Vereinbarung in der Vereinbarungsdatenbank 150 gespeichert. Wenn ein doppelter Softkey erforderlich ist, überträgt der Softkey-Manager 158 einen zweiten Softkey zu der DIN-Vorrichtung 108. Der DIN 104 empfängt den zweiten Softkey und kann entscheiden, ob der zweite Softkey zu dem Fahrzeug 106 übertragen werden soll, um die Türen zu entriegeln oder nicht. In einigen Beispielen wird der zweite Softkey nach der Vereinbarung automatisch zu der DIN-Vorrichtung 108 übertragen. In einigen Beispielen kann der zweite Softkey bereits in der DIN-Vorrichtung 108 gespeichert sein und der DIN 104 kann auswählen, wann der zweite Softkey übertragen werden soll.
  • 13 ist ein Ablaufdiagramm, das ein Beispielverfahren 1300 veranschaulicht, das von dem beispielhaften ODC-System 102 aus 1 umgesetzt wird, um eine Position eines Fahrzeugs während eines ODC-Services zu überwachen. Das Beispielverfahren 1300 kann umgesetzt werden, nachdem eine Vereinbarung für einen ODC-Service bestätigt wurde (z. B. wie in 11) veranschaulicht und nachdem der ODC 110 in das Fahrzeug eingestiegen ist (z. B. wie in 12 veranschaulicht). Bei Block 1302 bestätigt die Fahrzeugschnittstelle 156 des ODC-Systems 102, dass das Fahrzeug 106 in Anwesenheit des ODC fährt. Bei Block 1304 überträgt die Navigations-/Positionsüberwachungsvorrichtung 154 eine Navigationsroute zu der ODC-Vorrichtung 112 und/oder dem Fahrzeug 106, um das Fahrzeug 106 zu der Fahrzeugabstellposition zu navigieren. Die Navigationsroute kann auf der ODC-Vorrichtung 112 angezeigt werden. Zusätzlich oder alternativ kann die Navigationsroute auf der Anzeige 126 und/oder dem HUD 134 des Fahrzeugs 106 angezeigt werden. Bei Block 1306 bestimmt die Fahrzeugschnittstelle 156, über wie viel Kraftstoff/Ladung das Fahrzeug 106 verfügt und die Navigations-/Positionsüberwachungsvorrichtung 154 bestimmt, ob das Fahrzeug 106 über ausreichend Kraftstoff/Ladung verfügt, um die Fahrzeugabstellposition zu erreichen. Wenn das Fahrzeug 106 nicht über genug Kraftstoff oder Ladung verfügt, leitet die Navigations-/Positionsüberwachungsvorrichtung 154 das Fahrzeug 106 zu einer Tankstelle oder Ladestation um (Block 1308). Eine Tankstelle oder Ladestation kann auf Grundlage einer Branchenzugehörigkeit, einer Distanz zu der nächsten Tankstelle/Ladestation usw. ausgewählt werden. In einigen Beispielen bezahlt der ODC 110 über eine Anwendung auf der ODC-Vorrichtung 112 für den Kraftstoff/die Aufladung. Nach dem Auftanken stellt die Navigations-/Positionsüberwachungsvorrichtung 154 weiterhin eine Navigationsroute für die Abstellposition bereit.
  • Bei Block 1310 überwacht die Navigations-/Positionsüberwachungsvorrichtung 154 die Position des Fahrzeugs 106. Die Position des Fahrzeugs 106 kann auf Grundlage des GNSS 136 in dem Fahrzeug 106 und/oder der Position der ODC-Vorrichtung 112 (für die angenommen wird, dass sie sich mit dem ODC 110 in dem Fahrzeug 106 befindet) ermittelt werden. In einigen Beispielen wird die Position des Fahrzeugs 106 zu der DIN-Vorrichtung 108 übertragen, sodass der DIN 104 die Position des Fahrzeugs 106 auf der DIN-Vorrichtung 108 überwachen kann. Bei Block 1312 ermittelt die Navigations-/Positionsüberwachungsvorrichtung 154, ob sich das Fahrzeug 106 innerhalb eines Korridors (z. B. einer zulässigen Reichweite) der angewiesenen Route befindet. In einigen Beispielen ist der Korridor relativ eng eingestellt, sodass die Navigations-/Positionsüberwachungsvorrichtung 154 das Fahrzeug 106 auffordert, einen bestimmten Pfad einzuhalten. In anderen Beispielen ist der Korridor relativ breit oder frei, sodass das Fahrzeug 106 von der angewiesenen Route um einen vordefinierten Radius (z. B. zwei Blocks) abweichen kann. Wenn die Navigations-/Positionsüberwachungsvorrichtung 154 ermittelt, dass das Fahrzeug 106 von dem Korridor der Route abgewichen ist, fährt das Beispielverfahren 1300 durch A mit Block 1402 in 14 (hierin ausführlicher beschrieben) fort, um den ODC 110, den DIN 104 und/oder die Behörden im Hinblick auf die Abweichung zu warnen.
  • Wenn sich das Fahrzeug 106 in dem Korridor der Route befindet, bestimmt die Navigations-/Positionsüberwachungsvorrichtung 154 auf Grundlage der Position des Fahrzeugs 106, ob das Fahrzeug 106 die Fahrzeugabstellposition (Block 1314) erreicht hat. Wenn sich das Fahrzeug 106 nicht an der Abstellposition befindet, überwacht die Navigations-/Positionsüberwachungsvorrichtung 154 weiterhin die Position des Fahrzeugs 106 (Block 1310) und ermittelt, ob sich das Fahrzeug 106 in dem Korridor der Route befindet (Block 1312). Sobald das Fahrzeug 106 die Abstellposition erreicht hat, bestätigt die Fahrzeugschnittstelle 156, dass das Fahrzeug 106 abgeschaltet wurde und die Vereinbarung ist abgeschlossen (Block 1316). In einigen Beispielen, wie zuvor erwähnt, wird die Zahlung von dem Zahlungsprozessor 152 nach Abschluss des Fahrzeugtransfers verarbeitet.
  • 14 ist ein Ablaufdiagramm, das ein Beispielverfahren 1400 veranschaulicht, das von dem beispielhaften ODC-System 102 aus 1 umgesetzt wird, um den ODC 110 und/oder den DIN 104 zu warnen, wenn das Fahrzeug von dem Korridor der Route abweicht (z. B. wie bei Block 1312 aus 13 ermittelt). Bei Block 1402 ermittelt die Warnvorrichtung 160, ob sich der DIN 104 bei dem Fahrzeug 106 befindet (d. h. das Fahrzeug 106 und den ODC 110 begleitet) oder nicht. In einigen Beispielen bestätigt die Warnvorrichtung 160 auf Grundlage der Kriterien in der Vereinbarung (z. B. in der Vereinbarungsdatenbank 150 gespeichert), ob sich der DIN 104 in dem Fahrzeug 106 befindet oder nicht. Zusätzlich oder alternativ kann die Warnvorrichtung 160 auf Grundlage der Position der DIN-Vorrichtung 108 (z. B. von dem GNSS der DIN-Vorrichtung 108) ermitteln, ob sich der DIN 104 in dem Fahrzeug 106 befindet. Wenn sich der DIN 104 nicht in dem Fahrzeug 106 befindet, überträgt die Warnvorrichtung 160 eine Warnung (z. B. eine Warnmeldung) zu der ODC-Vorrichtung 112 und/oder dem Fahrzeug 106, um den ODC 110 zu warnen, dass der ODC 110 den genehmigten Korridor verlassen hat (Block 1404). Zum Beispiel zeigt die beispielhafte Warnung 800, wie in 8 veranschaulicht, an, dass der ODC 110 die genehmigte Route verlassen hat. In einigen Beispielen wird ein Warnungsmesser gestartet (z. B. der Fortschrittsmesser 802 aus 8), welcher dem ODC 110 eine vordefinierte Zeitspanne gewährt, um zu dem Korridor der Route zurückzukehren. In einigen Beispielen erhält der ODC 110 die Option (z. B. die Option 804 aus 8), den DIN 104 zu kontaktieren (z. B. über einen Anruf oder eine Textnachricht). Der ODC 110 kann den DIN 104 kontaktieren, um zu erklären, warum er/sie von der angewiesenen Route abgewichen ist und kann um eine Autorisierung für die Abweichung bitten. Bei Block 1406 ermittelt die Navigations-/Positionsüberwachungsvorrichtung 154, ob das Fahrzeug 106 zu dem Korridor der Route zurückgekehrt ist. Wenn das Fahrzeug 106 vor Ablauf des Warnungsmessers zu der angewiesenen Route zurückkehrt, folgt das Beispielverfahren 1400 B zu Block 1310 aus 13, wo die Navigations-/Positionsüberwachungsvorrichtung 154 weiterhin die Position des Fahrzeugs 106 überwacht (Block 1310) und ermittelt, ob sich das Fahrzeug 106 in dem Korridor befindet (Block 1312).
  • Andernfalls überträgt die Warnvorrichtung 160 bei Block 1408, wenn das Fahrzeug nicht zu der angewiesenen Route zurückkehrt, eine Warnung zu der DIN-Vorrichtung 108. Eine beispielhafte Warnung wird in der beispielhaften Schnittstelle 900 aus 9 veranschaulicht. In einigen Beispielen wird mit der Warnung angefragt, ob der DIN 104 die Abweichung genehmigen oder die Behörden benachrichtigen und/oder das Fahrzeug deaktivierten möchte. Bei Block 1410 ermittelt die Warnvorrichtung 160, ob der DIN 104 das Fahrzeug 106 deaktivieren und/oder die Behörden benachrichtigen möchte. Wenn der DIN 104 sich dafür entscheidet, die Abweichung zu genehmigen, folgt das Beispielverfahren 1400 B zu Block 1310 aus 13, wo die Navigations-/Positionsüberwachungsvorrichtung 154 weiterhin die Position des Fahrzeugs 106 überwacht (Block 1310) und ermittelt, ob sich das Fahrzeug 106 in dem Korridor befindet (Block 1312). Andernfalls kontaktiert die Warnvorrichtung 160 bei Block 1412 die Behörden. Zusätzlich oder alternativ sendet die Fahrzeugschnittstelle 156 eine Anweisung zu dem Fahrzeug 106, um den Motor (z. B. über die PCU 122 aus 1) auf Grundlage einer Eingabe von der DIN-Vorrichtung 108 abzuschalten.
  • Erneut in Bezug auf Block 1402 sendet die Warnvorrichtung 160, wenn die Warnvorrichtung 160 ermittelt, dass sich der DIN in dem Fahrzeug 106 befindet, eine Warnung zu der DIN-Vorrichtung 108, um anzufragen, ob der DIN 104 in Sicherheit ist (Block 1414). Eine beispielhafte Warnung wird in 10 veranschaulicht. Bei Block 1416 bestimmt die Warnvorrichtung 160, ob der DIN 104 geantwortet hat. Wenn der DIN 104 antwortet, dass er/sie sich in Sicherheit befindet, die Navigations-/Positionsüberwachungsvorrichtung 154, folgt das Beispielverfahren 1400 B zu Block 1310 aus 13, wo die Navigations-/Positionsüberwachungsvorrichtung 154 weiterhin die Position des Fahrzeugs 106 überwacht (Block 1310) und ermittelt, ob sich das Fahrzeug 106 in dem Korridor befindet (Block 1312). Wenn der DIN 104 antwortet, dass er/sie sich nicht in Sicherheit befindet oder wenn der DIN 104 nicht innerhalb eines vorher festgelegten Zeitraums antwortet, kontaktiert oder benachrichtigt die Warnvorrichtung 160 die Behörden und/oder die Fahrzeugschnittstelle 156 sendet eine Anweisung zum Abschalten zu dem Fahrzeug 106 (Block 1412). In einigen Beispielen können Standardanweisungen von dem DIN 104 eingestellt werden, für den Fall, dass der DIN 104 nicht innerhalb des vorher festgelegten Zeitraums antwortet.
  • 15 ist ein Blockdiagramm einer beispielhaften Prozessorplattform 1500, die dazu in der Lage ist, Anweisungen auszuführen, um die Verfahren 1100, 1200, 1300, 1400 aus 11–14 und das ODC-System 102 aus 1 umzusetzen. Die Prozessorplattform 1500 kann zum Beispiel ein Server, ein Personal Computer, eine mobile Vorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet, wie etwa ein iPadTM), ein persönlicher digitaler Assistent (PDA), eine Internetanwendung, ein DVD-Player, ein CD-Player, ein digitaler Videorecorder, ein Blu-Ray-Player, eine Spielkonsole, ein Personal-Videorecorder, ein Set-Top-Box oder eine beliebige andere Art einer Rechenvorrichtung sein.
  • Die Prozessorplattform 1500 des veranschaulichten Beispiels schließt einen Prozessor 1512 ein. Der Prozessor 1512 des veranschaulichten Beispiels schließt Hardware ein, die eines oder mehrere der beispielhaften Kontodatenbank 142, des beispielhaften Anfrage-Parsers 144, des beispielhaften Angebotszusammenstellers 146, des beispielhaften Bestätigungsmoduls 148, der beispielhaften Vereinbarungsdatenbank 150, des beispielhaften Zahlungsprozessors 152, der beispielhaften Navigations-/Positionsüberwachungsvorrichtung 154, der beispielhaften Fahrzeugschnittstelle 156, des beispielhaften Softkey-Managers 158 und/oder der beispielhaften Warnvorrichtung 160 des ODC-Systems 102 aus 1 umsetzen kann. Zum Beispiel kann der Prozessor 1512 von einer bzw. einem oder mehreren integrierten Schaltungen, Logikschaltungen, Mikroprozessoren oder Steuerungen von einer beliebigen gewünschten Familie oder einem beliebigen gewünschten Hersteller umgesetzt werden.
  • Der Prozessor 1512 des veranschaulichten Beispiels schließt einen lokalen Speicher 1513 (z. B. einen Cache) ein. Der Prozessor 1512 des veranschaulichten Beispiels steht über einen Bus 1518 in Kommunikation mit einem Hauptspeicher, einschließend einen flüchtigen Speicher 1514 und einen nicht-flüchtigen Speicher 1516. Der flüchtige Speicher 1514 kann durch ein Synchronous Dynamic Random Access Memory (SDRAM), ein Dynamic Random Access Memory (DRAM), ein RAMBUS Dynamic Random Access Memory (RDRAM) und/oder eine beliebige andere Art einer Random-Access-Memory-Vorrichtung umgesetzt werden. Der nicht-flüchtige Speicher 1516 kann durch einen Flash-Speicher und/oder eine beliebige andere gewünschte Art einer Speichervorrichtung umgesetzt werden. Der Zugriff auf den Hauptspeicher 1514, 1516 wird durch eine Speichersteuerung gesteuert.
  • Die Prozessorplattform 1500 des veranschaulichten Beispiels schließt außerdem eine Schnittstellenschaltung 1520 ein. Die Schnittstellenschaltung 1520 kann durch eine beliebige Art eines Schnittstellenstandards, wie etwa eine Ethernetschnittstelle, einen Universal Serial Bus (USB) und/oder eine PCI Express Schnittstelle umgesetzt werden.
  • In dem veranschaulichten Beispiel sind eine oder mehrere Eingabevorrichtungen 1522 mit der Schnittstellenschaltung 1520 verbunden. Die Eingabevorrichtung(en) 1522 ermöglicht bzw. ermöglichen es einem Benutzer Daten und Befehle in den Prozessor 1512 einzugeben. Die Eingabevorrichtung(en) kann bzw. können zum Beispiel durch einen Audiosensor, ein Mikrophon, eine Kamera (Fotofunktion oder Video), eine Tastatur, eine Schaltfläche, eine Maus, einen Touchscreen, ein Trackpad, einen Trackball, Isopoint und/oder ein Spracherkennungssystem umgesetzt werden.
  • Eine oder mehrere Ausgabevorrichtungen 1524 sind ebenso mit der Schnittstellenschaltung 1520 des veranschaulichten Beispiels verbunden. Die Ausgabevorrichtungen 1524 können zum Beispiel durch Anzeigevorrichtungen (z. B. eine Leuchtdiode (LED), eine organische Leuchtdiode (OLED), eine Flüssigkristallanzeige, eine Kathodenstrahlröhrenanzeige (CRT), einen Touchscreen, eine taktile Ausgabevorrichtung, einen Drucker und/oder Lautsprecher) umgesetzt werden. Die Schnittstellenschaltung 1520 des veranschaulichten Beispiels schließt demnach üblicherweise eine Grafiktreiberkarte, einen Grafiktreiberchip oder einen Grafiktreiberprozessor ein.
  • Die Schnittstellenschaltung 1520 des veranschaulichten Beispiels schließt außerdem eine Kommunikationsvorrichtung, wie etwa einen Sender, einen Empfänger, einen Sendeempfänger, ein Modem und/oder eine Netzwerkschnittstellenkarte ein, um den Austausch von Daten mit externen Maschinen (z. B. Rechenvorrichtungen jeglicher Art) über ein Netzwerk 1526 (z. B. eine Ethernetverbindung, eine Digital Subscriber Line (DSL), eine Telefonleitung, ein Koaxialkabel, ein Mobiltelefonsystem usw.) zu vereinfachen.
  • Die Prozessorplattform 1500 des veranschaulichten Beispiels schließt außerdem einen oder mehrere Massenspeicher 1528 zum Speichern von Software und/oder Daten ein. Beispiele derartiger Massenspeicher 1528 schließen Diskettenlaufwerke, Festplattenlaufwerke, Compact-Disk-Laufwerke, Blu-Ray-Disk-Laufwerke, RAID-Systeme und Digital-Versatile-Disk(DVD)-Laufwerke ein.
  • Codierte Anweisungen 1532 zum Umsetzen der Verfahren 1100, 1200, 1300, 1400 aus 11–14 können in dem Massenspeicher 1528, in dem flüchtigen Speicher 1514, in dem nicht-flüchtigen Speicher 1516 und/oder einem entfernbaren greifbaren computerlesbaren Speichermedium, wie etwa einer CD oder DVD, gespeichert werden.
  • Auf Grundlage des Vorstehenden versteht es sich, dass die zuvor offenbarten Verfahren, Systeme/Geräte und Erzeugnisse die Planung und Ausführung eines ODC-Services zwischen einem DIN und einem ODC vereinfachen. Die beispielhaften hierin offenbarten ODC-Systeme ermöglichen es einem DIN ohne Weiteres und selbstbewusst einen ODC-Service zu planen, damit sein/ihr Fahrzeug mit oder ohne den DIN von einer Position zu einer anderen überführt wird. Folglich wird mit den beispielhaften ODC-Systemen die Wahrscheinlichkeit dafür verringert, dass der DIN andernfalls sein/ihr Fahrzeug fahren müsste, wenn er nicht dazu in der Lage ist, zu fahren (z. B. betrunken).
  • Ferner werden bei beispielhaften hierin offenbarten ODC-Systemen Softkeys verwendet, um zu garantieren, dass der ODC auf das Fahrzeug zugreifen und dieses starten kann, wodurch die Notwendigkeit des Zugriffs auf den physischen Schlüssel für das Fahrzeug beseitigt wird. Demnach kann ein ODC ein Fahrzeug entriegeln und starten, ohne dass der DIN anwesend ist. Beispielhafte Softkeys können ebenso verwendet werden, um den Zugriff auf bestimmte Merkmale in dem Fahrzeug (z. B. das Radio, Temperatureinstellungen usw.) einzuschränken. Ferner überwachen und verfolgen die beispielhaften ODC-Systeme das Fahrzeug während des ODC-Services und stellen zahlreiche Überprüfungen bereit, um zu gewährleisten, dass der ODC den ODC-Service gemäß der Vereinbarung ausführt.
  • Obwohl hierin bestimmte beispielhafte Verfahren, Systeme/Geräte und Erzeugnisse offenbart wurden, ist der Geltungsumfang dieses Patents nicht darauf beschränkt. Im Gegensatz dazu deckt dieses Patent alle Verfahren, Systeme/Geräte und Erzeugnisse ab, die verhältnismäßig in den Umfang der Patentansprüche dieses Patents fallen.

Claims (15)

  1. Verfahren, umfassend: mit einem On-Demand-Driver(ODD)-System, Generieren eines Softkeys für ein Fahrzeug, der mit einer Vereinbarung zwischen einem Driver-In-Need (DIN) und einem ODD verknüpft ist; mit dem ODD-System, Überwachen einer Position einer ODD-Vorrichtung, die von dem ODD getragen wird; mit dem ODD-System, Übertragen des Softkeys zu der ODD-Vorrichtung, wenn detektiert wird, dass sich die ODD-Vorrichtung in der Nähe des Fahrzeugs befindet, wobei der Softkey verwendet wird, um das Fahrzeug zu entriegeln.
  2. Verfahren nach Anspruch 1, wobei der Softkey eine Ablaufzeit einschließt.
  3. Verfahren nach Anspruch 2, wobei das ODD-System, falls die Ablaufzeit vor der Übertragung des Softkeys überschritten wurde, den Softkey nicht zu der ODD-Vorrichtung überträgt.
  4. Verfahren nach Anspruch 1, wobei der Softkey eine Anweisung einschließt, ein Merkmal in dem Fahrzeug zu deaktivieren.
  5. Verfahren nach Anspruch 1, wobei der Softkey ein erster Softkey ist, ferner einschließend: mit dem ODD-System, Generieren eines zweiten Softkeys; und mit dem ODD-System, Übertragen des zweiten Softkeys zu einer DIN-Vorrichtung, die von dem DIN getragen wird, wobei der erste Softkey und der zweite Softkey benötigt werden, um das Fahrzeug zu entriegeln.
  6. Verfahren nach Anspruch 1, ferner einschließend: mit dem ODD-System, Bestimmen einer Navigationsroute für das Fahrzeug; mit dem ODD-System, Verfolgen einer Position des Fahrzeugs; und mit dem ODD-System, auf Grundlage der Position des Fahrzeugs, Bestimmen, ob das Fahrzeug von der Navigationsroute abweicht.
  7. Verfahren nach Anspruch 6, ferner einschließend, mit dem ODD-System, das Übertragen der Navigationsroute zu mindestens einem von der ODD-Vorrichtung oder dem Fahrzeug.
  8. Verfahren nach Anspruch 6, ferner einschließend, mit dem ODD-System, das Übertragen einer Warnung zu einer DIN-Vorrichtung, die von dem DIN getragen wird, wenn das Fahrzeug von der Navigationsroute abweicht.
  9. Verfahren nach Anspruch 8, ferner einschließend, mit dem ODD-System, das Übertragen einer Anweisung zu dem Fahrzeug, um das Fahrzeug auf Grundlage einer Eingabe von der DIN-Vorrichtung zu deaktivieren.
  10. Verfahren nach Anspruch 8, ferner einschließend, mit dem ODD-System, das Benachrichtigen einer Behörde, wenn der DIN nicht innerhalb eines Zeitraums antwortet.
  11. Verfahren nach Anspruch 6, ferner einschließend, mit dem ODD-System, das Übertragen einer Warnung zu dem Fahrzeug, die über ein Kombiinstrument angezeigt werden soll, wenn das Fahrzeug von der Navigationsroute abweicht.
  12. Gerät, umfassend: eine Vereinbarungsdatenbank, um eine On-Demand-Driver(ODD)-Vereinbarung zwischen einem Driver-In-Need (DIN) und einem ODD für den Transport eines Fahrzeugs zu speichern; eine Positionsüberwachungsvorrichtung zum Verfolgen einer Position einer ODD-Vorrichtung, die von dem ODD getragen wird; und einen Softkey-Manager, um: einen Softkey zum Starten des Fahrzeugs zu generieren; und den Softkey zu der ODD-Vorrichtung zu übertragen, wenn detektiert wird, dass sich die ODD-Vorrichtung in der Nähe des Fahrzeugs befindet.
  13. Gerät nach Anspruch 12, wobei die Positionsüberwachungsvorrichtung dazu dient, um: eine angewiesene Route für das Fahrzeug zu bestimmen; und eine Position des Fahrzeugs zu überwachen, während das Fahrzeug fährt.
  14. Gerät nach Anspruch 13, ferner einschließend eine Warnvorrichtung, um eine Warnung zu dem DIN zu übertragen, wenn sich das Fahrzeug außerhalb eines Korridors der angewiesenen Route bewegt.
  15. Gerät nach Anspruch 14, wobei der Korridor der angewiesenen Route durch einen Radius definiert wird.
DE102017114586.9A 2016-06-30 2017-06-29 On-demand driver systeme und -verfahren Pending DE102017114586A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/198,930 2016-06-30
US15/198,930 US10501054B2 (en) 2016-06-30 2016-06-30 On-demand driver systems and methods

Publications (1)

Publication Number Publication Date
DE102017114586A1 true DE102017114586A1 (de) 2018-01-04

Family

ID=59523716

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017114586.9A Pending DE102017114586A1 (de) 2016-06-30 2017-06-29 On-demand driver systeme und -verfahren

Country Status (6)

Country Link
US (2) US10501054B2 (de)
CN (1) CN108297826B (de)
DE (1) DE102017114586A1 (de)
GB (1) GB2554496B (de)
MX (1) MX2017008758A (de)
RU (1) RU2741521C2 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10501054B2 (en) 2016-06-30 2019-12-10 Ford Global Technologies, Llc On-demand driver systems and methods
US10769452B2 (en) * 2016-11-14 2020-09-08 Lyft, Inc. Evaluating and presenting pick-up and drop-off locations in a situational-awareness view of an autonomous vehicle
US11293767B2 (en) * 2018-11-21 2022-04-05 International Business Machines Corporation Dynamic drop off and pick up of passengers via autonomous vehicles
US11422551B2 (en) * 2018-12-27 2022-08-23 Intel Corporation Technologies for providing a cognitive capacity test for autonomous driving
CN111422162B (zh) * 2020-02-21 2022-01-18 吉利汽车研究院（宁波）有限公司 一种基于数字钥匙的车辆启动方法、装置及终端
US11127281B1 (en) * 2020-03-19 2021-09-21 Roald Mathias Hesse Security method and application software

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060111570A (ko) * 2003-12-10 2006-10-27 마츠시타 덴끼 산교 가부시키가이샤 도난방지시스템
CN101803346A (zh) 2007-09-14 2010-08-11 罗姆股份有限公司 便携式电话
WO2009095472A2 (de) * 2008-01-31 2009-08-06 Continental Teves Ag & Co. Ohg Fahrzeugschlüssel und verfahren zur ortung eines kraftahrzeugs im nahbereich unter verwendung eines fahrzeugschlüssels
US20090216600A1 (en) 2008-02-27 2009-08-27 Montiss Llc Systems and methods for arranging a transport transaction
KR101012501B1 (ko) 2008-08-04 2011-02-08 연홍석 대리운전 서비스 시스템
KR100993636B1 (ko) 2010-03-23 2010-11-11 이경순 사용자가 대리운전 기사를 직접 선택할 수 있는 대리운전 서비스 제공 방법
KR20120077781A (ko) 2010-12-31 2012-07-10 홍구표 Ｑｒ 코드를 이용한 대리 운전 호출 시스템 및 방법
US9365188B1 (en) * 2011-04-22 2016-06-14 Angel A. Penilla Methods and systems for using cloud services to assign e-keys to access vehicles
US20140129301A1 (en) * 2012-11-07 2014-05-08 Ford Global Technologies, Llc Mobile automotive wireless communication system enabled microbusinesses
US8880239B2 (en) 2012-11-07 2014-11-04 Ford Global Technologies, Llc Credential check and authorization solution for personal vehicle rental
JP6105747B2 (ja) * 2012-12-13 2017-03-29 エルジー エレクトロニクス インコーポレイティド 経路計算方法、経路獲得方法またはこのための装置
US9184777B2 (en) 2013-02-14 2015-11-10 Ford Global Technologies, Llc Method and system for personalized dealership customer service
CN103178966B (zh) * 2013-03-19 2015-08-12 北京经纬恒润科技有限公司 车辆与智能钥匙的kpd认证方法、车辆基站及系统
WO2014146186A1 (en) 2013-03-22 2014-09-25 Keyfree Technologies Inc. Managing access to a restricted area
US9902343B2 (en) 2013-07-31 2018-02-27 Driverdo Llc Digital vehicle tag and method of integration in vehicle allocation system
CN103600719A (zh) * 2013-09-18 2014-02-26 浙江吉利控股集团有限公司 车用无钥匙进入启动系统及其使用方法
DE102013016097B4 (de) * 2013-09-27 2018-01-04 Audi Ag Verfahren zum schlüsselfreien Entriegeln einer Schließvorrichtung eines Kraftfahrzeugs
US9499125B2 (en) * 2013-10-29 2016-11-22 Volkswagen Aktiengesellschaft Vehicle system for activating a vehicle component to provide vehicle access
US9481326B2 (en) * 2013-11-06 2016-11-01 Harman International Industries, Incorporated Adapting vehicle systems based on wearable devices
KR101710317B1 (ko) * 2013-11-22 2017-02-24 퀄컴 인코포레이티드 차량 내의 다수의 모바일 컴퓨팅 디바이스들에 의해 제공된 선호도들에 기초하여 차량의 내면을 구성하기 위한 시스템 및 방법
US10002479B2 (en) * 2014-10-01 2018-06-19 Continental Intelligent Transportation Systems, LLC End to end system for service delivery to and from a vehicle using a dongle
GB201420496D0 (en) 2014-10-01 2014-12-31 Continental Intelligent Transporation Systems Llc Package delivery to and pick-up from a vehicle
US9508204B2 (en) 2014-10-01 2016-11-29 Continental Intelligent Transportation Systems, LLC Package exchange and service system using a key fob simulator
US9821768B2 (en) * 2014-10-01 2017-11-21 Continental Intelligent Transportation Systems LLC Geo-proximity vehicle alert and access system for security and package exchange efficiency
US9533653B2 (en) * 2015-05-29 2017-01-03 Denso International America, Inc. Systems and methods for delegating control of vehicle features to a wearable electronic device
US10501054B2 (en) 2016-06-30 2019-12-10 Ford Global Technologies, Llc On-demand driver systems and methods
JP6969216B2 (ja) * 2017-08-09 2021-11-24 トヨタ自動車株式会社 開錠制御システム
US11275368B2 (en) * 2019-04-01 2022-03-15 Ford Global Technologies, Llc Key fobs for vehicle remote park-assist

Also Published As

Publication number Publication date
US11198415B2 (en) 2021-12-14
GB2554496B (en) 2022-09-14
MX2017008758A (es) 2018-09-10
GB2554496A (en) 2018-04-04
GB201710267D0 (en) 2017-08-09
US10501054B2 (en) 2019-12-10
RU2017122301A3 (de) 2020-08-11
CN108297826B (zh) 2022-03-08
CN108297826A (zh) 2018-07-20
RU2017122301A (ru) 2018-12-26
US20180001870A1 (en) 2018-01-04
US20200017072A1 (en) 2020-01-16
RU2741521C2 (ru) 2021-01-26

Similar Documents

Publication Publication Date Title
DE102017114586A1 (de) On-demand driver systeme und -verfahren
DE102013222428B4 (de) Berechtigungsnachweisprüfung und Autorisierungslösung zur Personenfahrzeugvermietung
DE102011085186B4 (de) System für bedienungslosen betrieb und verfahren zum vorbereiten eines bedienungslosen betriebs eines fahrzeugs
Crane et al. A survey of legal issues arising from the deployment of autonomous and connected vehicles
DE102013222421A1 (de) Mobiles, drahtloses Automobil-Kommunikationssystem für aktivierte Kleinunternehmen
US20100131304A1 (en) Real time insurance generation
DE102013222423A1 (de) Hardware und Steuerungen zur Personenfahrzeugvermietung
DE202017102431U1 (de) Crowdsourcing-Fahrzeugeinstellungsempfehlungen
DE112012004770T5 (de) Fahrzeug-Middleware
DE102019103819A1 (de) Überwachen der versorgungsqualität am fahrzeug
DE102014114438A1 (de) Verfahren zum Bereitstellen von Kraftstoffkaufoptionen für ein Fahrzeug
DE102017114179A1 (de) Vorrichtung und Verfahren für eine Fahrzeugplattform
DE102021123067A1 (de) Sicherer Transportmittel-Datenaustausch
DE102013113617A1 (de) Betriebsverfahren für eine Einstecksicherheitsvorrichtung für die drahtlose Kommunikation
US10692149B1 (en) Event based insurance model
DE112016007451T5 (de) Verfahren und vorrichtungen zum gewerblichen betrieb persönlicher autonomer fahrzeuge
DE102018107709A1 (de) System und verfahren zum parkverstoss-risikomanagement
DE102019135012A1 (de) Auf richtlinie und token basierender autorisierungsrahmen für konnektivität
DE102020129658A1 (de) Sichere intelligente c-v2x-mauterhebung
Wagner et al. Automated vehicles: Policy implications scoping study
DE102022111037A1 (de) Verfahren und systeme zur optimierung von fahrzeugereignisprozessen
JP7379424B2 (ja) 状況固有の輸送手段パワー割り当て
DE102017107795A1 (de) Fahrzeugcomputersystem zum autorisieren von versicherungs- und zulassungsbescheinigungen
DE102021117053A1 (de) Systeme und verfahren zur schlüsselfreien fahrzeugbetriebsverwaltung
DE102020110124A1 (de) Fahrzeugkraftstoffstandanzeigesysteme und -verfahren

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: PATERIS THEOBALD ELBEL FISCHER, PATENTANWAELTE, DE

R084 Declaration of willingness to licence
R012 Request for examination validly filed