DE102020111877A1

DE102020111877A1 - Verbesserte verwendbarkeit und funktionalität von bordeigener hardware und software von fahrzeugen

Info

Publication number: DE102020111877A1
Application number: DE102020111877.5A
Authority: DE
Inventors: Jeffrey Brian Yeung; Ayush Chandrakanth Shah; Sandeep SASIDHARAN; Perry Robinson MacNeille
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2019-04-30
Filing date: 2020-04-30
Publication date: 2020-11-05
Also published as: US20200349776A1; CN111845592A; US20220277597A1

Abstract

Diese Offenbarung stellt verbesserte Verwendbarkeit und Funktionalität von bordeigener Hardware und Software von Fahrzeugen bereit. Ein Fahrzeug kann eine Anforderung zur Verwendung einer Fahrzeugressource von einer entfernten Quelle empfangen. Das Fahrzeug kann auf Grundlage eines Zustands der Ressource bestimmen, ob das Fahrzeug dazu in der Lage ist, die Anforderung zu erfüllen. Das Fahrzeug kann zudem Kosten für das Verwenden der Ressource als Reaktion darauf, dass bestimmt wird, dass das Fahrzeug dazu in der Lage ist, die Anforderung zu erfüllen, bestimmen und an die entfernte Quelle senden und die Verwendung der Ressource gemäß einer in Verbindung mit den Kosten definierten Verwendungslaufzeit als Reaktion darauf, dass eine Zustimmung von der entfernten Quelle zum Bezahlen der Kosten empfangen wird, bereitstellen.

Description

GEBIET DER TECHNIK
Die veranschaulichenden Ausführungsformen betreffen in Allgemeinen Verfahren und Einrichtungen zur verbesserten Verwendbarkeit und Funktionalität von bordeigener Hardware und Software von Fahrzeugen.
ALLGEMEINER STAND DER TECHNIK
Fahrzeuge beinhalten immer leistungsstärkere Rechensysteme. Da sie Infotainment, Telematiksysteme und eine Suite von Fahrzeugsoftwaremodulen und elektronischen Steuereinheiten (electronic control units - ECUs) an Bord mit Leistung versorgen, weisen bordeigene Fahrzeugcomputer erhebliche und häufig nicht verwendete Verarbeitungsfähigkeiten auf. Fahrzeugsensoren stellen zudem eine große Bandbreite an Daten über das Fahrzeug und die Umgebung bereit, während das Fahrzeug fährt, und diese Daten und die Sensoren, die diese Daten bereitstellen und erheben, werden erneut in vielen Szenarien häufig nicht verwendet.
KURZDARSTELLUNG
In einem ersten veranschaulichenden Beispiel beinhaltet eine mobile Vorrichtung einen Prozessor, der zum Anfordern der Verwendung einer Fahrzeugressource in Verbindung mit einer auf der mobilen Vorrichtung ausgeführten Anwendung konfiguriert ist. Der Prozessor ist zudem zum Empfangen einer Benachrichtigung über Kosten des Verwendens der Fahrzeugressource konfiguriert. Der Prozessor ist ferner zum Senden einer Zustimmung zum Bezahlen der Kosten an ein Fahrzeug, das die angeforderte Ressource beinhaltet, und zum Empfangen von Daten von der Fahrzeugressource als Reaktion auf die gesendete Zustimmung konfiguriert.
In einem zweiten veranschaulichenden Beispiel beinhaltet ein Fahrzeug einen Prozessor, der zum Empfangen einer Anforderung zur Verwendung einer Fahrzeugressource von einer entfernten Quelle konfiguriert ist. Der Prozessor ist zudem zum Bestimmen, ob das Fahrzeug dazu in der Lage ist, die Anforderung zu erfüllen, auf Grundlage eines Zustands der Ressource konfiguriert. Der Prozessor ist ferner konfiguriert zum Senden von Kosten für das Verwenden der Ressource an die entfernte Quelle als Reaktion darauf, dass bestimmt wird, dass das Fahrzeug dazu in der Lage ist, die Anforderung zu erfüllen, und Bereitstellen der Verwendung der Ressource gemäß einer in Verbindung mit den Kosten definierten Verwendungslaufzeit als Reaktion darauf, dass eine Zustimmung von der entfernten Quelle zum Bezahlen der Kosten empfangen wird.
In einem dritten veranschaulichenden Beispiel beinhaltet ein Fahrzeug einen Prozessor, der zum Bestimmen einer oder mehrerer Fahrzeugressourcen, die zur Verwendung durch eine entfernte Quelle verfügbar sind, konfiguriert ist. Der Prozessor ist zudem zum Aussenden der Verfügbarkeit der bestimmten einen oder mehreren Ressourcen konfiguriert. Der Prozessor ist ferner konfiguriert zum Empfangen einer Anforderung von einer entfernten Quelle zum Verwenden von mindestens einer der Fahrzeugressourcen und als Reaktion darauf, dass bestimmt wird, dass die mindestens eine Ressource derzeit nicht durch das Fahrzeug verwendet wird und zur Verwendung durch die entfernte Quelle verfügbar ist, Bereitstellen der Verwendung der mindestens einen Ressource im Austausch gegen eine Zahlungszustimmung von der entfernten Quelle.
Figurenliste

1 zeigt ein veranschaulichendes Datenteilungssystem;
2 zeigt ein veranschaulichendes Beispiel für einen Prozess zum bordexternen Verlagern für eine mobile Vorrichtung;
3 zeigt ein veranschaulichendes Beispiel für einen Prozess zur Anforderungserfüllung,
4 zeigt einen alternativen Prozess zum Bereitstellen von Daten an eine entfernte Entität;
und
5 zeigt einen veranschaulichenden Prozess zum Abwickeln von Anforderungen nach Bedarf.

DETAILLIERTE BESCHREIBUNG
Detaillierte Ausführungsformen werden in dieser Schrift nach Bedarf offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich der Veranschaulichung dienen und in verschiedenen und alternativen Formen umgesetzt werden können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Deshalb sind in dieser Schrift offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielseitige Umsetzung des beanspruchten Gegenstands zu lehren.
Wenn Fahrzeuge immer autonomer werden, werden bordeigene Rechen- und Sensorsuiten exponentiell leistungsfähiger, doch es wird viele Gelegenheiten geben, bei denen das Fahrzeug nicht viele der bordeigenen Sensoren nutzt und nicht viel von der bordeigenen Rechenleistung verwendet. Die veranschaulichenden Ausführungsformen erlauben es mobilen Vorrichtungen, die mit dem Fahrzeugcomputer verbunden sind, Verarbeitung bordextern auf den Fahrzeugcomputer zu verlagern, um sowohl die Verarbeitung der mobilen Vorrichtung zu beschleunigen als auch Batterielebensdauer der mobilen Vorrichtung einzusparen. Ferner können Benutzer mobiler Vorrichtungen und auch Anwendungsentwickler Fahrzeugsensordaten anfordern und verwenden, um die Funktionalität von Anwendungen zu verbessern und/oder die Qualität und Quantität von wünschenswerten Daten zu verbessern.
Indem es Fahrgästen erlaubt wird, bordeigene Verarbeitung und Daten zu verwenden, sowie einem Besitzer oder Mitfahrer eines Fahrzeugs erlaubt wird, Daten an anfordernde Anwendungen zu verkaufen, können neue Umsatzmodelle und neue Modelle für eine schnellere Verarbeitung und eine verbesserte Batterielebensdauer mobiler Vorrichtungen erreicht werden, ohne dass dabei erhebliche Hardware zu bereits vorhandenen Fahrzeugsystemen hinzugefügt wird.
1 zeigt ein veranschaulichendes Datenteilungssystem, das in Verbindung mit veranschaulichenden Ausführungsformen verwendet werden kann. In diesem Beispiel ist ein veranschaulichendes Fahrzeug 101 gezeigt, das mindestens einen bordeigenen Prozessor 103 beinhaltet. Das Fahrzeug 101 kann manuell gefahren oder autonom sein. Während autonome Fahrzeuge typischerweise eine größere Rechenleistung und Sensorfähigkeit aufweisen, weisen sie auch einen größeren Bedarf auf, diese Systeme zu verwenden, aber beide Fahrzeugtypen sind für die veranschaulichenden Ausführungsformen geeignet, da sowohl manuell gefahrene als auch autonome Fahrzeuge wahrscheinlich Gelegenheiten für geteilte Berechnung und geteilte Sensordaten aufweisen.
Das Fahrzeug 101 weist eine Telematiksteuereinheit (telematics control unit - TCU) 105 auf, die eine Verbindungsfähigkeit über Mobilfunk bereitstellt. Diese Einheit 105 erlaubt es dem Fahrzeug 101, sich mit entfernten Systemen in der Cloud 130 zu unterhalten, die in diesem Beispiel eine Datendienstanwendung 131 sowie einen oder mehrere Anwendungsserver 133, 135 beinhalten. Die Datendienstanwendung 131 kann durch einen Erstausrüster (original equipment manufacturer - OEM) verwaltet werden und das Fahrzeug über ausstehende Datenanforderungen oder Gelegenheiten zum Verkaufen von Daten an anfordernde Entitäten benachrichtigen. Zum Beispiel kann es sein, dass ein Wetter- oder Navigationsanwendungsanbieter lokalisierte Daten über Wetterbedingungen oder Straßen-/Verkehrsbedingungen an einer spezifischen Lokalität möchte. Der Anwendungsserver 133, 135 kann diese Informationen von dem Server für Datendienste 131 anfordern, der Fahrzeuge identifizieren kann, die die angemessenen Sensoren und Standorte aufweisen, die der Datenanforderung entsprechen. Der Server für Datendienste 131 kann dann diese Fahrzeuge 101 kontaktieren, um zu bestimmen, ob das Fahrzeug die angeforderten Daten erlangen und verkaufen kann und wird.
In anderen Beispielen kann der Anwendungsserver 133 direkt mit dem Fahrzeug 101 kommunizieren, da er entweder die Berechtigung dazu aufweist oder er eine Anwendung 119 unterstützt, die sich auf dem Fahrzeug befindet. Wenn der Anwendungsserver 133 kommuniziert, um eine bordeigene Anwendung 119 zu unterstützen, kann der Server 133 die Daten durch die bordeigene Anwendung 119 anfordern. Wenn keine entsprechende bordeigene Anwendung 119 vorhanden ist, kann der Server 133 die Daten direkt von einem Fahrzeug 101 anfordern.
In diesem Beispiel beinhaltet das Fahrzeug zudem Sendeempfänger für WLAN 107 und BLUETOOTH 109, die zum Kommunizieren mit einer mobilen Vorrichtung 120 in dem Fahrzeug verwendet werden können. Zusätzlich zum Bereitstellen von Kommunikationsdiensten könnte der WLAN-Sendeempfänger zum Beispiel einer anfordernden Anwendung eine Liste mit öffentlichen Hotspots bereitstellen, die durch den Sendeempfänger identifiziert werden, während das Fahrzeug fährt. Würde zum Beispiel ein Anwendungsentwickler Daten über verfügbare öffentliche Hotspots an einer Lokalität einschließen wollen, könnten ein oder mehrere Fahrzeuge 101 diese Netze detektieren und dem Entwickler Informationen über ihre Existenz bereitstellen.
Das Fahrzeug 101 beinhaltet zudem eine Mensch-Maschine-Schnittstelle (human machine interface - HMI) 111, die häufig eine berührungsempfindliche Anzeige ist. Diese Schnittstelle kann verwendet werden, um Datenanforderungen zu genehmigen sowie Einstellungen dafür zu steuern und festzulegen, welche Daten geteilt werden können, wann sie geteilt werden können, die Kosten der Daten, etwaige erforderliche Anonymität usw. Das Fahrzeug 101 beinhaltet ferner eine Vielzahl von bordeigenen Datensensoren 113. Diese können unter anderem Standort (GPS, GLONASS), Innen-/Außenkameras, Fahrdaten (Ausrichtung, zurückgelegte Strecke, Geschwindigkeit usw.), Trägheitssensoren, Magnetometer, Verschmutzungssensoren, Erfassung der Straßenqualität durch die Federung, Außengeräusche usw. beinhalten. Autonome Fahrzeuge können zudem hochwertige LIDAR-, RADAR- oder andere Sensoren beinhalten, die dazu ausgestaltet sind, die physische Umgebung eines Fahrzeugs 101 genau abzubilden, während es fährt.
Die meisten oder alle der Sensoren 113 weisen einen tatsächlichen fahrzeugseitigen Zweck auf, doch sie werden auch häufig nicht verwendet, es sei denn, ein spezifischer Grund tritt auf, der erfordert, dass das Fahrzeug 101 Daten von einem gegebenen Sensor 113 erlangt. Demnach und auch in den Fällen, in denen das Fahrzeug 101 die Daten ebenfalls benötigt, können diese Sensoren 113 genutzt werden, um zahlreichen Interessenten teilbare/verkaufbare Daten bereitzustellen. Die Sensoren 113 können eine systemeigene Abfragerate (wie oft sie Daten erheben/melden) aufweisen und können zudem angewiesen werden, mit einer Rate abzufragen, die einer gegebenen Anforderung entspricht. Sofern die Abfrage die anderweitig benötigten Rechenressourcen nicht übermäßig belastet, kann das Fahrzeug 101 die Daten von diesen Sensoren 113 ohne Weiteres erheben und teilen, während das Fahrzeug 101 fährt.
Das Fahrzeug 101 kann zudem einen Navigationscomputer 115 beinhalten. Dieser Computer kann leistungsfähiger sein als ein Computer der mobilen Vorrichtung 120 oder Zugriff auf ein Standortsignal höherer Qualität oder andere Navigationsdaten aufweisen, die für die systemeigene Navigationsfunktion einer mobilen Vorrichtung 120 nützlich sind. Darüber hinaus können Routendaten, Routenempfehlungen, Orte von Interesse und allgemeine Fahrtgewohnheiten, die alle durch das Navigationssystem 115 verfolgt werden oder verfolgt werden können, für Anwendungsentwickler von Interesse sein. Somit können die Anwendungsserver 133, 135 dazu in der Lage sein, Navigationsdaten von dem Navigationssystem 115 des Rechensystems des Fahrzeugs 101 anzufordern.
Das Fahrzeug 101 beinhaltet zudem vielfältige bordeigene Systeme 117, wie etwa Bremssysteme, Federungssysteme, Heizung, Lüftung und Klimatisierung (HLK), Unterhaltungssysteme, Diagnosesysteme usw. Einige oder alle dieser Systeme 117 weisen Daten auf, die sowohl für vielfältige bordeigene mobile Vorrichtungen 120 als auch für Anwendungsentwickler interessant sind, und können diese melden. Benutzer an Bord können einige der Systemdaten des Fahrzeugs 101 nutzen, um zum Beispiel eine Spielumgebung zu replizieren, die für die aktuellen Bedingungen des Fahrzeugs 101 sinnbildlich ist. Es kann sein, dass Entwickler mobiler Anwendungen Daten zu Komponentenverschleiß, Unterhaltungsoptionen, HLK-Einstellungen und vielfältige andere Informationen kennen möchten, die den Entwicklern beim Erzeugen von Anwendungen helfen können, die dazu in der Lage sind, anderen Benutzern auf Grundlage von Beobachtungen über Gewohnheiten von Personen, von denen Daten erhoben worden sind, Empfehlungen zu geben.
Viele der vorhergehenden Systeme 117 des Fahrzeugs 101 werden durch elektronische Steuereinheiten (ECUs) 118 unterstützt, die häufig auch dazu in der Lage sind, spezifische Dateninstanzen zu erlangen und bereitzustellen. Diesen ECUs 118 kann auch Rechenleistung zugeordnet sein, die in einem verteilten Rechenmodell verwendet werden kann, um die Verarbeitung der mobilen Vorrichtung 120 zu verbessern, wenn die ECU 118 nicht anderweitig für ihren primären beabsichtigten Zweck verwendet wird.
Das Fahrzeug 101 kann zudem eine oder mehrere bordeigene Anwendungen 119 beinhalten. Diese Anwendungen 119 können bordeigene Funktionen unterstützen oder verbessern sowie Möglichkeiten bereitstellen, um Daten bordextern mit einem Anwendungsserver 133, 135 zu verkaufen oder zu teilen. Die Verwendung einiger Anwendungen 119 kann durch eine Zustimmung zum Teilen von Daten kostenlos gemacht werden und in anderen Fällen kann der Besitzer oder Mitfahrer des Fahrzeugs 101 dazu in der Lage sein, als Reaktion auf eine oder mehrere Anforderungen von dem Anwendungsserver 133, 135 einen Gewinn oder eine Kostenaufrechnung (zum Beispiel für eine Mitfahrt) auf Grundlage von geteilten Daten zu generieren.
Die mobile Vorrichtung 120 des Mitfahrers kann mit dem Fahrzeug 101 durch Sendeempfänger der mobilen Vorrichtung 120 einschließlich WLAN 125 und BLUETOOTH 127 kommunizieren. Die mobile Vorrichtung 120 beinhaltet zudem einen Prozessor 121 und ist zu Mobilfunkkommunikation durch einen Mobilfunksendeempfänger 123 in der Lage. Durch den Mobilfunksendeempfänger 123 kann die mobile Vorrichtung 120 mit der Cloud 130 und direkt mit Anwendungsservern 133, 135 kommunizieren, die auf der mobilen Vorrichtung 120 installierte Anwendungen 129 unterstützen können oder durch die mobile Vorrichtung 120 Daten von dem Fahrzeug 101 anfordern können.
Die mobile Vorrichtung 120 kann entweder drahtlos oder zum Beispiel durch eine drahtgebundene USB-Verbindung mit dem Fahrzeug 101 verbunden sein. Wenn das Fahrzeug 101 verfügbare Verarbeitungsleistung oder Sensordaten aufweist, die für die mobile Vorrichtung 120 von Interesse sind (wie zum Beispiel durch das Fahrzeug 101 angekündigt oder durch die mobile Vorrichtung 120 angefordert), kann die mobile Vorrichtung 120 Daten zum Verarbeiten an den Prozessor 103 des Fahrzeugs, die ECUs 118 oder andere verfügbare verteilte Rechenressourcen senden. In anderen Beispielen kann die mobile Vorrichtung 120 gewisse Datentypen mit gewissen Abfrageraten von dem Fahrzeug 101 anfordern und das Fahrzeug 101 kann darauf reagieren, indem es die Daten mit der angeforderten Abfragerate entweder wieder durch die direkte Verbindung oder über eine drahtlose Aussendung der Daten, die die mobile Vorrichtung 120 abonnieren kann, bereitstellt.
Durch Verwenden eines derartigen Systems kann die mobile Vorrichtung 120 zum Beispiel die Abbildung mit dem Verwenden eines Fahrzeug-GPS in Kombination mit einem Trägheitssensor und einem Magnetometer verbessern. Dies kann sowohl die Batterielaufzeit der mobilen Vorrichtung verlängern als auch möglicherweise genauere Informationen bereitstellen. Die mobile Vorrichtung könnte zum Beispiel auch HLK- und Infotainment-Einstellungen und andere nutzen, um ein Erlebnis bei einer mobilen Anwendung zu verbessern.
Indem es der mobilen Vorrichtung 120 erlaubt wird, Verarbeitungsressourcen zu verwenden, und einem Fahrzeugbesitzer erlaubt wird, Daten sowohl an die mobile Vorrichtung 120 als auch an die Cloud-Server 133, 135 zu verkaufen, können Fahrzeugbesitzer oder auch Mitfahrer unter Verwendung von Technik, die bereits in der Infrastruktur des Fahrzeugs 101 besteht, neue Einnahmekanäle generieren.
Die Datenübertragung kann zum Beispiel durch eine Anwendungsprogrammierschnittstelle (application programming interface - API) erzielt werden, durch die eine mobile Anwendung 129 eine Datenverbindung zu dem Fahrzeug 101 erzeugen könnte, um Eingabedaten (über USB oder WLAN übertragen) zu erlangen, ähnlich dazu, wie eine Programmierschnittstelle instanziiert wird, um bereits auf der mobilen Vorrichtung 120 vorhandene bordeigene Sensordaten zu abonnieren. Aktualisierungen der angeforderten Daten können durch das Fahrzeug 101 laut einer Abfragerate, die in der App für jeden Sensor einzeln bestimmt wird, ausgesendet werden.
Die Implementierung einer API kann einzelnen Entwicklern überlassen bleiben, doch es könnte eine Suite von Dateneingaben verfügbar gemacht werden, die durch das Fahrzeug 101 erlangt werden kann. Die Anwendung 129 könnte das Fahrzeug 101 nach einer Richtlinientabelle mit Fähigkeiten, Abfrageraten und Berechtigungen abfragen. Eine weiße Liste (zum Beispiel in der Cloud 130 aktualisiert) würde erzeugt, um es den Anwendungen 129 zu ermöglichen, die allgemeinen verfügbaren Informationstypen zu erlangen, doch einzelne Fahrzeuge 101 können Bestimmungen darüber treffen, ob und wann ein gegebener Datentyp geteilt wird oder geteilt werden kann.
2 zeigt ein veranschaulichendes Beispiel für einen Prozess zum bordexternen Verlagern für eine mobile Vorrichtung, der zum Beispiel durch einen Prozessor 121 einer mobilen Vorrichtung ausführbar ist. In diesem Beispiel bestimmt die mobile Vorrichtung 120 bei 201, dass eine gewisse Verarbeitungsfunktion oder ein gewisser Datensatz für eine ausführende Anwendung 129 erforderlich ist. Diese Fähigkeit zum bordexternen Verlagern könnte in ein Betriebssystem der mobilen Vorrichtung 120 eingebaut sein (um gewisse Datenanforderungen umzuleiten) oder sie könnte in eine Anwendung 129 eingebaut sein, die dazu aufgebaut ist, die Interaktion mit einem Fahrzeug 101 zu nutzen, das eine derartige Funktionalität bereitstellt. Falls die Verarbeitung oder die Daten bei 203 keine bordexterne Verlagerung erfordern oder nicht davon profitieren, verwendet die Vorrichtung 120 bei 205 nur die systemeigene(n) Verarbeitung/Sensoren, um den Bedarf der Vorrichtung 120 zu erfüllen. In einigen Fällen, zum Beispiel wenn die Batterieleistung niedrig ist, kann die mobile Vorrichtung 120 versuchen, so viel Verarbeitung wie möglich bordextern zu verlagern, um die Batterielebensdauer zu bewahren. In anderen Fällen kann die mobile Vorrichtung 120 nur dann versuchen, Verarbeitung bordextern zu verlagern, falls ein erheblicher Verarbeitungsbedarf oder bordexterne Datenanforderungen bestehen, wenn die Anwendung 129 (über eine weiße Liste, die sich auf das aktuelle Fahrzeug 101 bezieht) identifiziert, dass ein gewisser Typ verbesserter Daten aus der Kommunikation mit dem Fahrzeug 101 erlangt werden kann.
Falls die Vorrichtung 120 bestimmt, dass bordexterne Verlagerung nützlich sein könnte, kann die Vorrichtung 120 bei 207 einen Dienst anfordern. Dieser Dienst entspricht einer Funktion (Verarbeitung/Datenbereitstellung), die von dem Fahrzeug 101 verfügbar ist, wie durch eine weiße Liste identifiziert, die dem Fahrzeug 101 zugeordnet ist, oder eine Aussendung des Fahrzeugs 101 von verfügbarer Verarbeitung/Datenbereitstellung. Falls der angeforderte Dienst bei 209 verfügbar ist, fordert die Vorrichtung 120 bei 211 auch eine Berechtigung an. Gewisse Funktionen können durch den OEM genehmigte Anwendungen erfordern und deshalb kann es selbst dann, wenn ein gewisser Datensatz verfügbar ist, sein, dass die Vorrichtung 120 oder die Anwendung 129 nicht für den Zugriff auf diese Daten genehmigt wird. Die Verfügbarkeit der Verarbeitung oder der Daten hängt typischerweise davon ab, was das Fahrzeug 101 derzeit mit der Verarbeitungsleistung und/oder den Daten unternimmt und ob ein Fahrer/Fahrgast/Besitzer geteilte Verarbeitung oder Teilen des angeforderten Datentyps genehmigt hat.
Falls die Vorrichtung 120 oder die Anwendung 129 bei 211 zum Zugriff auf die angeforderte Ressource genehmigt wird, kann die Vorrichtung 120 entweder bei 213 die Daten zur Verarbeitung senden oder bei 213 eine Aussendung von Sensordaten abonnieren, die den angeforderten Daten entsprechen. In vielen Fällen können dem Verwenden von Ressourcen des Fahrzeugs 101 Kosten zugeordnet sein und die Vorrichtung 120 kann zudem bei 215 die Zahlung für die angeforderten Daten oder die Verarbeitung abwickeln. Die Vorrichtung 120 empfängt dann die Daten in periodischen Abfrageintervallen (durch die Anwendung 129/Vorrichtung 120 vorgegeben oder durch das Fahrzeug 101 vorgegeben) und sobald die Anforderung abgeschlossen und erfüllt ist, kann die Vorrichtung 120 bei 217 das Abonnement der Datenaussendung beenden.
Es kann sein, dass die Vorrichtung 120 einen gewissen Datensatz abonnieren muss, um die angeforderten Daten zu empfangen, und wenn die Vorrichtung 120 diesen abonniert, kann das Fahrzeug 101 verfolgen, wie viele Instanzen von Daten der Vorrichtung 120 bereitgestellt worden sind. Dies ist nützlich, falls die Vorrichtung 120 für eine Anforderung für jede Instanz bezahlt, aber in anderen Modellen kann die Vorrichtung 120 einen festen Tarif für das Datenabonnement bezahlen und die Vorrichtung 120 kann dann bestimmen, wie viele Datenpunkte verwendet werden. Das Abonnieren der Daten kann es der Vorrichtung 120 erlauben, einen Schlüssel zum Entschlüsseln von ausgesendeten Daten zu empfangen, oder das Fahrzeug 101 kann in einem einfacheren Modell einfach Daten dieses Typs über einen verfügbaren Kommunikationskanal aussenden, solange eine Vorrichtung 120 einen gewissen Datentyp abonniert hat, bis zu dem Zeitpunkt, zu dem keine Vorrichtungen 120 diesen abonniert haben. Das letztere Modell würde es einer zweiten Vorrichtung erlauben, die Daten während der Aussendung effektiv kostenlos zu erlangen, doch es würde auch zusätzlichen Austausch von Sicherheitsprotokollen vermeiden und kann einfacher zu implementieren sein.
3 zeigt ein veranschaulichendes Beispiel für einen Prozess zur Anforderungserfüllung, der zum Beispiel durch einen Prozessor 103 eines Fahrzeugs 101 ausführbar ist. In diesem Beispiel empfängt das Fahrzeug 101 die Anforderung für Verarbeitung oder Daten von einer Vorrichtung 120. In diesem Beispiel könnte das Fahrzeug 101 zudem eine Anforderung von einer Anwendung 129 empfangen, die auf der Vorrichtung 120 ausgeführt wird, selbst in einer Situation, in der der Vorrichtungsbesitzer diese Anwendung 129 nicht verwendet. Gewisse Anwendungen 129 können dazu ausgestaltet sein, Daten des Fahrzeugs 101 zu nutzen, wenn diese verfügbar sind, und können somit gewisse Daten von dem Fahrzeug 101 anfordern, selbst wenn ein Besitzer der Vorrichtung 120 diese Daten nicht ausdrücklich benötigt. In einem derartigen Fall würde wahrscheinlich der Entwickler der Anwendung 129 und nicht der Besitzer der Vorrichtung 120 für die angeforderten Daten bezahlen und in einem Szenario mit einer Mitfahrgelegenheit kann der Besitzer der Vorrichtung 120 die Daten tatsächlich an den Anbieter der Anwendung 129 verkaufen, um sie gegen die Kosten einer Mitfahrt aufzurechnen.
Zum Beispiel kann eine verbesserte Navigationsanwendung 129 Fahrzeugdaten verwenden, um ein Benutzererlebnis zu verbessern. Dies kann vielfältige Daten (Verkehr, Straßenzustände, Wetter usw.) beinhalten, die für einen aktuellen Fahrgast nicht von besonderem Interesse sind, doch die Daten könnten für andere interessant sein, die sich auf dem Weg dahin befinden, wo sich der aktuelle Fahrgast gerade befindet. Gleichzeitig kann der Fahrgast das Recht haben, die Daten für eine gegebene in Anspruch genommene Mitfahrgelegenheit an jede anfordernde Entität zu verkaufen. Somit könnte der Fahrgast sich dafür entscheiden, die lokalen Sensordaten an eine Anwendung 129 zu verkaufen, die sich auf derselben Vorrichtung 120 befindet, die der Fahrgast in das Fahrzeug 101 mitgebracht hat. Dies würde Personen, die häufig reisen, dazu ermutigen, eine Reihe von Anwendungen 129 zu Datenbereitstellungszwecken auf ihr Telefon 120 zu laden, selbst wenn diese Personen diese Anwendungen 129 aus anderen Gründen selten oder nie verwenden.
In einem anderen Beispiel kann das Fahrzeug 101 eine Anforderung von dem Server für Datendienste 131 oder einem Anwendungsserver 133, 135 empfangen. Diese cloudbasierten Entitäten können dazu in der Lage sein, spezifische Fahrzeuge 101 zu identifizieren, die Eigenschaften (Modell, Geschwindigkeit, Typ, Standort usw.) aufweisen, die für die vereinzelte Bereitstellung von benötigten Daten wünschenswert sind, und die cloudbasierten Entitäten können die Daten direkt von identifizierten Fahrzeugen 101 anfordern. Der Fahrer oder Fahrgast kann erneut bestimmen, ob die Daten an den Server verkauft werden sollten, und ob die Anforderung erfüllt wird, kann von der Verfügbarkeit von Daten und Bereitstellungen zum Teilen abhängen.
Nachdem das Fahrzeug 101 die Anforderung bei 301 empfangen hat, kann das Fahrzeug 101 bestimmen, ob die angeforderte Verarbeitung oder Daten bei 303 verfügbar ist bzw. sind. Im Fall von Verarbeitung kann das Fahrzeug 101 bestimmen, ob das Fahrzeug 101 selbst Bedarf an der zusätzlichen Verarbeitungsfähigkeit aufweist, und im Fall von Daten kann das Fahrzeug 101 bestimmen, ob das Fahrzeug 101 die Fähigkeit und die Befähigung aufweist, die angeforderten Daten zu teilen. Die Fähigkeit kann von installierten Sensoren abhängen und davon, zu welchem Zweck diese Sensoren derzeit genutzt werden, und die Befähigung kann von den Einstellungen abhängen, die sich auf Datenteilung und etwaige Leistungsentnahme beziehen, der das Fahrzeug 101 im Austausch dafür ausgesetzt wird, dass die angeforderten Daten erlangt und bereitgestellt werden (d. h. ein Fahrzeug 101 in einem Zustand mit niedriger Leistung kann alle Anforderungen ignorieren, um die Leistung an Bord für Fahrzwecke zu bewahren).
Falls die angeforderte(n) Verarbeitung oder Daten derzeit nicht verfügbar ist bzw. sind, aber in Zukunft verfügbar sein könnte(n), kann das Fahrzeug 101 die Anforderung bei 305 in eine Warteschlange einreihen und die Vorrichtung 120 oder andere anfordernde Entität benachrichtigen, wenn der Dienst verfügbar ist. Falls der angeforderte Dienst bei 305 aktuell verfügbar ist und auf Grundlage von Teilungs- oder Berechtigungseinstellungen bei 307 nicht gestattet ist, kann das Fahrzeug 101 die Anforderung bei 309 ablehnen.
Andernfalls kann das Fahrzeug 101 der anfordernden Entität bei 311 Abonnementzugriff bereitstellen, was es der Entität erlaubt, Daten eines gewissen Typs in der Datenteilungsanforderung zu abonnieren, oder es kann im Fall einer verteilten Rechenanforderung einfach eine Verarbeitungsanforderung erfüllen. Falls die Vorrichtung 120 oder andere Entität Daten abonnieren wird, kann das Fahrzeug 101 die Vorrichtung 120 oder Entität bei 313 hinzufügen und etwaige erforderlichen Entschlüsselungs- oder Kanalidentifikationsparameter mit der Vorrichtung 120 oder Entität teilen, um es der Vorrichtung 120 oder Entität zu erlauben, die angeforderten Ergebnisse zu erlangen. Dann kann das Fahrzeug 101 in periodischen Abfrageintervallen die Daten bei 315 an die Vorrichtung 120 oder andere Entität aussenden (oder die Daten direkt über einen direkten Kommunikationskanal senden).
4 zeigt einen alternativen Prozess zum Bereitstellen von Daten an eine entfernte Entität, der zum Beispiel durch einen Prozessor 103 eines Fahrzeugs 101 ausführbar ist. In diesem Beispiel empfängt das Fahrzeug 101 bei 401 eine Femanforderung von einer entfernten Entität. Diese entfernte Entität könnte ein Datendienstserver 131, ein entfernter Anwendungsserver 133, 135 oder auch ein entfernter Server 133, 135 sein, der die Anforderung durch eine Anwendung 129 sendet, die auf einer mobilen Vorrichtung 120 im Inneren eines Fahrzeugs 101 ausgeführt wird.
Falls die Daten bei 403 nicht verfügbar sind, benachrichtigt das Fahrzeug 101 die anfordernde Entität bei 405 erneut über die aktuelle Nichtverfügbarkeit. Da entfernte Entitäten häufig Daten in Bezug auf einen spezifischen Fahrzeugstandort oder eine spezifische Fahrzeuglokalität benötigen, kann es sein, dass die Entität zu einem späteren Zeitpunkt nicht an den Daten interessiert ist. In diesem Fall bestimmt das Fahrzeug 101 bei 407, ob die Datenanforderung eine vereinzelte Anforderung ist, das heißt eine einmalige Anforderung, die an einen Fahrzeugstandort oder einen anderen vorübergehenden Parameter gebunden ist. Falls die nicht verfügbaren Daten bei 407 einer vereinzelten Anforderung entsprechen, lehnt das Fahrzeug 101 die Anforderung bei 409 ab, da sich der Zustand des Fahrzeugs 101, auf dem die Anforderung beruht hat, wahrscheinlich ändern wird, bevor die Daten zum Teilen verfügbar werden.
Falls die Anforderung eine laufende Anforderung ist (zum Beispiel möchte ein Anwendungsserver 133, 135 die Identifikation aller durch einen WLAN-Sendeempfänger 107 des Fahrzeugs identifizierten drahtlosen Netze entlang einer Route erheben), kann das Fahrzeug 101 bei 411 einen Prozess zur Zahlungs- und Datenaustauschzustimmung abwickeln. Daran sind typischerweise das Vorgeben von Bedingungen für die Erfüllung, ein Preis und eine Zustimmung zum Bezahlen des Preises und der Empfang eines Zahlungsformats von der anfordernden Entität beteiligt.
Sobald der Handshake und die Verhandlung zur Zahlung und Zustimmung bei 411 abgeschlossen sind, bestimmt das Fahrzeug 101 bei 413, ob die Anforderung eine vereinzelte Anforderung ist. Falls die Anforderung eine einmalige vereinzelte Anforderung ist, erlangt das Fahrzeug 101 die angeforderten Daten bei 415 und sendet die Daten bei 417 an die anfordernde Entität.
Falls die Anforderung andererseits eine Anforderung vom Abonnementtyp ist, die laufendes Melden in Intervallen erfordert, legt das Fahrzeug 101 bei 419 ein Meldeintervall fest. Dieses Intervall kann durch die anfordernde Entität vorgegeben werden oder für einen gegebenen Sensor oder ein gegebenes Fahrzeug 101 feststehen. In anderen Beispielen kann ein Fahrer oder Besitzer das Abfrage-/Meldeintervall für einen gegebenen Sensor vorgeben. Das Fahrzeug 101 kann zudem bei 419 eine Meldedauer festlegen, was zum Beispiel das Melden über X Zeit, über N Meilen oder bis zum Ende einer Fahrt beinhaltet. In vielen Fällen zahlt die anfordernde Entität auf Grundlage der Gesamtmenge der gemeldeten Daten, sodass die Entität einen Anreiz hat, eine genaue Meldedauer vorzugeben.
Sobald das Melden während der vorgegebenen Dauer bei 421 abgeschlossen worden ist, kann das Fahrzeug 101 die Zahlung für die Anforderung auf die bei 411 vereinbarte Weise abwickeln.
5 zeigt einen veranschaulichenden Prozess zum Abwickeln von Anforderungen nach Bedarf. Dieser Prozess ist durch einen Prozessor 103 eines Fahrzeugs 101 oder einen Prozessor eines Fahrzeugs 101, der mit einem Prozessor 121 einer mobilen Vorrichtung 120 zusammenarbeitet, ausführbar. In einigen Fällen kann ein Fahrer oder Besitzer eines Fahrzeugs dazu in der Lage sein, Anforderungen zu genehmigen, und in anderen Fällen kann ein Fahrgast das Recht haben, eine Anforderung zu genehmigen. Wer das Recht hat, die Anforderung zu genehmigen (und wer von der Zahlung profitiert), wird häufig durch eine Zustimmung vorgeschrieben sein (z. B. erlaubt das Mitfahrunternehmen U Mitfahrern, die Daten zu verkaufen, um die Mitfahrkosten zu decken) oder dadurch vorgeschrieben sein, welche Daten verkauft werden (z. B. könnten demografische Angaben zu dem Fahrgast plus das Ziel des Fahrgasts der Kontrolle des Fahrgasts unterliegen und Bremsverschleißdaten könnten der Kontrolle des Fahrers unterliegen).
Das Fahrzeug 101 empfängt die Anforderung bei 501 und bestimmt auf Grundlage von vordefinierten Parametern, wie etwa den vorhergehenden, wer zum Genehmigen der Anforderung angemessen ist. Falls dann bei 503 die entsprechende Entität die Anforderung genehmigt, wickelt das Fahrzeug 101 bei 507 die Abrechnung für die Anforderung ab. Falls zum Beispiel eine Anforderung für das Ziel und demografische Angaben des Fahrgasts empfangen worden ist, kann das Fahrzeug 101 bestimmen, dass der Fahrgast die Anforderung genehmigen sollte, und es würde die Anforderung zur Genehmigung an die mobile Vorrichtung 120 des Fahrgasts senden. In diesem Fall könnte der Wert des Erfüllens der Anforderung gegen die Kosten einer Mitfahrt aufgerechnet werden oder auf ein Fahrgastkonto eingezahlt werden.
Falls andererseits eine Bremsverschleißanforderung empfangen worden ist, kann das Fahrzeug 101 bestimmen, dass der Fahrer angemessen ist, um die Anforderung zu genehmigen, und die Anforderung zur Interaktion mit dem Fahrer und zu dessen Genehmigung an die HMI 111 senden. In diesem Fall könnte der Wert des Erfüllens der Anforderung auf ein Fahrerkonto gehen. Das Fahrzeug 101 sendet dann bei 509 Daten gemäß einer bei 507 vereinbarten Zahlung an die Entität, wenn die Genehmigung bei 503 empfangen wird. Falls bei 503 keine Genehmigung empfangen wird, kann das Fahrzeug 101 die Anforderung bei 505 einfach ablehnen.
Programmieranweisungen zum Ausführen von veranschaulichenden Ausführungsformen und dergleichen können durch geeignete Prozessoren ausgeführt werden, die abhängig von der Variation der Beispiele unter anderem Fahrzeugprozessoren, Cloud-Verarbeitung und/oder Prozessoren von mobilen Vorrichtungen beinhalten. Nichttransitorische Speichermedien, wie etwa unter anderem Festplattenlaufwerke, Festkörperlaufwerke und andere Speichermedien, die zum Speichern von Programmieranweisungen verwendet werden, können Anweisungen speichern, die es Prozessoren erlauben, auf diese Speichermedien zuzugreifen, um die Anweisungen auszuführen, um die veranschaulichenden Ausführungsformen und dergleichen durchzuführen.
In jeder der in dieser Schrift erörterten veranschaulichenden Ausführungsformen wird ein beispielhaftes nicht einschränkendes Beispiel für einen Prozess gezeigt, der durch ein Rechensystem durchgeführt werden kann. In Bezug auf jeden Prozess ist es möglich, dass das Rechensystem, das den Prozess ausführt, für den begrenzten Zweck des Ausführens des Prozesses als Spezialprozessor zum Durchführen des Prozesses konfiguriert wird. Nicht alle Prozesse müssen in ihrer Gesamtheit durchgeführt werden, sondern sind als Beispiele für Arten von Prozessen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu erzielen. Nach Bedarf können zusätzliche Schritte den Prozessen hinzugefügt oder daraus entfernt werden.
Hinsichtlich der veranschaulichenden Ausführungsformen, die in den Figuren beschrieben sind, die veranschaulichende Prozessabläufe zeigen, ist anzumerken, dass ein Universalprozessor zum Zwecke des Ausführens einiger oder aller der durch diese Figuren gezeigten beispielhaften Verfahren vorübergehend als Spezialprozessor befähigt werden kann. Wenn Code ausgeführt wird, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend so lange als Spezialprozessor umfunktioniert werden, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann im geeigneten Umfang Firmware, die gemäß einem im Voraus konfigurierten Prozessor wirkt, den Prozessor dazu veranlassen, als Spezialprozessor zu wirken, der zum Zwecke des Durchführens des Verfahrens oder einer sinnvollen Variation davon bereitgestellt wird.
Wenngleich vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und keine einschränkenden Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Erfindung abzuweichen. Zusätzlich dazu können die Merkmale verschiedener Ausführungsformen zur Umsetzung auf logische Weise kombiniert werden, um situationsgerechte Variationen von in dieser Schrift beschriebenen Ausführungsformen zu bilden.
Gemäß der vorliegenden Erfindung ist eine mobile Vorrichtung bereitgestellt, die Folgendes aufweist: einen Speicher, der eine Anwendung speichert; und einen Prozessor, der konfiguriert ist zum Anfordern der Verwendung einer Fahrzeugressource eines Fahrzeugs in Verbindung mit der Ausführung der Anwendung auf der mobilen Vorrichtung; Empfangen einer Benachrichtigung über Kosten des Verwendens der Fahrzeugressource; Senden einer Zustimmung zum Bezahlen der Kosten an das Fahrzeug; und Empfangen von Daten von der Fahrzeugressource als Reaktion auf die gesendete Zustimmung.
Gemäß einer Ausführungsform wird die Anforderung explizit durch einen Benutzer der mobilen Vorrichtung in Form einer eingegebenen Anforderung erstellt.
Gemäß einer Ausführungsform wird die Anforderung passiv durch die Anwendung als Reaktion auf das Detektieren einer verfügbaren Verbindung zu dem Fahrzeug und eine durch die Anwendung definierte Verwendung für die Fahrzeugressource erstellt.
Gemäß einer Ausführungsform wird die Anforderung passiv durch die Anwendung als Reaktion darauf, dass eine dem Fahrzeug zugeordnete weiße Liste die Fahrzeugressource als zur Verwendung verfügbar identifiziert, und auf eine durch die Anwendung definierte Verwendung für die Fahrzeugressource erstellt.
Gemäß einer Ausführungsform wird die Anforderung passiv durch die Anwendung als Reaktion darauf, dass eine Aussendung durch das Fahrzeug von verfügbaren Ressourcen die Fahrzeugressource als zur Verwendung verfügbar identifiziert, und auf eine durch die Anwendung definierte Verwendung für die Fahrzeugressource erstellt.
Gemäß einer Ausführungsform beinhaltet die Verwendung der Fahrzeugressource die Verwendung von Fahrzeugrechenzyklen.
Gemäß einer Ausführungsform beinhaltet die Verwendung der Fahrzeugressource die Verwendung eines Fahrzeugsensors.
Gemäß einer Ausführungsform beinhaltet die Verwendung der Fahrzeugressource die Verwendung von durch das Fahrzeug erhobenen Daten.
Gemäß der vorliegenden Erfindung ist ein Fahrzeug bereitgestellt, das Folgendes aufweist: einen drahtlosen Sendeempfänger; und einen Prozessor, der konfiguriert ist zum Empfangen einer Anforderung zur Verwendung der Fahrzeugressource von einer entfernten Quelle über den drahtlosen Sendeempfänger; Bestimmen, ob das Fahrzeug dazu in der Lage ist, die Anforderung zu erfüllen, auf Grundlage eines Zustands der Ressource; Senden von Kosten für das Verwenden der Ressource an die entfernte Quelle als Reaktion darauf, dass bestimmt wird, dass das Fahrzeug dazu in der Lage ist, die Anforderung zu erfüllen, und Bereitstellen der Verwendung der Ressource gemäß einer in Verbindung mit den Kosten definierten Verwendungslaufzeit als Reaktion darauf, dass eine Zustimmung von der entfernten Quelle zum Bezahlen der Kosten empfangen wird.
Gemäß einer Ausführungsform beinhaltet die entfernte Quelle eine mobile Vorrichtung im Inneren des Fahrzeugs.
Gemäß einer Ausführungsform beinhaltet die entfernte Quelle einen entfernten Server in Kommunikation mit dem Fahrzeug.
Gemäß einer Ausführungsform beinhaltet die Verwendung der Fahrzeugressource die Verwendung eines Fahrzeugsensors.
Gemäß einer Ausführungsform beinhaltet die Verwendung der Fahrzeugressource die Verwendung von Fahrzeugverarbeitungszyklen.
Gemäß einer Ausführungsform beinhaltet die Verwendung der Fahrzeugressource die Verwendung von durch das Fahrzeug erhobenen Daten.
Gemäß einer Ausführungsform ist der Prozessor ferner dazu konfiguriert, die Anforderung vor dem Senden der Kosten einem Fahrzeuginsassen zur Genehmigung darzustellen, und wobei das Senden der Kosten von der Genehmigungseingabe von dem Insassen abhängt.
Gemäß der vorliegenden Erfindung ist ein Fahrzeug bereitgestellt, das Folgendes aufweist: einen drahtlosen Sendeempfänger; und einen Prozessor, der konfiguriert ist zum Bestimmen einer oder mehrerer Fahrzeugressourcen über den drahtlosen Sendeempfänger, die zur Verwendung durch eine entfernte Quelle verfügbar sind; Aussenden der Verfügbarkeit der bestimmten einen oder mehreren Ressourcen; Empfangen einer Anforderung von einer entfernten Quelle zum Verwenden von mindestens einer der Fahrzeugressourcen; und als Reaktion darauf, dass bestimmt wird, dass die mindestens eine Ressource derzeit nicht durch das Fahrzeug verwendet wird und zur Verwendung durch die entfernte Quelle verfügbar ist, Bereitstellen der Verwendung der mindestens einen Ressource im Austausch gegen eine Zahlungszustimmung von der entfernten Quelle.
Gemäß einer Ausführungsform beinhaltet die Aussendung Kosten für die Verwendung jeder Ressource.
Gemäß einer Ausführungsform beinhaltet die Aussendung einen Meldezyklus für Ressourcen der einen oder mehreren Ressourcen, die Daten erheben.
Gemäß einer Ausführungsform ist der Prozessor zum Einreihen der Anforderung in eine Warteschlange, bis die mindestens eine Ressource nicht durch das Fahrzeug verwendet wird, als Reaktion darauf konfiguriert, dass bestimmt wird, dass die mindestens eine Ressource derzeit durch das Fahrzeug verwendet wird.
Gemäß einer Ausführungsform ist der Prozessor zum Aussenden der Verfügbarkeit der bestimmten einen oder mehreren Ressourcen als Reaktion darauf konfiguriert, dass eine Anforderung von einer mobilen Vorrichtung, die in drahtloser Kommunikation mit dem Fahrzeug steht, eine Liste mit verfügbaren Fahrzeugressourcen anfordert.

Claims

Mobile Vorrichtung, umfassend: einen Speicher, der eine Anwendung speichert; und einen Prozessor, der konfiguriert ist zum Anfordern der Verwendung einer Fahrzeugressource eines Fahrzeugs in Verbindung mit der Ausführung der Anwendung auf der mobilen Vorrichtung; Empfangen einer Benachrichtigung über Kosten des Verwendens der Fahrzeugressource; Senden einer Zustimmung zum Bezahlen der Kosten an das Fahrzeug; und Empfangen von Daten von der Fahrzeugressource als Reaktion auf die gesendete Zustimmung.
Mobile Vorrichtung nach Anspruch 1, wobei die Anforderung explizit durch einen Benutzer der mobilen Vorrichtung in Form einer eingegebenen Anforderung erstellt wird.
Mobile Vorrichtung nach Anspruch 1, wobei die Anforderung passiv durch die Anwendung als Reaktion auf das Detektieren einer verfügbaren Verbindung zu dem Fahrzeug und eine durch die Anwendung definierte Verwendung für die Fahrzeugressource erstellt wird.
Mobile Vorrichtung nach Anspruch 1, wobei die Anforderung passiv durch die Anwendung als Reaktion darauf, dass eine dem Fahrzeug zugeordnete weiße Liste die Fahrzeugressource als zur Verwendung verfügbar identifiziert, und auf eine durch die Anwendung definierte Verwendung für die Fahrzeugressource erstellt wird.
Mobile Vorrichtung nach Anspruch 1, wobei die Anforderung passiv durch die Anwendung als Reaktion darauf, dass eine Aussendung durch das Fahrzeug von verfügbaren Ressourcen die Fahrzeugressource als zur Verwendung verfügbar identifiziert, und auf eine durch die Anwendung definierte Verwendung für die Fahrzeugressource erstellt wird.
Mobile Vorrichtung nach Anspruch 1, wobei die Verwendung der Fahrzeugressource die Verwendung von Fahrzeugrechenzyklen beinhaltet.
Mobile Vorrichtung nach Anspruch 1, wobei die Verwendung der Fahrzeugressource die Verwendung eines Fahrzeugsensors beinhaltet.
Mobile Vorrichtung nach Anspruch 1, wobei die Verwendung der Fahrzeugressource die Verwendung von durch das Fahrzeug erhobenen Daten beinhaltet.
Fahrzeug, umfassend: einen drahtlosen Sendeempfänger; und einen Prozessor, der konfiguriert ist zum Empfangen einer Anforderung zur Verwendung der Fahrzeugressource von einer entfernten Quelle über den drahtlosen Sendeempfänger; Bestimmen, ob das Fahrzeug dazu in der Lage ist, die Anforderung zu erfüllen, auf Grundlage eines Zustands der Ressource; Senden von Kosten für das Verwenden der Ressource an die entfernte Quelle als Reaktion darauf, dass bestimmt wird, dass das Fahrzeug dazu in der Lage ist, die Anforderung zu erfüllen, und Bereitstellen der Verwendung der Ressource gemäß einer in Verbindung mit den Kosten definierten Verwendungslaufzeit als Reaktion darauf, dass eine Zustimmung von der entfernten Quelle zum Bezahlen der Kosten empfangen wird.
Fahrzeug nach Anspruch 9, wobei die entfernte Quelle eine mobile Vorrichtung im Inneren des Fahrzeugs beinhaltet.
Fahrzeug nach Anspruch 9, wobei die entfernte Quelle einen entfernten Server in Kommunikation mit dem Fahrzeug beinhaltet.
Fahrzeug nach Anspruch 9, wobei die Verwendung der Fahrzeugressource die Verwendung eines Fahrzeugsensors beinhaltet.
Fahrzeug nach Anspruch 9, wobei die Verwendung der Fahrzeugressource die Verwendung von Fahrzeugverarbeitungszyklen beinhaltet.
Fahrzeug nach Anspruch 9, wobei die Verwendung der Fahrzeugressource die Verwendung von durch das Fahrzeug erhobenen Daten beinhaltet.
Fahrzeug nach Anspruch 9, wobei der Prozessor ferner dazu konfiguriert ist, die Anforderung vor dem Senden der Kosten einem Fahrzeuginsassen zur Genehmigung darzustellen, und wobei das Senden der Kosten von der Genehmigungseingabe von dem Insassen abhängt.