-
TECHNISCHES GEBIET
-
Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen Verfahren und Vorrichtungen zur Kraftstoffzahlungsverarbeitung.
-
ALLGEMEINER STAND DER TECHNIK
-
Öffentliche Ladestationen für elektrisch betriebene Plugin-Fahrzeuge können in deren Betrieb, Benutzerschnittstelle und Zahlungsverfahren entscheidend variieren. Ladestationen können verschiedene Hersteller aufweisen und können durch verschiedene Ladungsanbieter betrieben werden, jeweils mit einem einzigartigen Vorgang zum Einstecken des Ladekabels, Erzielen der Zahlung, Einleiten des Ladens und Informieren des Benutzers über den Ladefortschritt.
-
Um eine Ladung an einer bezahlten öffentlichen Ladestation einzuleiten, ist üblicherweise eine Form von Identifikation und Art von Zahlung erforderlich. Normalerweise werden die Zahlung und Einleitung durch eine von vier Methoden vorgenommen: Antippen einer RFID-Karte, die mit einer Kreditkarte verbunden ist, Aktivieren der Ladung durch eine Telefonanwendung (nach Auswählen des entsprechenden Ladegeräts in der App), direktes Einführen einer Kreditkarte oder Anrufen einer Telefonnummer, die an dem Ladegerät aufgelistet ist. Diese Verfahren variieren je nach Ladegerät und machen oftmals erforderlich, dass der Benutzer mehrere verschiedene RFID-Karten und/oder Apps auf seinem Telefon mit sich führt. All diese Variabilität sorgt für Komplexität und Verwirrung von Kunden, die an den äußerst standardisierten und praktischen Auftankprozess gewöhnt sind, der an Benzin-/Dieseltankstellen vorhanden ist.
-
KURZDARSTELLUNG
-
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der konfiguriert ist, um eine Fahrzeugkennung, die ein Fahrzeug identifiziert, von einer ersten digitalen Einheit zu empfangen. Der Prozessor ist außerdem konfiguriert, um ein Zahlungskonto, das der Kennung zugeordnet ist, als Reaktion auf das Empfangen der Kennung digital zu erhalten. Der Prozessor ist ferner konfiguriert, um Zahlungsrechte durch Eingabe von einer zweiten Einheit zu validieren, die Rechte zur Verwendung des Kontos zum Bezahlen für ein Laden des Fahrzeugs zu bestätigen und das Zahlungskonto nach Abschluss des Ladens des Fahrzeugs als Reaktion auf eine erfolgreiche Validierung mit dem Laden des Fahrzeugs zu belasten.
-
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren Empfangen einer Fahrzeugkennung als Reaktion auf Verbinden eines Ladekabels mit einem Fahrzeug und über eine Verbindung, die durch das Ladekabel aufgebaut wurde. Das Verfahren beinhaltet außerdem Anfordern von Zahlungsinformationen von einem Cloud-Konto, wobei die Informationen der Fahrzeugkennung zugeordnet sind, die an das Cloud-Konto übertragen wurde. Das Verfahren beinhaltet ferner Beginnen eines Ladens des Fahrzeugs als Reaktion auf das Empfangen der Zahlungsinformationen und Verwenden der Zahlungsinformationen zum Bezahlen für das Laden nach Abschluss des Ladens.
-
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren drahtloses Empfangen einer Fahrzeugkennung an einem Fahrzeugladegerät von einem Fahrzeugschlüsselanhänger. Das Verfahren beinhaltet außerdem digitales Anfordern von Zahlungsinformationen, die der Fahrzeugkennung zugeordnet sind, wobei die Anforderung die Fahrzeugkennung beinhaltet. Das Verfahren beinhaltet ferner Verifizieren einer Genehmigung zur Verwendung der Zahlungsinformationen durch Anfragen an einer anderen Einheit als dem Fahrzeugschlüsselanhänger, wobei die Einheit die Zahlung durch Reagieren mit einer vordefinierten Verifizierung verifiziert. Außerdem beinhaltet das Verfahren Beginnen eines Ladens des Fahrzeugs als Reaktion auf Verifizieren der Zahlungsinformationen und Verwenden der Zahlungsinformationen zum Bezahlen für das Laden nach Abschluss des Ladens.
-
Figurenliste
-
- 1 zeigt ein veranschaulichendes Fahrzeugrechensystem;
- 2 zeigt einen veranschaulichenden Prozess zur Zahlungserfassung und -verarbeitung;
- 3A und 3B zeigen veranschaulichende Prozesse zur VIN-Erfassung;
- 4 zeigt einen veranschaulichenden Prozess zur Zahlungsverarbeitung; und
- 5A-5C zeigen veranschaulichende Prozesse zur Ladungseinführung.
-
DETAILLIERTE BESCHREIBUNG
-
Je nach Bedarf werden hierin detaillierte Ausführungsformen offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein veranschaulichender Natur sind und in verschiedenen und alternativen Formen integriert sein können. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Daher sind hierin offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um dem Fachmann die vielfältige Umsetzung des beanspruchten Gegenstands zu lehren.
-
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Rechensystem 1 (vehicle based computing system - VCS) für ein Fahrzeug 31. Ein Beispiel für ein derartiges fahrzeugbasiertes Rechensystem 1 ist das SYNC-System, hergestellt durch THE FORD MOTOR COMPANY. Ein mit einem fahrzeugbasierten Rechensystem ausgestattetes Fahrzeug kann eine optische Frontend-Schnittstelle 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann zudem dazu in der Lage sein, mit der Schnittstelle zu interagieren, wenn sie beispielsweise mit einer Touchscreen-Anzeige bereitgestellt ist. In einer weiteren veranschaulichenden Ausführungsform erfolgt die Interaktion durch Betätigen von Tasten, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
-
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 zumindest einen Teil des Betriebs des fahrzeugbasierten Rechensystems. Der in dem Fahrzeug bereitgestellte Prozessor ermöglicht das fahrzeuginterne Verarbeiten von Befehlen und Abläufen. Außerdem ist der Prozessor sowohl mit einem nichtdauerhaften 5 als auch dauerhaften Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform handelt es sich bei dem nichtdauerhaften Speicher um einen Direktzugriffsspeicher (random access memory - RAM) und bei dem dauerhaften Speicher um einen Festplattenspeicher (hard disk drive - HDD) oder Flash-Speicher. Im Allgemeinen kann der dauerhafte (nichtflüchtige) Speicher alle Speicherformen einschließen, die Daten behalten, wenn ein Computer oder eine andere Vorrichtung ausgeschaltet wird. Diese schließen unter anderem HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und jede beliebige andere geeignete Form von dauerhaftem Speicher ein.
-
Der Prozessor ist zudem mit einer Reihe von unterschiedlichen Eingängen bereitgestellt, die es dem Benutzer ermöglichen, über eine Schnittstelle mit dem Prozessor zu interagieren. Bei dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der eine Touchscreen-Anzeige sein kann, und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Eine Eingangswähleinheit 51 ist ebenfalls bereitgestellt, damit ein Benutzer zwischen verschiedenen Eingängen wechseln kann. Eingaben sowohl an dem Mikrofon als auch dem Hilfsanschluss werden durch einen Wandler 27 von analog in digital umgewandelt, bevor sie zu dem Prozessor weitergeleitet werden. Wenngleich nicht gezeigt, können zahlreiche Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS in Kommunikation stehen, ein Fahrzeugnetzwerk (wie etwa unter anderem einen CAN-Bus) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) weiterzuleiten.
-
Ausgänge zu dem System können unter anderem eine optische Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang beinhalten. Der Lautsprecher ist an einen Verstärker 11 angeschlossen und empfängt sein Signal durch einen Digital-Analog-Wandler 9 von dem Prozessor 3. Eine Ausgabe kann zudem an eine Remote-BLUETOOTH-Vorrichtung, wie etwa eine PND 54, oder eine USB-Vorrichtung, wie etwa die Fahrzeugnavigationsvorrichtung 60, entlang der bidirektionalen Datenströme, die bei 19 und 21 gezeigt sind, übertragen werden.
-
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sendeempfänger 15, um mit einer Mobilvorrichtung 53 eines Benutzers zu kommunizieren 17 (z. B. einem Mobiltelefon, Smartphone, PDA oder einer beliebigen anderen Vorrichtung, die eine drahtlose Remote-Netzwerkkonnektivität aufweist). Die Mobilvorrichtung (nachstehend als ND (nomadic device) bezeichnet) 53 kann dann verwendet werden, um beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. In einigen Ausführungsformen kann es sich bei dem Mast 57 um einen WLAN-Zugangspunkt handeln.
-
Eine beispielhafte Kommunikation zwischen der ND 53 und dem BLUETOOTH-Sendeempfänger 15 wird durch das Signal 14 wiedergegeben.
-
Das Koppeln der ND 53 mit dem BLUETOOTH-Sendeempfänger 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der bordeigene BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einer Mobilvorrichtung gekoppelt wird.
-
Zwischen der CPU 3 und dem Netzwerk 61 können Daten beispielsweise unter Verwendung eines Datentarifs, von Daten-über-Sprache oder DTMF-Tönen kommuniziert werden, die der ND 53 zugeordnet sind. Alternativ kann es wünschenswert sein, ein bordeigenes Modem 63 einzuschließen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Die ND 53 kann dann verwendet werden, um beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 herstellen, um mit dem Netzwerk 61 zu kommunizieren. Als nicht einschränkendes Beispiel kann es sich bei dem Modem 63 um ein USB-Mobilfunkmodem und bei der Kommunikation 20 um Mobilfunkkommunikation handeln.
-
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem bereitgestellt, das eine API zum Kommunizieren mit einer Modemanwendungssoftware beinhaltet. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine Firmware auf dem BLUETOOTH-Sendeempfänger zugreifen, um die Drahtloskommunikation mit einem Remote-BLUETOOTH-Sendeempfänger (wie etwa demjenigen, der in einer Mobilvorrichtung anzutreffen ist) abzuschließen. Bei Bluetooth handelt es sich um eine Teilmenge der IEEE-802-PAN-(Personal Area Network-)Protokolle. IEEE-802-LAN-(Local Area Network-)Protokolle beinhalten WLAN und weisen eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide eignen sich zur Drahtloskommunikation in einem Fahrzeug. Ein weiteres Kommunikationsmittel, das in diesem Bereich verwendet werden kann, sind die optische Freiraumkommunikation (wie etwa IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
-
In einer weiteren Ausführungsform beinhaltet die ND 53 ein Modem zur Sprachband- oder Breitbanddatenkommunikation. In der Daten-über-Sprache-Ausführungsform kann eine Technik umgesetzt werden, die als Frequenzmultiplexverfahren bekannt ist, wenn der Besitzer der Mobilvorrichtung bei gleichzeitiger Datenübertragung über die Vorrichtung sprechen kann. Zu anderen Zeitpunkten, zu denen der Besitzer die Vorrichtung nicht verwendet, kann die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) zur Datenübertragung verwendet werden. Obwohl das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet geläufig sein kann und weiterhin verwendet wird, wurde es weitgehend durch Hybride von Codemultiplexverfahren (Code Domain Multiple Access - CDMA), Zeitmultiplexverfahren (Time Domain Multiple Access - TDMA), Raummultiplexverfahren (Space Domain Multiple Access SDMA) für eine digitale Mobilfunkkommunikation ersetzt. Wenn der Benutzer über einen der Mobilvorrichtung zugeordneten Datentarif verfügt, besteht die Möglichkeit, dass der Datentarif eine Breitbandübertragung ermöglicht und das System eine wesentlich größere Bandbreite verwenden könnte (was die Datenübertragungsgeschwindigkeit erhöht). In noch einer weiteren Ausführungsform wird die ND 53 durch eine Mobilfunkkommunikationsvorrichtung (nicht gezeigt) ersetzt, die in das Fahrzeug 31 eingebaut ist. In noch einer weiteren Ausführungsform kann die ND 53 eine Vorrichtung eines drahtlosen lokalen Netzwerks (local area network - LAN) sein, das beispielsweise (und ohne Einschränkung) über ein 802.11g-Netzwerk (d. h. WLAN) oder ein WiMax-Netzwerk kommunizieren kann.
-
In einer Ausführungsform können eingehende Daten über Daten-über-Sprache oder einen Datentarif durch die Mobilvorrichtung, durch den fahrzeuginternen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs weitergeleitet werden. Im Falle bestimmter temporärer Daten können die Daten zum Beispiel auf dem HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
-
Zusätzliche Quellen, die eine Schnittstelle mit dem Fahrzeug aufweisen können, schließen Folgende ein: eine persönliche Navigationsvorrichtung 54, die zum Beispiel einen USB-Anschluss 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationsvorrichtung 60, die einen USB-Anschluss 62 oder anderen Anschluss aufweist, eine fahrzeuginterne GPS-Vorrichtung 24 oder ein Remote-Navigationssystem (nicht gezeigt), das eine Verbindung mit dem Netzwerk 61 aufweist. Bei USB handelt es sich um eines von einer Klasse serieller Netzwerkprotokolle. Die seriellen Protokolle IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Vorrichtung-zu-Vorrichtung-Normen. Die Mehrheit der Protokolle kann entweder für die elektrische oder die optische Kommunikation umgesetzt werden.
-
Ferner könnte die CPU mit einer Vielzahl von anderen Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können über eine drahtlose 67 oder drahtgebundene 69 Verbindung verbunden sein. Die Hilfsvorrichtung 65 kann unter anderem persönliche Medienwiedergabevorrichtungen, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen einschließen.
-
Zudem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, zum Beispiel unter Verwendung eines Sendeempfängers 71 für WLAN (IEEE 803.11). Dies könnte es der CPU ermöglichen, sich mit Remote-Netzwerken in Reichweite des lokalen Routers 73 zu verbinden.
-
Zusätzlich zur Ausführung beispielhafter Prozesse durch ein sich in einem Fahrzeug befindendes Fahrzeugrechensystem können die beispielhaften Prozesse bei bestimmten Ausführungsformen durch ein Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Kommunikation steht. Ein derartiges System kann unter anderem eine drahtlose Vorrichtung (z. B. unter anderem ein Mobiltelefon) oder ein Remote-Rechensystem (z. B. unter anderem einen Server) einschließen, die über die drahtlose Vorrichtung verbunden sind. Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Rechensysteme (vehicle associated computing systems - VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS in Abhängigkeit von der konkreten Umsetzung des Systems bestimmte Teile eines Prozesses durchführen. Falls ein Prozess beispielsweise und nichteinschränkend einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, ist es wahrscheinlich, dass die drahtlose Vorrichtung diesen Teil des Prozesses nicht durchführt, da die drahtlose Vorrichtung Informationen nicht sich selbst bzw. von sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes Rechensystem auf eine bestimmte Lösung anzuwenden.
-
In jeder der hierin 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 den jeweiligen Prozess ist es möglich, dass das Rechensystem, das den Prozess ausführt, für den beschränkten Zweck der Ausführung des Prozesses als Spezialprozessor zum Durchführen des Prozesses konfiguriert ist. Alle Prozesse müssen nicht in ihrer Gesamtheit durchgeführt werden und sind als Beispiele von Prozesstypen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu realisieren. Zusätzliche Schritte können nach Bedarf zu den beispielhaften Prozessen hinzugefügt oder daraus entfernt werden.
-
In Bezug auf die veranschaulichenden Ausführungsformen, die in den Figuren beschrieben sind, die veranschaulichende Prozessabläufe zeigen, ist anzumerken, dass ein Universalprozessor vorübergehend als Spezialprozessor zum Zwecke des Ausführens einiger oder aller der beispielhaften Verfahren, die durch diese Figuren gezeigt werden, aktiviert werden kann. Wenn Code ausgeführt wird, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor erneut vorübergehend als Spezialprozessor eingesetzt werden, und zwar so lange, bis das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann in einem angemessenen Ausmaß Firmware, die gemäß einem vorkonfigurierten Prozessor agiert, veranlassen, dass der Prozessor als Spezialprozessor agiert, der zum Zwecke des Durchführens des Verfahrens oder einer angemessenen Variation davon bereitgestellt ist.
-
Aufgrund von Benutzererwartungen und -präferenzen für einfache Benutzerzahlungslösungen besteht eine Gelegenheit, ein standardisiertes, vereinfachtes, benutzerfreundliches Verfahren zum öffentlichen Laden bereitzustellen.
-
Die veranschaulichenden Ausführungsformen stellen eine Anwenderfreundlichkeit bezüglich des Ladens bereit, ähnlich der Unkompliziertheit, die der schlüssellose Eintritt und der Druckknopfstart für das Fahrzeug selbst mit sich bringen. Jede vorgeschlagene Ladestation kann die Fahrzeug-VIN erfassen, eine Verbindung zu zugeordneten Benutzerzahlungsinformationen herstellen, ein Laden automatisch authentifizieren und dann einleiten, wenn das Fahrzeug eingesteckt ist. Die Erfassung einer VIN kann über den Fahrzeug-CAN-Bus, sobald ein Ladekabel eingesteckt wurde, durch drahtlose Schnittstellenbildung mit dem Fahrzeugschlüsselanhänger oder (für eine zusätzliche Sicherheit) durch beides vorgenommen werden.
-
Benutzerzahlungsinformationen können einer VIN zugeordnet und in der Cloud oder offline in dem Fahrzeug selbst gespeichert werden. Zum Beispiel könnten eine Einleitung einer Zahlung und ein Ladungsbeginn über einen einzigen Knopfdruck an dem Ladegerät, einem Knopfdruck an einer Smart-Telefonapp oder einem Knopfdruck an der Fahrzeuganzeige vorgenommen werden oder könnten vollständig automatisch auf Grundlage einer vorangehenden Autorisierung sein.
-
Dieser vorgeschlagene Ladungsprozess kann die Benutzerinteraktion mit der Ladestation in großem Maße minimieren, ein Durchziehen oder Scannen von Kreditkarten oder RFID-Karten vermeiden und eine standardisierte Erfahrung bereitstellen, die über einen beliebigen Ladegerätehersteller oder -anbieter umgesetzt werden kann.
-
2 zeigt einen veranschaulichenden Prozess zur Zahlungserfassung und -verarbeitung. In diesem Beispiel wird der Prozess an einem Ladegerät oder einem Computer ausgeführt, der an dem Ladegerät angeschlossen ist. Alle der vorgeschlagenen Lösungen könnten in Bezug auf herkömmliche Benzinpumpen ebenfalls angewendet werden, unter der Voraussetzung, dass jegliche Erfassungs- und/oder Sperrfunktionen, die für eine Umsetzung erforderlich sind, als Funktionen der Benzinpumpe ebenfalls bereitgestellt sind.
-
Der Prozess beginnt mit Erfassen 201 einer VIN. Die VIN kann in einem Schlüsselanhänger gespeichert sein und mithilfe von BLUETOOTH-Low-Energy, RFID, NFC oder einer anderen Nahbereichskommunikation erfasst werden. Der Nahbereich wird bevorzugt, da dies ein Vermeiden von Verwirrung durch Erfassen von zu vielen IDs unterstützen kann. Selbstverständlich könnten Signalstärke und andere Faktoren mit Erfassung eines längeren Bereichs verwendet werden, um Entscheidungsmöglichkeiten zu beschränken und/oder es könnte eine Lösung mit längerer Reichweite verwendet werden, wenn der Kunde die bestimmte VIN oder andere Fahrzeugkennung bestätigen muss. In vielen Beispielen kann die VIN außerdem als eine zweite Punktquelle verifiziert werden, die sich davon unterscheidet, wenn die VIN empfangen wurde, sodass in Fällen, in denen eine Verifizierung verwendet wird, selbst wenn anfangs eine Reihe von VINs erfasst wurden, die richtige VIN aus der Gruppe identifizierbar sein sollte. In anderen Modellen wird die VIN-Erfassung durch direkte Kommunikation mit einem Fahrzeug über eine physische Verbindung unterstützt, wodurch jegliche Unklarheit in diesen Fällen aus dem Weg geräumt werden sollte.
-
Sobald die VIN erfasst wurde, ordnet 203 der Prozess diese VIN einem bestimmten Ladegerät zu. Wenn durch bestimmte Erfassungsprozesse mehrere VINs erfasst werden, kann ein Verifizierungsschritt vor der Zuordnung erfolgen, um sicherzustellen, dass die richtige VIN dem richtigen Ladegerät zugeordnet wird. Sobald die VIN zugeordnet wurde, kann der Prozess Zahlungsinformationen anfordern 205, die in Bezug auf eine VIN gespeichert sind. Die Zahlungsinformationen können in der Cloud gespeichert sein oder die Zahlungsinformationen können auf eine abrufbare Weise in einem Fahrzeug- oder Schlüsselanhängerspeicher gespeichert sein.
-
Wenn die VIN verifiziert werden muss (was von dem Verfahren des Erhaltens der VIN abhängig sein kann) und wenn die VIN noch nicht verifiziert 207 wurde, kann der Prozess die Verifizierung der VIN anfordern 209. Dies könnte zum Beispiel Vergleichen der VIN mit einer zweiten Vorrichtung in der Nähe (z. B. einem Schlüsselanhänger oder Fahrzeug, je nachdem, welches nicht verwendet wurde, um die VIN anfänglich abzurufen) und/oder Eingeben einer Postleitzahl, einer PIN oder eines anderen Codes durch den Benutzer in das Ladegerät beinhalten. Andere geeignete Verifizierungsverfahren werden ebenfalls in Erwägung gezogen.
-
Sobald die VIN verifiziert wurde, kann der Prozess, der nun über die Zahlungsinformationen und VIN-Verifizierung verfügt, ein Laden beginnen 211. Sobald das Laden abgeschlossen 213 ist, kann der Prozess eine Zahlungsanforderung an das identifizierte Zahlungskonto übermitteln 215. Der Prozess kann außerdem eine Quittung an das Fahrzeug, an die mobile Vorrichtung oder an eine andere Quelle senden 217.
-
Ein Beispiel für das Vorangehende würde wie folgt ablaufen: Ein Benutzer in einem Fahrzeug fährt an eine Ladestelle heran und interagiert auf eine gewisse Weise mit dem Ladegerät (nähert sich diesem an, aktiviert dieses usw.). Zusätzlich oder alternativ könnte die Ladestelle das Annähern erfassen. Die Ladestelle kann dann zum Beispiel eine Drahtloskommunikation von einem Schlüsselanhänger oder Fahrzeug empfangen, welche die VIN identifiziert. In einem weiteren Beispiel wird die VIN unter Umständen nicht identifiziert, bis das Ladekabel tatsächlich verbunden ist.
-
Sobald die VIN erhalten wurde, kann der Prozess entweder die VIN verifizieren (wenn eine gewisse Unklarheit besteht oder die Verifizierung anderweitig erforderlich ist) oder die VIN verwenden, um Zahlungsinformationen anzufordern. Wenn die VIN verifiziert werden soll, könnte das Ladegerät eine PIN oder Postleitzahl von einem Benutzer anfordern. Wenn die VIN ohne direkte Benutzerinteraktion verifiziert wurde, könnte der Prozess ein Abtasten bezüglich einer zweiten Quelle vornehmen, die den VIN verifizieren kann - wenn die VIN zum Beispiel von einem Schlüsselanhänger stammt, könnte das Ladegerät mit einem Fahrzeug kommunizieren, um sicherzustellen, dass ein Fahrzeug, das dieselbe VIN aufweist, ebenfalls anwesend ist. Wenn sowohl die VIN-Übertragung von dem Schlüsselanhänger als auch das Abtasten des Fahrzeugs drahtlos erfolgt ist, könnte dies selbstverständlich dazu führen, dass ein Schlüsselanhänger und Fahrzeug in der Nähe dem falschen Ladegerät zugewiesen werden, weshalb es nützlich sein kann, die sekundäre Verifizierungsfunktion von entweder einer direkten (verdrahteten) Verbindung (z. B. Einstecken in das Ladegerät) oder einem Funksignal mit sehr niedriger Reichweite und/oder einem gerichteten Funksignal ausgeschaltet zu haben.
-
Das Ladegerät kann außerdem die VIN (vor oder nach der Verifizierung) verwenden, um Zahlungsinformationen zu erhalten. In einem Beispiel können die Zahlungsinformationen cloudbasiert sein und könnte das Ladegerät die VIN an die Cloud übermitteln, um auf ein Zahlungskonto zuzugreifen. Hierfür könnte abhängig davon, wie die VIN erhalten wurde, eine Form von Identifizierung vor Ort erforderlich sein. In einem weiteren Beispiel können die Zahlungsinformationen in dem Fahrzeug oder Schlüsselanhänger gespeichert sein und könnte das Ladegerät die erfasste VIN zusammen mit einer Verifizierungsanforderung und Zahlungsinformationsanforderung an die zweite Einheit (das Fahrzeug oder den Schlüsselanhänger, der nicht die anfängliche Identifizierung bereitgestellt hat) senden. Dies ermöglicht es der verifizierenden Einheit, ebenfalls als Reaktion Zahlungsinformationen bereitzustellen, und weist die weitere Sicherheit auf, dass sowohl der Schlüsselanhänger als auch das Fahrzeug zumindest anwesend sein muss, um eine Zahlung zu verarbeiten.
-
In den vorangehenden Systemen kann die Art des Verarbeitens, die verwendet wird, um die VIN zu erhalten, von einem nachfolgenden Verifizierungsverfahren abhängig sein. Wenn der Benutzer eine PIN oder Postleitzahl eingibt und/oder wenn die VIN über eine Richtungsverbindung mit einem Fahrzeug, das die VIN aufweist, verifiziert wird, könnte zum Beispiel eine Funksignalerfassung mit längerer Reichweite verwendet werden, um die VIN eines beliebigen Fahrzeugs in der Umgebung, die das Ladegerät umgibt, anfangs zu erhalten. Das Ladegerät könnte sogar eine Liste mit VINs empfangen und da lediglich eine durch die Verbindung oder den Benutzercode verifiziert würde, könnte der Rest dann verworfen werden. Wenn die VIN durch andere Verfahren verifiziert wird, die über eine geringere Sicherheit bezüglich falscher positiver Ergebnisse verfügen könnten, kann das Erhalten der VIN durch ein Signal mit geringerer Reichweite vorgenommen werden, um eine Verwirrung weniger wahrscheinlich zu machen.
-
3A und 3B zeigen veranschaulichende Prozesse zur VIN-Erfassung. In dem in 3A gezeigten Beispiel, erhält das Ladegerät die VIN durch eine direkte Verbindung. Wenn das Ladegerät erfasst 301, dass ein Ladekabel mit dem Fahrzeug verbunden wurde, fragt 303 das Ladegerät die VIN von einer physischen Verbindung mit einem Fahrzeugnetzwerk an. Eine weitere Option würde darin bestehen, zum Beispiel einen Sendeempfänger mit kurzer Reichweite an dem Ladekabel einzuschließen, der zum Beispiel ein NFC- oder RFID-Signal von einem Transponder einlesen könnte, der sich in der Nähe von der Ladestelle befindet. Der Prozess empfängt 305 die VIN auf eine angemessene Weise und als Reaktion darauf, dass sich das Kabel in der Nähe des Fahrzeugs befindet oder damit verbunden ist.
-
In 3B erfasst 311 der gezeigte Prozess die Anwesenheit eines Fahrzeugschlüsselanhängers, auf dem eine VIN auf eine abrufbare Weise gespeichert ist. Der Prozess ruft 313 die VIN von dem Schlüsselanhänger ab und verwendet in diesem Beispiel eine direkte Verbindung mit einem Fahrzeug, um die VIN zu verifizieren. Wenn das Ladekabel nicht verbunden 315 ist, weist der Prozess den Benutzer 317 an, das Kabel zu verbinden. Sobald das Kabel verbunden wurde, kann der Prozess eine lokalisierte direkte oder drahtlose Verbindung verwenden, um die VIN zu verifizieren 319. Auch wenn es so scheinen kann, dass es sich hierbei um einen zu 3A ähnlichen Prozess handelt, kann der Prozess durch Erfassen der VIN von dem Schlüsselanhänger vor der Verbindung in der Lage sein, vorläufige Zahlungsinformationen und andere relevante Daten von einem Benutzerkonto abzurufen, noch bevor der Benutzer aus dem Fahrzeug aussteigt und mit dem Ladegerät interagiert. Hierdurch kann die Kundenerfahrung beschleunigt werden, da der Prozess bei Verbindung direkt mit dem Laden beginnen kann, solange die direkte Verbindung die VIN verifiziert, ohne dass die Schritte des Erhaltens und Verifizierens von Zahlungsinformationen, die auf Grundlage der VIN vorher erhalten werden können, vorgenommen werden müssen.
-
In einem abschließenden Verifizierungsprozess, der nicht gezeigt ist, könnte der Prozess die VIN entweder von dem Fahrzeug oder dem Schlüsselanhänger erhalten und dann eine Drahtloskommunikation mit dem anderen von dem Fahrzeug oder Schlüsselanhänger verwenden, um die erhaltene VIN zu verifizieren. Wenn das Ladegerät die Quelle für eine VIN unterscheiden kann, könnte der Prozess ein direktionales Signal, ein Signal mit einer sehr kurzen Reichweite oder eine Signalstärke (z. B. RSSI) verwenden, um eine zweite Verifizierungsquelle an einer für Verifizierungszwecke angemessenen Stelle zu bestimmen. Dies bedeutet, dass die sekundäre Quelle durch verschiedene Verfahren als sich annähernd oder sich etwa in der Nähe befindend erfasst werden könnte oder sich unter Umständen innerhalb einer Zone befinden müsste, um durch ein direktionales Signal erfasst zu werden.
-
4 zeigt einen veranschaulichenden Prozess zur Zahlungsverarbeitung. In diesem Beispiel verwendet der Prozess abhängig davon, wie die VIN anfangs erhalten wurde, eine variierte Form der sekundären Verifizierung. Bei einem beliebigen gegebenen Ladegerät kann es der Fall sein, dass lediglich einer der Aspekte dieser Lösung (oder etwas zu einem der Aspekte Ähnliches) umgesetzt wird; der veranschaulichte Prozess zeigt jedoch eine Lösung, die ausführbar ist, um die VINs anzugehen, die von einer Vielzahl von Quellen auf eine Vielzahl von Arten erhalten wurde.
-
In diesem Prozess bestimmt 401 der Prozess, ob die VIN von dem Schlüsselanhänger stammt. Wenn die VIN nicht von dem Schlüsselanhänger stammt, stammt die VIN (in diesem Beispiel) von dem Fahrzeug und verwendet der Prozess daher den Schlüsselanhänger zur Verifizierung, sodass der Prozess eine Abtastung 403 bezüglich eines Funksignals des Schlüsselanhängers vornimmt. Wenn kein Schlüsselanhänger aufgefunden 405 wird, kann der Prozess einen Benutzer bitten 419, eine PIN oder Postleitzahl (oder dergleichen) zur Verifizierung einzugeben. Der Prozess verbindet 421 sich dann mit der Cloud und verwendet dann die PIN zusammen mit der VIN, um Zahlungsinformationen zu erhalten 423. Die Cloud verifiziert 425 den Code (die PIN, Postleitzahl usw.) und ermöglicht, dass der Prozess eine Zahlung verarbeitet 431, wenn der Code richtig 427 ist. Wenn der Code falsch ist, wird die Zahlungsverwendungsanforderung abgelehnt 429.
-
Wenn das Erfassen eines Schlüsselanhängers durch den Prozess erfolgreich ist, fordert der Prozess von dem Schlüsselanhänger ebenfalls eine VIN 407 (zur Verifizierung der VIN, die ursprünglich von einer anderen Quelle stammt) an. Wenn die Schlüsselanhänger-VIN mit der Fahrzeug-VIN 409 übereinstimmt, bestimmt 411 der Prozess, ob der Schlüsselanhänger ebenfalls darauf gespeicherte Zahlungsinformationen beinhaltet. Wenn dies der Fall ist, erhält 413 der Prozess die Zahlungsinformationen von dem Schlüsselanhänger, der eine VIN aufweist, die mit der vorangehend empfangenen VIN übereinstimmt, und verarbeitet 415 die Zahlung. Wenn der Schlüsselanhänger keine Zahlungsinformationen aufweist, jedoch verwendet wird, um die VIN zu verifizieren, kann der Prozess einen Verifizierungscode anhängen 417 oder übertragen, der von dem Schlüsselanhänger abgerufen oder auf Grundlage der Bestätigung der VIN durch den Schlüsselanhänger generiert wurde und nutzbar ist, wenn sich das Ladegerät mit der Cloud verbindet, um Zahlungsinformationen zu erhalten. Dieser Code dient im Wesentlichen als ein Platzhalter für den Benutzereingabecode, da die VIN durch die Anwesenheit des Schlüsselanhängers verifiziert wurde.
-
Wenn die VIN ursprünglich von dem Schlüsselanhänger stammt, bestimmt 433 der Prozess, ob es dem Ladegerät gelungen ist, die VIN (z. B. von einer Benutzerverifizierung, zweiten Quelle usw.) zu verifizieren. Wenn das Ladegerät die VIN nicht verifiziert hat, bestimmt der Prozess, ob eine lokale fahrzeugbasierte Zahlungsabrufung erwünscht 437 ist. Wenn dies der Fall ist, kann der Prozess Zahlungsinformationen von dem Fahrzeug anfordern 439 und die nicht verifizierte VIN senden 441. Da das Fahrzeug vermutlich seine eigene VIN kennt, kann das Fahrzeug nun die VIN verifizieren 443, die mit der Zahlungsanforderung von dem Ladegerät übertragen wurde. Wenn die Verifizierung fehlschlägt, lehnt 445 das Ladegerät die Anforderung ab. Andernfalls erhält 447 das Ladegerät eine Zahlung und kann die Zahlung verarbeiten 449. In diesem Fall sendet das Fahrzeug die Zahlungsinformationen als Reaktion darauf zurück, dass eine richtige VIN mit der Anforderung übertragen wurde.
-
Wenn das Ladegerät die VIN (von dem Schlüsselanhänger) durch andere Mittel verifiziert, wie etwa einen Benutzereingabecode oder eine andere Verifizierung, bestimmt 435 der Prozess, ob eine lokale Zahlungslösung erwünscht ist. Wenn die lokale Zahlung erwünscht ist, kann der Prozess (der die VIN durch den Benutzer verifiziert hat) direkt Zahlungsinformationen von dem Schlüsselanhänger oder Fahrzeug anfordern (möglicherweise unter Verwendung des Verifizierungscodes oder in einem anderen Beispiel lediglich durch Anfordern der Zahlung, wenn die VIN vorher verifiziert wurde). Wenn eine cloudbasierte Zahlung (Remote-Zahlung) erwünscht ist, kann der Prozess wie zuvor einen Verifizierungscode anhängen und die Zahlungsanforderung zur Verarbeitung an die Cloud senden.
-
5A-5C zeigen veranschaulichende Prozesse zur Ladungseinführung. In dem in 5A gezeigten Beispiel erhält 501 der Prozess Zahlungsmittel durch eine der hierin beschriebenen Ausführungsformen oder dergleichen. Wenn die Zahlung durch einen der hierin beschriebenen Verifizierungsprozesse oder dergleichen erfolgreich verifiziert 503 wurde, stellt 505 der Prozess eine Option zum Beginnen des Ladens dar. Wenn der Benutzer die Option auswählt 507, beginnt 509 der Prozess mit dem Laden.
-
In diesem Beispiel wird der Prozess durch die manuelle Benutzerinteraktion begonnen. Es ist außerdem möglich, dass die Ladestation mit einem Fahrzeug interagiert und der Benutzer könnte die Taste zum Beginnen des Ladens an der Fahrzeugschnittstelle auswählen. Die Interaktion mit dem Fahrzeug könnte durch eine drahtlose Verbindung oder durch die physische Verbindung erfolgen, die mit einem eingesteckten Ladekabel aufgebaut wurde.
-
In dem in 5B gezeigte zweiten Beispiel wird der Prozess auf einem Benutzer-Smartphone oder Fahrzeug ausgeführt. In diesem Beispiel empfängt 511 der Prozess ein Funksignal von der Ladestation, wenn das Ladegerät verbunden 513 ist, was für einen Smartphone-Prozess oder einen fahrzeuginternen Prozess der Fall sein könnte. Alternativ könnte der auf einem Fahrzeug ausgeführte Prozess ein direktes Signal empfangen 511, wenn das Ladegerät verbunden 513 ist, oder könnte der auf einem Smartphone ausgeführt Prozess ein Funksignal von dem Fahrzeug empfangen 511, wenn das Ladekabel verbunden 513 ist. Die Schnittstelle (der Vorrichtung, auf welcher der Prozess ausgeführt wird) könnte als Reaktion auf das Signal, das eine Verbindung angibt, eine auswählbare Option darstellen 515. Wenn ein Benutzer die Option 517 drückt oder auswählt, kann der Prozess 519 anweisen, dass das Laden beginnt. Dies kann Senden eines Signals an das Fahrzeug, das Ladegerät oder beide von der Vorrichtung, die den Prozess ausführt, umfassen.
-
In dem in 5C gezeigten Beispiel ist der Prozess zum automatischen Laden konfiguriert. In diesem Einführungsmodell erhält 501 der Prozess Zahlungsinformationen (was durch ein beliebiges der veranschaulichten Beispiele oder dergleichen erfolgen kann). Wenn die Bezahlung verifiziert 503 wurde, bestimmt der Prozess 504, ob das automatische Laden gewählt wurde. Wenn das automatische Laden aktiviert wurde, wobei es sich um eine Funktion handelt, die der Benutzer bei Konfiguration der Ladeoptionen oder zu einem anderen Zeitpunkt aktivieren könnte, kann der Prozess automatisch bestimmen 506, dass ein Ladegerät verbunden ist, und das Laden 508 als Reaktion darauf beginnen.
-
Durch Verwenden der veranschaulichten Ausführungsformen können Benutzer Ladezahlungsoptionen auf eine Weise, die mit einer Vielzahl von Ladekonfigurationen nutzbar ist, auf praktische Weise konfigurieren und speichern. Abhängig von dem umgesetzten Modell kann der Benutzer dann Zahlungsinformationen erhalten und verifizieren lassen und das Laden problemlos beginnen und hierfür zahlen, wenn er sich einer Vielzahl von Ladestellen annähert, ohne dass er eine bestimmte Lösung bestimmen muss, die für die gegebene Ladestelle aktiviert ist.
-
Während vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht 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 Geist und Umfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener umsetzender Ausführungsformen auf logische Weise kombiniert werden, um situationsgerechte Variationen von hierin beschriebenen Ausführungsformen zu erzeugen.
-
Gemäß einer Ausführungsform wird das Zahlungskonto von einem cloudbasierten Server erhalten.
-
Gemäß einer Ausführungsform beinhaltet die Validierung Anfragen an einem Fahrzeug und wobei die Validierung erfolgreich ist, wenn das Fahrzeug dadurch auf die Anfrage reagiert, dass es die Fahrzeugkennung bereitstellt.
-
Gemäß der vorliegenden Erfindung beinhaltet ein computerimplementiertes Verfahren Empfangen einer Fahrzeugkennung als Reaktion auf Verbinden eines Ladekabels mit einem Fahrzeug und über eine Verbindung, die durch das Ladekabel aufgebaut wurde; Anfordern von Zahlungsinformationen von einem Cloud-Konto, wobei die Informationen der Fahrzeugkennung zugeordnet sind, die an das Cloud-Konto übertragen wurde; Beginnen eines Ladens des Fahrzeugs als Reaktion auf das Empfangen der Zahlungsinformationen; und Verwenden der Zahlungsinformationen zum Bezahlen für das Laden nach Abschluss des Ladens.
-
Gemäß der vorliegenden Erfindung beinhaltet ein computerimplementiertes Verfahren Empfangen einer Fahrzeugkennung drahtlos an einem Fahrzeugladegerät von einem Fahrzeugschlüsselanhänger; digitales Anfordern von Zahlungsinformationen, die der Fahrzeugkennung zugeordnet sind, wobei die Anforderung die Fahrzeugkennung beinhaltet; Verifizieren einer Genehmigung zur Verwendung der Zahlungsinformationen durch Anfragen an einer anderen Einheit als dem Fahrzeugschlüsselanhänger, wobei die Einheit die Zahlung durch Reagieren mit einer vordefinierten Verifizierung verifiziert; Beginnen des Ladens des Fahrzeugs als Reaktion auf das Verifizieren der Zahlungsinformationen; und Verwenden der Zahlungsinformationen zum Bezahlen für das Laden nach Abschluss des Ladens.
-
Gemäß einer Ausführungsform beinhaltet das Verifizieren Anfragen eines vordefinierten Verifizierungscodes bei einem Kunden über die Ladestation.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
