DE102016107712A1

DE102016107712A1 - Ridesharing-Reichweitenkonturen

Info

Publication number: DE102016107712A1
Application number: DE102016107712.7A
Authority: DE
Inventors: Yimin Liu; Perry Robinson MacNeille; Jinjing Yang
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-04-29
Filing date: 2016-04-26
Publication date: 2016-11-03
Also published as: US20160321771A1; MX2016005553A; CN106096749A; GB201607550D0; GB2539555A; RU2016116024A

Abstract

Ein Ridesharing-Server kann einen Satz Mitfahr-Nutzer innerhalb einer eine Fahrerroute umgebenden Reichweitenkontur identifizieren, die einen Schwellenwert von Kosten und/oder Zeit und/oder Insassenanzahl angibt; einen Satz Mitfahr-Optionen an eine Fahrereinrichtung senden, wobei die Mitfahr-Optionen die Mitfahr-Nutzer angeben; einen Satz Mitfahr-Optionen an eine Mitfahrereinrichtung senden; und von der Fahrereinrichtung eine Auswahl einer der Mitfahr-Optionen zum Mitnehmen eines der Mitfahr-Nutzer empfangen; von der Mitfahrereinrichtung eine Auswahl einer der Mitfahr-Optionen zum Reservieren eines der Ridesharing-Fahrer oder Stornierung einer Auswahl empfangen. Eine mobile Einrichtung kann vom Ridesharing-Server den Satz Mitfahr-Optionen empfangen; eine Nutzerschnittstelle anzeigen, die die Mitfahr-Optionen enthält; eine Auswahl einer der Mitfahr-Optionen zum Mitnehmen eines der Mitfahr-Nutzer empfangen; und die Auswahl an den Ridesharing-Server senden.

Description

TECHNISCHES GEBIET
Aspekte der Offenbarung beziehen sich im Allgemeinen auf ein multimodales Transportsystem, das die Tourenplanung, die Angebotsabgabe, das Anzeigen und die Tourenreservierung ermöglicht, einschließlich der Identifizierung von Reichweitenkonturen zur Verwendung beim Ridesharing.
HINTERGRUND
Ein multimodales Transportsystem ist ein System, bei dem Güter oder Passagiere unter Verwendung mehrerer Transportmodi transportiert werden können. Zu diesen Transportmodi können, als einige Beispiele, Busse, Züge, Flugzeuge, Autos, Fahrräder, Schiffe (z. B. Fähren, Kreuzfahrtschiffe usw.) und sogar das Gehen zählen, und zu ihnen kann das Reisen auf Wegen, wie zum Beispiel auf Straßen, Schienen, Einschienenbahnen, in Tunneln, auf dem Wasser und in der Luft, zählen. Multimodale Transportsysteme können den Wettbewerb zwischen Transportmodi fördern, wie zum Beispiel zwischen Massenverkehr, Mehrpersonenverkehr und Individualverkehr. Welcher Transportmodus dominiert, kann von kulturellen, finanziellen, geografischen, insassen- und ressourcenbedingten Vorgaben abhängen. Viele städtische Gebiete enthalten multimodale Transportsysteme, einschließlich einer Mischform aus öffentlichen Massenverkehrs- und Individualverkehrssystemen, die an Transportknotenpunkten miteinander verbunden sind.
KURZE DARSTELLUNG DER ERFINDUNG
In einer ersten veranschaulichenden Ausführungsform enthält ein System einen Ridesharing-Server, der zu Folgendem ausgelegt ist: einen Satz Mitfahr-Nutzer als innerhalb einer eine Fahrerroute umgebenden Reichweitenkontur zu identifizieren, die einen Schwellenwert von Kosten und/oder Zeit angibt; den Satz Mitfahr-Optionen an eine Fahrereinrichtung zu senden, wobei die Mitfahr-Optionen die Mitfahr-Nutzer angeben; und von der Einrichtung einer der Mitfahr-Optionen eine Auswahl zu empfangen, die eine Auswahl zum Mitnehmen eines der Mitfahr-Nutzer angibt.
In einer zweiten veranschaulichenden Ausführungsform enthält ein System eine mobile Einrichtung, die zu Folgendem ausgelegt ist: von einem Ridesharing-Server einen Satz Mitfahr-Optionen zu empfangen, die Ridesharing-Nutzer innerhalb einer eine Fahrerroute umgebenden Reichweitenkontur angeben, die einen Schwellenwert von Kosten und/oder Zeit angibt; eine Nutzerschnittstelle anzuzeigen, die die Mitfahr-Optionen beinhaltet; eine Auswahl einer der Mitfahr-Optionen zum Mitnehmen eines der Mitfahr-Nutzer zu empfangen; und die Auswahl an den Ridesharing-Server zu senden.
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren Folgendes: das Empfangen von Fahrernutzerpositionen von einer mobilen Einrichtung des Fahrers, die mit einem Fahrzeug verknüpft ist, das eine Fahrerroute befährt; Empfangen von Mitfahr-Nutzerpositionen von einer mobilen Passagiereinrichtung eines Mitfahr-Nutzers; Identifizieren des Mitnehmens des Mitfahr-Nutzers entsprechend Gemeinsamkeit der Fahrer- und der Mitfahr-Nutzerpositionen; und Senden einer Anforderung an die mobile Einrichtung des Fahrers und/oder die des Passagiers, um das Mitnehmen zu bestätigen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 veranschaulicht ein beispielhaftes Schema einschließlich eines Fahrzeugs, das dazu ausgelegt ist, auf Telematik-Server und eine mobile Einrichtung mit einer Tourenplanungsanwendung zuzugreifen;
2A veranschaulicht ein beispielhaftes Logikschema eines multimodalen Transportsystems;
2B veranschaulicht ein beispielhaftes Netzwerkschema des multimodalen Transportsystems;
3 veranschaulicht eine beispielhafte Nutzerschnittstelle der Tourenplanungsanwendung, die eine Route und Reichweitenkonturen anzeigt, die auf einer Karte eingeblendet werden;
4 veranschaulicht einen beispielhaften Datensatz, der mehrere Mitfahr-Optionen auf der Route enthält;
5 veranschaulicht eine beispielhafte Nutzerschnittstelle der Tourenplanungsanwendung zur Auswahl von Mitfahr-Optionen; und
6 veranschaulicht einen beispielhaften Prozess zum Durchführen von Ridesharing für mehrere Nutzer des multimodalen Transportsystems; und
7 veranschaulicht einen beispielhaften Prozess zum Annehmen von Ridesharing durch einen nicht fahrenden Nutzer des multimodalen Transportsystems.
AUSFÜHRLICHE BESCHREIBUNG
Wie erforderlich, werden hier ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; allerdings versteht es sich, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können übertrieben oder minimiert sein, um Details spezieller Komponenten zu zeigen. Daher sind hier offenbarte, spezifische strukturelle und funktionale Details nicht als einschränkend zu interpretieren, sondern lediglich als eine repräsentative Grundlage, um einen Fachmann über verschiedene Anwendungen der vorliegenden Erfindung zu unterrichten.
Ein multimodales Transportsystem kann ein System sein, bei dem Güter oder Passagiere möglicherweise unter Verwendung mehrerer Transportmodi transportiert werden, wie zum Beispiel zu Fuß, mit Fahrrädern, Motorrädern, Autos, Bussen, Flugzeugen, Wasserfahrzeugen und Schienenfahrzeugen, die dem Reisenden oder einem Teil einer Eigentümergruppe, zu der der Partner gehört, gehören oder von diesen geleast sind oder die für Vermietung oder Verleih verfügbar sind. Das multimodale Transportsystem kann Stränge multimodaler Knotenpunkte enthalten, die zum Beispiel durch ein schienengestütztes Massenverkehrssystem oder ein busgestütztes Schnellverkehrssystem verbunden sind. Zu den Knotenpunkten können Merkmale, wie zum Beispiel Parkplätze und Mietwagenplätze, zählen, wobei der Mietwagenplatz Stellplätze für Fahrzeuge, wie zum Beispiel Autos, Motorräder und Fahrräder, einschließt. Um jeden Knotenpunkt herum kann es Straßen, Fahrradstreifen und Gehwege geben, so dass Pendler unter Verwendung von Fahrrädern, Mietwagen oder zu Fuß zwischen Knotenpunkten oder zu den Knotenpunkten und Bestimmungsorten hin und von ihnen weg reisen können. In vielen Fällen werden wenigstens einige der Transportmodi auf Wegen betrieben, die für diesen Transportmodus bestimmt sind.
Zu einem Ridesharing-System kann eine Tourenplanungsanwendung zählen, die auf mobilen Einrichtungen des Nutzers installiert ist. Die Tourenplanungsanwendung kann dazu ausgelegt sein, sich mit einer fahrzeuginternen Computerplattform des Fahrzeugs zu verbinden und zu integrieren, wenn sich die mobile Einrichtung des Nutzers in der Drahtlosübertragungsreichweite eines Fahrzeugs befindet. Die Tourenplanungsanwendung kann dazu ausgelegt sein, Routenoptimierung in Übereinstimmung mit Informationen durchzuführen, die vom verbundenen Fahrzeug empfangen werden, wie Global Positioning Informationen. Die Tourenplanungsanwendung kann dazu ausgelegt sein, die Ridesharing-Entscheidungsfindung zu erleichtern, indem sie den Status von Fahrzeugrouten über die verschiedenen Transportmodi hinweg und Unterschiede hinsichtlich Kosten, zeitlichen und anderen Faktoren berücksichtigt, wie zum Beispiel die Kenngrößen der Mitfahrer, Routenauswahlregeln (z. B. Fahrspur für Fahrgemeinschaften, Parkgelegenheiten, Geschwindigkeitsbeschränkungen, Fahrzeuggewicht und -größe) und die Anzahl der Fahrzeuginsassen. Ridesharing-Fahrer, die die Tourenplanungsanwendung verwenden, können dementsprechend Zielkonflikte zwischen diesen Faktoren verstehen und Auswahlen auf Basis der Empfehlungen treffen (z. B. unter Verwendung der Mensch-Maschine-Schnittstelle (MMS) des Fahrzeugs, unter Verwendung der MMS der mobilen Einrichtung des Nutzers usw.). Die Tourenplanungsanwendung kann dazu ausgelegt sein, autonom, ohne Integration in die Fahrzeug-MMS, zu arbeiten, wenn sie sich außerhalb der Reichweite eines Fahrzeugs befindet.
Das System kann weiterhin dazu ausgelegt sein, sowohl Reichweitenkonturen für die Fahrer-Mitfahr-Nutzer zu bestimmen, als auch verfügbare Fahrzeugoptionen für die Passagier-Mitfahr-Nutzer. Diese Reichweitenkonturen können berechnet werden, indem für einen Fahrer eine effiziente Route (z. B. Routen, bei denen Fahrspuren für Fahrgemeinschaften verwendet werden) zu einem Bestimmungsort ermittelt wird, alternative Routenplanungspunkte, die die Route umgeben, identifiziert werden und bestimmt wird, welche Mitfahrer die Tour gemeinsam nutzen und auf der Route mitgenommen oder abgesetzt werden könnten. In einem Beispiel können die Konturen gebildet werden, indem Punkte auf jeder Route verbunden werden, die vom Fahrer bereitgestellte Ridesharing-Vorgaben erfüllen. In einem solchen System können ein Zeitraum, der für den Übergang zwischen Transportmodi an Knotenpunkten erforderlich ist, und eine verfügbare Fläche, die für eigene Fahrzeuge und für Mietfahrzeuge benötigt wird, entscheidend sein. Weil das System für Mitfahrer und für Fahrt-Anbieter komplex sein kann, kann von der Tourenplanungsanwendung eine Anzeige bereitgestellt werden, um die Nutzeridentifikation von Fahrten und Mitfahrern zu erleichtern. Weitere Aspekte des multimodalen Transportsystems und der Tourenplanungsanwendung werden hier ausführlicher erörtert.
Diese Anmeldung steht in Beziehung zu den gemeinsam übertragenen Anmeldungen mit der Seriennummer 14/699,217, gleichzeitig hiermit eingereicht und betitelt „RIDE-SHARING USER PATH DISTURBANCES AND USER RE-ROUTING“, mit der Seriennummer 14/699,241, gleichzeitig hiermit eingereicht und betitelt „RIDE-SHARING ROUTING USING CONTEXTUAL CONSTRAINTS“, mit der Seriennummer 14/699,268, gleichzeitig hiermit eingereicht und betitelt „RIDE-SHARING LONG-TERM RIDE-SHARE GROUPS“ und mit der Seriennummer 14/699,291, gleichzeitig hiermit eingereicht und betitelt „RIDE-SHARING JOINT-RENTAL GROUPS“, von denen jede hier durch Bezugnahme in ihrer Gänze einbezogen wird.
1 veranschaulicht ein beispielhaftes System 100 einschließlich eines Fahrzeugs 102, das dazu ausgelegt ist, auf Telematik-Server und eine mobile Einrichtung 152 mit einer Tourenplanungsanwendung 170 zuzugreifen. Zum Fahrzeug 102 können verschiedene Arten von Automobilen, wie zum Beispiel Crossover-Utility-Vehicles (CUV), Sport-Utility-Vehicles (SUV), Lastwagen, Freizeitfahrzeuge (RV), Boote, Flugzeuge oder andere mobile Maschinen zum Transportieren von Personen oder Gütern zählen. Zu Telematikdiensten können, als einige nicht einschränkende Möglichkeiten, Navigation, Turn-by-Turn-Wegbeschreibungen, Fahrzeugzustandsberichte, Suche nach lokalen Unternehmen, Unfallberichtswesen und Freisprechen zählen. In einem Beispiel kann das Fahrzeug 102 das SYNC-System, das von The Ford Motor Company aus Dearborn, Michigan, hergestellt wird, enthalten. Es sei darauf hingewiesen, dass das veranschaulichte System 100 lediglich ein Beispiel darstellt und dass mehr, weniger und/oder anders gelegene Elemente verwendet werden können.
Die Computerplattform 104 kann einen oder mehrere Prozessoren 106 enthalten, die dazu ausgelegt sind, Anweisungen, Befehle und andere Routinen als Unterstützung der hier beschriebenen Prozesse durchzuführen. Zum Beispiel kann die Computerplattform 104 dazu ausgelegt sein, Anweisungen von Fahrzeuganwendungen 110 auszuführen, um Merkmale, wie zum Beispiel Navigation, Unfallberichtswesen, Satellitenradiodecodierung und Freisprechen bereitzustellen. Solche Anweisungen und andere Daten können auf eine nichtflüchtige Weise unter Verwendung einer Vielzahl von Arten computerlesbarer Speichermedien 112 gehalten werden. Das computerlesbare Medium 112 (auch als ein prozessorlesbares Medium oder Speicher bezeichnet) enthält irgendein nichtflüchtiges Medium (z. B. ein dinghaftes Medium), das beim Bereitstellen von Anweisungen oder anderen Daten mitwirkt, die vom Prozessor 106 der Computerplattform 104 gelesen werden können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien erstellt werden, darunter, aber ohne Beschränkung, und entweder allein oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl und PL/SQL.
Die Computerplattform 104 kann mit verschiedenen Merkmalen versehen sein, die es den Fahrzeuginsassen erlauben, an die Computerplattform 104 anzukoppeln. Die Computerplattform 104 kann zum Beispiel Folgendes enthalten: einen Audioeingang 114, der dazu ausgelegt ist, gesprochene Befehle von Fahrzeuginsassen über ein verbundenes Mikrofon 116 zu empfangen, und einen Hilfsaudioeingang 118, der dazu ausgelegt ist, Audiosignale aus verbundenen Einrichtungen zu empfangen. Der Hilfsaudioeingang 118 kann eine physische Verbindung, wie zum Beispiel ein elektrischer Draht oder ein Glasfaserkabel, oder ein drahtloser Eingang, wie zum Beispiel eine Bluetooth-Audioverbindung, sein. In einigen Beispielen kann der Audioeingang 114 dazu ausgelegt sein, Audioverarbeitungsfähigkeiten, wie zum Beispiel die Vorverstärkung von Niederpegelsignalen, und Umwandlung analoger Eingaben in digitale Daten zur Verarbeitung durch den Prozessor 106 bereitzustellen.
Die Computerplattform 104 kann auch einen oder mehrere Audioausgänge 120 für einen Eingang eines Audiomoduls 122 bereitstellen, das Audiowiedergabefunktionalität aufweist. In anderen Beispielen kann die Computerplattform 104 die Audioausgabe für einen Insassen durch Verwendung eines oder mehrerer dedizierter Lautsprecher (nicht veranschaulicht) bereitstellen. Das Audiomodul 122 kann einen Eingangswahlschalter 124 beinhalten, der dazu ausgelegt ist, Audioinhalt aus einer ausgewählten Audioquelle 126 für einen Audioverstärker 128 zur Wiedergabe über die Fahrzeuglautsprecher 130 oder Kopfhörer (nicht veranschaulicht) bereitzustellen. Zu den Audioquellen 126 können, als einige Beispiele, decodierte, amplitudenmodulierte (AM) oder frequenzmodulierte (FM) Funksignale und Audiosignale aus der Audiowiedergabe von Compact Disc (CD) oder Digital Versatile Disk (DVD) zählen. Zu den Audioquellen 126 können auch Audiosignale zählen, die von der Computerplattform 104 empfangen werden, wie zum Beispiel Audioinhalt, der von der Computerplattform 104 generiert wird, Audioinhalt, der aus Flash-Speicherlaufwerken decodiert wird, die mit einem USB(Universal Serial Bus)-Subsystem 132 der Computerplattform 104 verbunden sind, und Audioinhalt, der vom Hilfsaudioeingang 118 über die Computerplattform 104 weitergeleitet wird.
Die Computerplattform 104 kann eine Sprachschnittstelle 134 nutzen, um eine Freisprechschnittstelle zur Computerplattform 104 bereitzustellen. Ein beispielhaftes System für gesprochenen Dialog wird im US-Patent 8,400,332 beschrieben, das hier in seiner Gänze durch Bezugnahme einbezogen wird. Die Sprachschnittstelle 134 kann Spracherkennung von Audiosignalen, die über das Mikrofon 116 empfangen werden, entsprechend Grammatik, die mit verfügbaren Befehlen assoziiert ist, und Generierung von Sprachaufforderungen für die Ausgabe über das Audiomodul 122 unterstützen. Die Sprachschnittstelle 134 kann probabilistische Spracherkennungstechniken nutzen, die die Grammatik im Vergleich zum Spracheingang verwenden. In vielen Fällen kann die Sprachschnittstelle 134 ein Standard-Nutzerprofil-Tuning zur Verwendung durch die Spracherkennungsfunktionen enthalten, um zu ermöglichen, dass die Spracherkennung richtig eingestellt wird, um im Durchschnitt gute Ergebnisse bereitzustellen, was beim Großteil der Erstnutzer zu positiven Erfahrungen führt. In einigen Fällen kann das System dazu ausgelegt sein, die vom Eingangswahlschalter 124 ausgewählte Audioquelle zeitweise stumm zu schalten oder anders außer Kraft zu setzen, wenn eine Audioaufforderung zur Darstellung durch die Computerplattform 104 bereitsteht und eine andere Audioquelle 126 zur Wiedergabe ausgewählt ist.
In einigen Beispielen kann eine Push-to-Talk-Taste dazu ausgelegt sein, zu bewirken, dass die Sprachschnittstelle 134 mit der Spracherkennung beginnt. In einem anderen Beispiel kann ein Merkmal „Offenes Mikrofon“ umgesetzt sein, bei dem der Nutzer einfach zu sprechen beginnt, ohne eine Taste zu drücken. Dies kann mit einem sprachgesteuerten Schalter (VOX, Voice Operated Switch) oder mit einer fortschrittlichen LVCSR-Maschine umgesetzt werden, die für einen vorbestimmten Satz aus Sätzen oder Wörtern aktiviert (z. B. einem Namen des Systems, gefolgt von Bitte, gefolgt von einem aus einem speziellen Satz Verben). Die Sprachschnittstelle 134 kann auch Dazwischensprechen unterstützen, wobei der Sprachsynthesizer eine Aufforderung bereitzustellen beginnt, bevor der Nutzer den Satz beendet hat (was für natürliche Sprache typisch ist, bei der ein Zuhörer zu sprechen beginnt, sobald er den Satz verstanden hat, jedoch bevor dieser abgeschlossen ist). Dazwischensprechen kann es einem Dialogsystem auch ermöglichen, absichtlich einen Dialog während Schweigepausen einzuleiten oder ein laufendes Gespräch zu unterbrechen. Dies kann als eine Taktik zum Mitteilen von Dringlichkeit verwendet werden, um dadurch die Aufmerksamkeit des Nutzers zu erhalten.
Die Computerplattform 104 kann auch Eingaben aus Mensch-Maschine-Schnittstellen(MMS)-Steuerelementen 136 empfangen, die dazu ausgelegt sind, für Interaktion der Insassen mit dem Fahrzeug 102 zu sorgen. Zum Beispiel kann sich die Computerplattform 104 an eine oder mehrere Tasten oder andere MMS-Steuerelemente ankoppeln, die dazu ausgelegt sind, Funktionen auf der Computerplattform 104 aufzurufen (z. B. Lenkrad-Audiotaster, eine Push-to-Talk-Taste, Armaturenbrett-Steuerelemente usw.). Die Computerplattform 104 kann auch ein oder mehrere Displays 138 ansteuern oder anders mit diesen kommunizieren, die dazu ausgelegt sind, visuelle Ausgaben für Fahrzeuginsassen mittels einer Videosteuerung 140 bereitzustellen. In einigen Fällen kann das Display 138 ein Touchscreen sein, der weiterhin dazu ausgelegt ist, Touch-Eingaben des Bedieners über die Videosteuerung 140 zu empfangen, während das Display 138 in anderen Fällen lediglich ein Display sein kann, ohne Berühreingabefähigkeiten.
Die Computerplattform 104 kann weiterhin dazu ausgelegt sein, über ein oder mehrere fahrzeuginterne Netzwerke 142 mit anderen Komponenten des Fahrzeugs 102 zu kommunizieren. Zu den fahrzeuginternen Netzwerken 142 können, als einige Beispiele, ein Fahrzeug-Controller-Area-Network (CAN), ein Ethernet-Netzwerk und ein Media Oriented System Transfer (MOST) zählen. Die fahrzeuginternen Netzwerke 142 können es der Computerplattform 104 ermöglichen, mit anderen Systemen des Fahrzeugs 102 zu kommunizieren, wie zum Beispiel mit einem Fahrzeugmodem 144 (das bei einigen Konfigurationen möglicherweise nicht vorhanden ist), mit einem Global Positioning System(GPS)-Modul 146, das dazu ausgelegt ist, aktuelle Positions- und Kursinformationen des Fahrzeugs 102 bereitzustellen, und mit verschiedenen Fahrzeug-ECUs 148, die dazu ausgelegt sind, mit der Computerplattform 104 zu kooperieren. Als einige nicht einschränkende Möglichkeiten können die Fahrzeug-ECUs 148 Folgendes enthalten: ein Antriebsstrangsteuermodul, das dazu ausgelegt ist, Steuerung von Motorbetriebskomponenten bereitzustellen (z. B. Leerlaufsteuerkomponenten, Kraftstoffzuführungskomponenten, Emissionssteuerkomponenten usw.) und Motorbetriebskomponenten (z. B. den Status von Motordiagnosecodes) zu überwachen; ein Karosseriesteuermodul, das dazu ausgelegt ist, verschiedene Leistungssteuerfunktionen zu managen, wie zum Beispiel Außenbeleuchtung, Innenbeleuchtung, schlüssellosen Zugang, Fernstarten und Zugangspunktstatusverifikation (z. B. Schließzustand der Motorhaube, der Türen und/oder des Kofferraums des Fahrzeugs 102); ein Funk-Transceiver-Modul, das dazu ausgelegt ist, mit Schlüsselanhängern oder anderen lokalen Einrichtungen des Fahrzeugs 102 zu kommunizieren; und ein Klimasteuerungs-Managementmodul, das dazu ausgelegt ist, Steuern und Überwachen von Heiz- und Kühlsystemkomponenten (z. B. Verdichterkupplungs- und Gebläselüftersteuerung, Temperatursensorinformationen usw.) bereitzustellen.
Wie gezeigt wird, können das Audiomodul 122 und die MMS-Steuerelemente 136 mit der Computerplattform 104 über ein erstes fahrzeuginternes Netzwerk 142-A kommunizieren, und das Fahrzeugmodem 144, das GPS-Modul 146 und die Fahrzeug-ECUs 148 können mit der Computerplattform 104 über ein zweites fahrzeuginternes Netzwerk 142-B kommunizieren. In anderen Beispielen kann die Computerplattform 104 mit mehr oder weniger fahrzeuginternen Netzwerken 142 verbunden sein. Zusätzlich oder alternativ können ein oder mehrere MMS-Steuerelemente 136 oder andere Komponenten mit der Computerplattform 104 über andere als die gezeigten fahrzeuginternen Netzwerke 142 oder direkt ohne eine Verbindung mit einem fahrzeuginternen Netzwerk 142 verbunden sein.
Die Computerplattform 104 kann auch dazu ausgelegt sein, mit mobilen Einrichtungen 152 der Fahrzeuginsassen zu kommunizieren. Die mobilen Einrichtungen 152 können irgendwelche von verschiedenen Arten tragbarer Computereinrichtungen sein, wie zum Beispiel Mobiltelefone, Tablet-Computer, Smartwatches, Laptop-Computer, tragbare Musik-Player, Wearable-Technology-Einrichtungen, E-Textilien oder andere Einrichtungen, die zur Kommunikation mit der Computerplattform 104 in der Lage sind. In vielen Beispielen kann die Computerplattform 104 einen drahtlosen Transceiver 150 enthalten (z. B. ein Bluetooth-Modul, einen ZigBee-Transceiver, einen WiFi-Transceiver, einen IrDA-Transceiver, einen RFID-Transceiver usw.), der dazu ausgelegt ist, mit einem kompatiblen drahtlosen Transceiver 154 der mobilen Einrichtung 152 zu kommunizieren. Zusätzlich oder alternativ kann die Computerplattform 104 mit der mobilen Einrichtung 152 über eine drahtgebundene Verbindung kommunizieren, wie zum Beispiel eine USB-Verbindung zwischen der mobilen Einrichtung 152 und dem USB-Subsystem 132. In einigen Beispielen kann die mobile Einrichtung 152 batteriebetrieben sein, während die mobile Einrichtung 152 in anderen Fällen wenigstens einen Teil ihrer Leistung aus dem Fahrzeug 102 über eine drahtgebundene Verbindung empfangen kann.
Das Kommunikationsnetzwerk 156 kann Kommunikationsdienste, wie zum Beispiel paketvermittelnde Netzwerkdienste (z. B. Internetzugang, VoIP-Kommunikationsdienste), für mit dem Kommunikationsnetzwerk 156 verbundene Einrichtungen bereitstellen. Zu einem Beispiel für ein Kommunikationsnetzwerk 156 kann ein zellulares Telefonnetzwerk zählen. Mobile Einrichtungen 152 können Netzkonnektivität zum Kommunikationsnetzwerk 156 über ein Einrichtungsmodem 158 der mobilen Einrichtung 152 bereitstellen. Um die Kommunikationen über das Kommunikationsnetzwerk 156 zu erleichtern, können die mobilen Einrichtungen 152 mit eindeutigen Einrichtungskennungen (z. B. Mobileinrichtungsnummern (MDNs), Internetprotokoll(IP)-Adressen usw.) verknüpft sein, um die Kommunikationen der mobilen Einrichtungen 152 über das Kommunikationsnetzwerk 156 zu identifizieren. In einigen Fällen können Insassen des Fahrzeugs 102 oder Einrichtungen, die die Erlaubnis haben, sich mit der Computerplattform 104 zu verbinden, von der Computerplattform 104 entsprechend Daten 160 gepaarter Einrichtungen identifiziert werden, die im Speichermedium 112 gehalten werden. Die Daten 160 gepaarter Einrichtungen können zum Beispiel die eindeutigen Einrichtungskennungen der mobilen Einrichtungen 152 angeben, die vorher mit der Computerplattform 104 des Fahrzeugs 102 gepaart worden sind, so dass sich die Computerplattform 104 automatisch, ohne Nutzereingriff, wieder mit den mobilen Einrichtungen 152 verbindet, auf die in den Daten 160 gepaarter Einrichtungen referenziert wird. In einigen Fahrzeugen 102 kann der drahtlose Transceiver 154 der Computerplattform 104 dazu ausgelegt sein, für mobile Einrichtungen 152 des Nutzers Hotspot-Funktionalität bereitzustellen.
Wenn eine mobile Einrichtung 152, die Netzwerkkonnektivität unterstützt, mit der Computerplattform 104 gepaart wird, kann die mobile Einrichtung 152 es der Computerplattform 104 ermöglichen, die Netzwerkkonnektivität des Einrichtungsmodems 158 zu verwenden, um mit dem entfernten Telematik-Server 162 oder anderen entfernten Computereinrichtungen über das Kommunikationsnetzwerk 156 zu kommunizieren. In einem Beispiel kann die Computerplattform 104 einen Data-over-Voice-Plan oder Datenplan der mobilen Einrichtung 152 nutzen, um Informationen zwischen der Computerplattform 104 und dem Kommunikationsnetzwerk 156 zu kommunizieren. Zusätzlich oder alternativ kann die Computerplattform 104 das Fahrzeugmodem 144 nutzen, um ohne Verwendung der Kommunikationsvorrichtungen der mobilen Einrichtung 152 Informationen zwischen der Computerplattform 104 und dem Kommunikationsnetzwerk 156 zu kommunizieren.
Ähnlich der Computerplattform 104 kann die mobile Einrichtung 152 einen oder mehrere Prozessoren 164 beinhalten, die dazu ausgelegt sind, Anweisungen von mobilen Anwendungen auszuführen, die vom Speichermedium 168 der mobilen Einrichtung 152 in einen Speicher 166 der mobilen Einrichtung 152 geladen worden sind. In einigen Beispielen können die mobilen Anwendungen dazu ausgelegt sein, mit der Computerplattform 104 über den drahtlosen Transceiver 154 und mit dem entfernten Telematik-Server 162 oder anderen Netzwerkdiensten über das Einrichtungsmodem 158 zu kommunizieren. Die Computerplattform 104 kann auch eine Einrichtungslinkschnittstelle 172 enthalten, um die Integration von Funktionalität der mobilen Anwendungen in die Grammatik von Befehlen, die über die Sprachschnittstelle 134 verfügbar sind, zu erleichtern. Die Einrichtungslinkschnittstelle 172 kann den mobilen Anwendungen auch Zugang zu Fahrzeuginformationen, die für die Computerplattform 104 verfügbar sind, über die fahrzeuginternen Netzwerke 142 bereitstellen. Ein Beispiel für eine Einrichtungslinkschnittstelle 172 kann die Komponente SYNC APPLINK des SYNC-Systems sein, das von The Ford Motor Company aus Dearborn, Michigan, bereitgestellt wird.
Eine Tourenplanungsanwendung 170 kann ein Beispiel für eine Anwendung sein, die auf der mobilen Einrichtung 152 installiert ist und die dazu ausgelegt ist, die Einrichtungslinkschnittstelle 172 zum Interagieren mit der Computerplattform 104 zu nutzen. Die Tourenplanungsanwendung 170 kann dazu ausgelegt sein, Informationen von Fahrzeugsensoren, -aktuatoren und elektronischen Steuereinheiten zu nutzen, die über den Fahrzeugbus 142 verfügbar gemacht worden sind, wenn sie mit dem Fahrzeug 102 verbunden ist. Die Tourenplanungsanwendung 170 kann auch dazu ausgelegt sein, zu arbeiten, wenn sie nicht mit dem Fahrzeug 102 verbunden ist, wie zum Beispiel, wenn der Nutzer öffentliche Transportmittel nutzt oder zu Fuß geht. Die Tourenplanungsanwendung 170 kann weiterhin dazu ausgelegt sein, mit Servern über das Kommunikationsnetzwerk 156 zu kommunizieren, wie nachstehend ausführlich erörtert wird. Der Nutzer kann mit der Tourenplanungsanwendung 170 über die MMS der mobilen Einrichtung 152, über eine Web-Schnittstelle oder über die MMS des Fahrzeugs 102 interagieren, um Ablenkung während des Fahrens zu vermeiden.
2A veranschaulicht ein beispielhaftes Logikschema eines multimodalen Transportsystems 200. Wie gezeigt wird, kann das multimodale Transportsystem 200 multimodale Knotenpunkte 202-A bis 202-F (gemeinsam 202) enthalten. Die multimodalen Knotenpunkte 202 können durch Massentransportsysteme 204 verbunden sein, wie zum Beispiel eines oder mehrere von Folgenden: ein schienengestütztes Massentransportsystem (z. B. Züge 204-A), ein luftgestütztes Massentransportsystem (z. B. Flugzeuge 204-B), ein straßengestütztes Transportsystem (z. B. Fahrräder 204-C, Busse 204-D usw.) und ein wassergestütztes Transportsystem (nicht veranschaulicht). Zum System 200 können Fahrzeuge 102, wie zum Beispiel Autos, Lastwagen, Fahrräder, Schienenfahrzeuge oder andere Transportfahrzeuge oder -einrichtungen, zählen, die die Wege 206 befahren können, um die Bewegung von Nutzers von Position zu Position zu erleichtern.
Die Knotenpunkte 202 können dazu ausgelegt sein, die Transportsysteme 204 für Nutzer des Systems 200 verfügbar zu machen. Zu den Transportsystemen 204 können, als einige Möglichkeiten, Ridesharing-Dienste, Mietfahrzeugdienste und Mietfahrraddienste zählen. Zu diesen Diensten kann ein Carsharing-Dienst, wie zum Beispiel die Tochtergesellschaft Zipcar der Avis Budget Group aus Cambridge, Massachusetts, ein Fahrrad-Sharing-Dienst, wie zum Beispiel das Fahrrad-Sharing-System Hubway aus Boston, Massachusetts, ein Taxidienst oder ein anderer Dienst zählen, bei dem die Fahrzeuge 102 gemietet oder zeitweise geliehen werden können (z. B. unter Verwendung der mobilen Einrichtung 152) oder für einen speziellen Zweck oder eine spezielle Tour (z. B. eine einfache Tour) genutzt werden können. Es sei auch angemerkt, dass die Nutzer in einigen Fällen ihre eigenen Fahrzeuge 102 nutzen können. Zum Beispiel muss ein Fahrer möglicherweise in einer Stadt für eine Konferenz anhalten und kann oder will keinen Parkplatz finden, also kann der Fahrer sein Fahrzeug 102 für das Ridesharing verfügbar machen, bis der Besitzer das Fahrzeug 102 wieder nutzen möchte. Die Knotenpunkte 202 können zum Abstellen der Fahrzeuge 102 der Transportsysteme 204 ausgelegt sein, wie zum Beispiel gemietete oder geliehene Fahrzeuge 102 in Erwartung eines Mitfahrers. Die Knotenpunkte 202 können zum Abstellen der Fahrzeuge 102 von Einzelpersonen ausgelegt sein, die diese typischerweise durch Leasing oder Eigentum besitzen. In einem Beispiel kann zu den Knotenpunkten 202 ein Parkplatz oder ein anderer Stellplatz für Verkehrsfahrzeuge 102 (z. B. Autos, Lastwagen, Fahrräder usw.), die Einzelpersonen gehören, und ein Mietwagenplatz oder anderer Stellplatz zum Abstellen von Mietverkehrsfahrzeugen 102 (z. B. Autos, Motorräder, Fahrräder usw.) zählen. Zu den Knotenpunkten 202 können zusätzlich oder alternativ ein oder mehrere Stellplätze für Flugzeuge, Züge usw. zählen, die häufig nicht Einzelpersonen gehören oder von ihnen geleast sind, sondern die Eigentum einer Firma oder der öffentlichen Hand sind oder von ihr geleast sind.
Weiterhin können sich die Knotenpunkte 202 in der Nähe eines oder mehrerer, zur Routenplanung fähiger Wege 206 (wie zum Beispiel Straßen, Fahrradstreifen und Fußwege) befinden, so dass Nutzer die Wege 206 befahren können, um zwischen Knotenpunkten 202 oder zwischen Knotenpunkten 202 und anderen Bestimmungsorten unter Verwendung der Fahrzeuge 102 oder zu Fuß zu reisen. In einigen Fällen können die Wege 206 gemeinsam, über Transportmodi hinweg, genutzt werden (z. B. eigene Fahrzeuge 102 und Taxifahrzeuge 102), während sich die Wege 206 in anderen Fällen entsprechend dem Transportmodus unterscheiden können (z. B. befahren Züge und Busse unterschiedliche Wege 206). Ein geordneter Satz von Wegen 206, die von einem Nutzer befahren werden können, um von einer Position zu einer anderen zu reisen, können hier als eine Route bezeichnet werden. Es sei angemerkt, dass die Terminologie zwischen oberirdischer, nautischer und aeronautischer Navigation variieren kann. Zum Beispiel können Automobil-Routenplanungssysteme auf einen Ausgangspunkt, einen Satz von Manövern und einen Bestimmungsort Bezug nehmen. Weiterhin kann es Wegpunkte geben, die durch Etappen zwischen jedem Manöver verbunden sind. Ein Manöver kann an einer Kreuzung stattfinden, und Wegpunkte zwischen Manövern beschreiben die Form der Straßen. Das Auswählen einer Route kann sequentiell erfolgen, z. B. durch Ausschließen der am wenigsten akzeptablen Routen und Einführen zusätzlicher Auswahlkriterien und Entfernen weiterer inakzeptabler Routen, bis eine Route ausgewählt worden ist. Allerdings können unerwartete oder unwahrscheinliche Ereignisse auftreten, und eine vorher inakzeptable Route wird bevorzugt. Bei dynamischer Routenplanung kann sich die Routenauswahl während der Fahrt ändern.
2B veranschaulicht ein beispielhaftes Netzwerkschema 200-B des multimodalen Transportsystems 200. Wie gezeigt wird, kann das Kommunikationsnetzwerk 156 die Kommunikation zwischen verschiedenen Komponenten unterstützen, wie zum Beispiel mobilen Einrichtungen 152 des Nutzers (ob er gerade in Fahrzeugen 102 fährt oder nicht), Ridesharing-Servern 208-A, 208-B, 208-C (gemeinsam 208), einem Mietfahrzeug-Server 210, einem Werbe-Server 212, einem Transaktions-Server 214, einer multimodalen Routenplanungsmaschine 216, einem Passagier-Reservierungssystem 218, einem Wetterdienst 220, einem Verkehrsdienst 222 und einem Karten-Server 224. Das System 200 kann viele verschiedene Formen annehmen und enthält mehrere und/oder alternative Komponenten und Vorrichtungen. Obwohl in 2B ein beispielhaftes System 200 gezeigt ist, ist nicht beabsichtigt, dass die beispielhaften, veranschaulichten Komponenten des Systems 200 einschränkend sein sollen. Tatsächlich können zusätzliche oder alternative Komponenten und/oder Umsetzungsformen verwendet werden. Als ein Beispiel: Ein Teil oder die gesamte Funktionalität der multimodalen Routenplanungsmaschine 216 kann in den Ridesharing-Server 208 integriert sein.
Die Ridesharing-Server 208 können dazu ausgelegt sein, die Fahrzeuge 102 des Systems 200 zu managen. Wie gezeigt wird, enthält das multimodale Transportsystem 200 mehrere Fahrzeuge 102-A bis 102-H (gemeinsam 102), die dazu ausgelegt sind, mit den Ridesharing-Servern 208 zu kommunizieren (z. B. mit oder ohne Verwendung der mobilen Einrichtung 152). Die Ridesharing-Server 208 können dazu ausgelegt sein, als Kontaktpunkte für die Nutzer der Tourenplanungsanwendung 170 zu dienen, um mit den Diensten des multimodalen Transportsystems 200 zu interagieren. Zu diesen Diensten können, als einige Möglichkeiten, dynamische Zwischentransportmodus-Optionen, das Planen von Touren für Ridesharing-Passagiere und -Fahrer (z. B. Sofort-Ridesharing, dynamisches Ridesharing, Ad-hoc-Ridesharing, dynamisches Bilden von Fahrgemeinschaften usw.) und Positionsverfolgung des Fahrzeugs 102 zählen. Die Ridesharing-Server 208 können dementsprechend Ridesharing-Dienste für Nutzer des Systems 200 bereitstellen, was es diesen ermöglicht, entweder in einem Knotenpunkt 202 oder bei Ankunft an einem Knotenpunkt 202 effizient eine Fahrgemeinschaft zu bilden. Dies kann die Bewegung durch den Transportknotenpunkt 202 entsprechend beschleunigen, indem Ridesharing-Partner automatisch während des Reisens mit dem Massentransportsystem 204 gefunden werden, anstatt dass versucht wird, ein Ad-hoc-Ridesharing am Transportknotenpunkt 202 vorzunehmen, z. B. bei Ankunft an einem Flughafen ein Taxi herbeizuwinken.
Die Ridesharing-Server 208 können weiterhin Dienste für andere Beteiligte als die Nutzer der Tourenplanungsanwendung 170 bereitstellen. Zum Beispiel können die Ridesharing-Server 208 Mitteilung für die Transportsysteme 204 bereitstellen, wenn ein spezieller Transportmodus durch einen Nutzer ausgewählt wird, was die Zuordnung von Fahrzeugen 102 zu Routen für die Nutzer des Systems 200 ermöglicht. In einem anderen Beispiel können Kurzzeit-Mietfahrzeuge 102 von einem Mietfahrzeug-Server 210 gemanagt werden. Die Kurzzeit-Mietfahrzeuge 102 können von den Nutzern über den Mietfahrzeug-Server 210 gebucht werden, und die Details des Mietvorgangs (z. B. Kosten, Miettage usw.) können den Ridesharing-Servern 208 zur Verwendung beim Erleichtern von Ridesharing unter Verwendung des gemieteten Fahrzeugs 102 bereitgestellt werden. Zum Beispiel können die Ridesharing-Server 208 gemietete Fahrzeuge 102 oder Ridesharing-Fahrzeuge 102, die für zusätzliche Etappen einer Reise verwendet werden sollen, für Nutzer identifizieren, die an einem Knotenpunkt 202 mit einem Massenverkehrstransportsystem 204 angekommen sind und ein Fahrzeug 102 benötigen, um sich an Ridesharing zu beteiligen, um zwischen dem Transportknotenpunkt 202 und einem endgültigen Bestimmungsort zu reisen.
Der Werbe-Server 212 kann dazu ausgelegt sein, Informationen aus Transportsystemen 204 zu sammeln, um Nutzer anzuziehen und spezielle Ermäßigungen als Ausgleich für Unannehmlichkeiten anzubieten, wie zum Beispiel das Ändern einer Tourenzeit usw. Der Werbe-Server 212 kann weiterhin dazu ausgelegt sein, eine Einnahmequelle für den Betrieb des Systems 200 bereitzustellen, obwohl das System 200 zusätzlich oder alternativ ein Abonnementsmodell zum Tragen von Betriebs- und Fixkosten verwenden kann.
Der Transaktions-Server 214 kann dazu ausgelegt sein, als ein Wallet-Server zu arbeiten, um einen Weg für Reisende bereitzustellen, von der mobilen Einrichtung 152 des Nutzers Fahrkarten zu erwerben, Fahrzeuge 102 zu mieten usw. In einem Beispiel kann der Transaktions-Server 214 dazu ausgelegt sein, Kontoinformationen für Nutzer des Systems zu managen, um es Nutzern sowohl zu erleichtern, Zahlungen für das gemeinsame Nutzen eines Fahrzeugs 102 vorzunehmen und zu empfangen, als auch Transaktionen über einen Rechnungszeitraum (z. B. 30 Tage usw.) anzusammeln, und einem Nutzer am Ende des Rechnungszeitraums ein Guthaben, eine Auszahlung oder eine Rechnung bereitzustellen. Dementsprechend kann der Transaktions-Server 214 das Durchführen von finanziellen Aspekten des Ridesharing ermöglichen, ohne dass in den Fahrzeugen 102 oder an den Knotenpunkten 202 Bargeld- oder Kredittransaktionen durchgeführt werden, was die Bewegung durch die Transportzentren beschleunigt, indem, als ein Beispiel, Stopps an Fahrkartenschaltern vermieden werden.
Die multimodale Routenplanungsmaschine 216 kann dazu ausgelegt sein, Routenplanungsdienste für das System 200 bereitzustellen, um Reisezeiten und -wege 206 für eine spezifische Tour zu identifizieren. Wie nachstehend ausführlich erörtert wird, kann die multimodale Routenplanungsmaschine 216 weiterhin dazu ausgelegt sein, Reichweitenkonturen für die Mitfahr-Nutzer zu bestimmen. Diese Reichweitenkonturen 308 können berechnet werden, indem eine effiziente Route für einen Fahrer zu einem Bestimmungsort ermittelt wird, alternative Routenplanungspunkte, die die Route 306 umgeben, identifiziert werden und bestimmt wird, welche Mitfahrer die Tour gemeinsam nutzen und auf der Route 306 mitgenommen oder abgesetzt werden könnten. In einem Beispiel können die Konturen 308 gebildet werden, indem Punkte auf jeder Route verbunden werden, die vom Fahrer bereitgestellte Ridesharing-Vorgaben erfüllen.
Die Ridesharing-Server 208 können weiterhin dazu ausgelegt sein, auch mit anderen, Netzwerk verknüpften Informationsquellen zu kommunizieren. In einem Beispiel kann der Ridesharing-Server 208 dazu ausgelegt sein, Informationen von einem Passagier-Reservierungssystem 218 eines Transportsystems 204 zu empfangen, wie zum Beispiel Fahrkarteninformationen und Zug- oder andere Planungsinformationen. In einem anderen Beispiel können die Ridesharing-Server 208 dazu ausgelegt sein, Informationen von einem Wetterdienst 220 zu empfangen, der dazu ausgelegt ist, Informationen bereitzustellen, die historisierte, aktuelle und/oder prognostizierte Umgebungsbedingungen angeben. In einem weiteren Beispiel können die Ridesharing-Server 208 dazu ausgelegt sein, Informationen von einem Verkehrsdienst 222 zu empfangen, der dazu ausgelegt ist, Informationen bereitzustellen, die historisierte, aktuelle und/oder prognostizierte Verkehrsbedingungen für den Weg 206 angeben. In noch einem weiteren Beispiel können die Ridesharing-Server 208 dazu ausgelegt sein, Karteninformationen zu empfangen, wie zum Beispiel Informationen zum Weg 206 und Informationen zur Route 306 aus dem Karten-Server 224.
3 veranschaulicht eine beispielhafte Nutzerschnittstelle 300 der Tourenplanungsanwendung 170, die eine Route 306 und Reichweitenkonturen 308 anzeigt, die auf einer Karte 302 eingeblendet werden. Die Nutzerschnittstelle 300 kann von der Nutzer-Tourenplanungsanwendung 170 über ein Display der mobilen Einrichtung 152 dargestellt werden. Als eine andere Möglichkeit kann, in Fällen, in denen die mobile Einrichtung 152 mit der Computerplattform 104 des Fahrzeugs 102 verbunden ist, die Nutzerschnittstelle 300 dem Nutzer über ein Display des Fahrzeugs 102 über die Verbindung Fahrzeug-Mobileinrichtung bereitgestellt werden.
Wie in der Nutzerschnittstelle 300 veranschaulicht wird, kann die Karte 302 einen Teil des multimodalen Transportsystems 200 veranschaulichen. Die Route 306 kann auf der Karte 302 eingeblendet werden und kann weiterhin eine oder mehrere Positionsangaben 304 enthalten. Die Route 306 kann einen geordneten Satz aus einem oder mehreren Wegen 206 enthalten, die von einem Nutzer befahren werden können, um von einer Positionsangabe 304 zu einer anderen zu gelangen. Die Positionsangaben 304 können entsprechend sowohl Ausgangs- oder Bestimmungsorte des Nutzers auf der Route 306 angeben, als auch Positionen anderer Nutzer und andere Nutzerbestimmungsorte innerhalb des veranschaulichten Teils des multimodalen Transportsystems 200. Die Reichweitenkonturen 308 können visuell Kosten- und/oder Zeitschwellenwerte angeben, die auf Nutzereinstellungen basieren, die für den Nutzer der Tourenplanungsanwendung 170 beim Bestimmen nützlich sein können, ob er das Fahrzeug 102 mit anderen Nutzern gemeinsam nutzen wird.
Zum Beispiel wird ein Nutzer der Tourenplanungsanwendung 170 betrachtet, der von der Positionsangabe 304-A zur Positionsangabe 304-B steuert und der ein Fahrzeug 102 bei einem Mietfahrzeug-Server 210, der in Kommunikation mit einem Ridesharing-Server 208 steht, reserviert hat. Auf oder in der Nähe der Route des Nutzers von der Positionsangabe 304-A zur Positionsangabe 304-B können sich etliche andere Nutzer aufhalten, die möglicherweise ebenso einen Bestimmungsort auf oder in der Nähe der Route 306 erreichen möchten. In einem Beispiel kann sich ein Nutzer „David“ an der Positionsangabe 304-C befinden und möchte möglicherweise die Positionsangabe 304-E erreichen. In einem anderen Beispiel kann sich eine Nutzerin „Nancy“ an der Positionsangabe 304-D befinden und möchte möglicherweise auch die Positionsangabe 304-E erreichen. Wie gezeigt wird, befinden sich die Nutzer an den Positionsangaben 304-C und 304-D in der Nähe der Route 306 von der Positionsangabe 304-A zur Positionsangabe 304-B und können dazu bereit sein, entweder ihr eigenes Fahrzeug 102 zu reservieren (z. B. über die Buchungsdienste des Fahrzeugs 102 des Ridesharing-Servers 208 und den Mietfahrzeug-Server 210) oder als Teil einer Tour eines anderen Nutzers mitzufahren (z. B. über die Ridesharing-Dienste des Ridesharing-Servers 208).
4 veranschaulicht einen beispielhaften Datensatz 400, der mehrere Mitfahr-Optionen 402 auf der Route 306 enthält. Der Ridesharing-Server 208 kann dazu ausgelegt sein, vor dem oder während des Befahrens der Route 306 eine oder mehrere Mitfahr-Optionen 402 an die Tourenplanungsanwendung 170 der mobilen Einrichtung 152 des Nutzers zu senden. Zu diesen Mitfahr-Optionen 402 können zum Beispiel Zahlungsbeträge für das gemeinsame Nutzen des Fahrzeugs 102, Schätzwerte für Reisezeitunterschiede beim gemeinsamen Nutzen des Fahrzeugs 102, Gesamtanzahl der Mitfahrer und andere Informationen in Bezug auf die potentiellen Mitfahr-Optionen 402 zählen.
Unter Fortsetzung des Beispiels von der Nutzerschnittstelle 300: Der veranschaulichte Datensatz 400 gibt drei Mitfahr-Optionen 402-A, 402-B und 402-C an. Die Mitfahr-Option 402-A kann Aspekte eines Szenarios „Kein Mitnehmen“ angeben, bei dem kein Ridesharing durchgeführt wird, einschließlich Basisbetriebskosten (z. B. 50 $ an Kraftstoff- und Mietkosten), einer Basis-Reisezeit und einer Basisanzahl von Mitfahrern. In einigen Beispielen können zum Datensatz 400 Werte zählen, die vom Ridesharing-Server 208 für eines oder mehrere der Folgenden, Betriebskosten, Reisezeit und Anzahl Mitfahrer, bereitgestellt werden, falls sie dem Ridesharing-Server 208 bekannt sind. Die Reisezeitdaten können in einem Beispiel auf Basis von Daten für die Route 306 berechnet werden, die für den Ridesharing-Server 208 verfügbar sind, wie zum Beispiel Wetterinformationen, die vom Wetterdienst 220 abgerufen oder anders empfangen werden, Verkehrsinformationen für die Wege 206 der Route, die vom Verkehrsdienst 222 abgerufen oder anders empfangen werden, und Informationen in Bezug auf die zugrunde liegenden Wege 206, wie zum Beispiel Entfernung, Geschwindigkeitsbeschränkung und durchschnittliche Reisezeit. Die Betriebskostendaten können in einem Beispiel auf Basis von Daten für die Route 306 berechnet werden, die für den Ridesharing-Server 208 verfügbar sind, wie zum Beispiel die berechneten Reisezeitdaten, Kraftstoffwirkungsgradinformationen für das Fahrzeug 102 (z. B. auf Basis des Modells des Fahrzeugs 102 oder aus dem Mietfahrzeug-Server 210 abgerufener, historisierter Informationen), Kraftstoffkosteninformationen (z. B. Kraftstoffart/-energiegehalt, durchschnittlicher Benzinpreis für einen Postleitzahlenbereich oder ein anderes Ortsgebiet, in dem sich das Fahrzeug 102 befindet (z. B. die Position, wie sie entsprechend dem GPS-Modul 146 bestimmt wird)) und Tages-, Laufleistungs- oder anderer Mietpreis für das Fahrzeug 102, die aus dem Mietfahrzeug-Server 210 abgerufen werden. Als eine Möglichkeit können die Betriebskosten als eine stochastische Variable mit Unsicherheit aufgrund von Verteilung von Fahrerverhaltensweisen geschätzt werden. Bei den Betriebskosten können auch das Braess-Paradoxon und die Betriebskosten für das System berücksichtigt werden. Zum Beispiel ist für einen Fahrer ein Kostenfaktor die Zeit, für eine Person, die das Fahrzeug 102 betankt und unterhält, können zu Betriebskosten monetäre Kosten und Zeit zählen. Für das Transportsystem kann zu den Betriebskosten der Einfluss auf den Gesamtdurchsatz des Systems zählen. Eine Änderung im Wirkungsgrad und/oder eine Änderung im Durchsatz aufgrund von Ridesharing kann dementsprechend in den Betriebskosten berücksichtigt werden.
Die Mitfahr-Option 402-B kann Aspekte eines Szenarios beinhalten, bei denen der Fahrernutzer des Fahrzeugs 102 zusätzlich den Nutzer „David“ an der Positionsangabe 304-C mitnimmt, um ihn an der Positionsangabe 304-E abzusetzen. In einigen Beispielen kann der Datensatz 400 die Aspekte der Mitfahr-Option 402-B als Werte in Bezug auf die Mitfahr-Option 402-A spezifizieren (oder auf die aktuelle Mitfahr-Optionen 402-A). Zum Beispiel können sich die Betriebskosten in solch einem alternativen Szenario um 20 $ verringern (z. B. aufgrund von Zahlung an den Fahrernutzer von Davids Konto), die Reisezeit kann sich um fünfzehn Minuten erhöhen, und die Anzahl der Mitfahrer kann sich um einen erhöhen. In anderen Beispielen kann der Datensatz 400 die Aspekte der Mitfahr-Option 402-B als unabhängige Werte für jede der Mitfahr-Optionen 402 spezifizieren. Der Datensatz 400 kann weiterhin andere Informationen angeben, wie zum Beispiel, falls die Option 402-B ausgewählt ist, dass Fahrspuren für Fahrgemeinschaften bei Verwendung des Fahrzeugs 102 verfügbar werden.
Die Mitfahr-Option 402-C kann Aspekte eines Szenarios beinhalten, bei dem der Fahrernutzer des Fahrzeugs 102 die Nutzerin „Nancy“ an der Positionsangabe 304-D mitnimmt, um sie an der Positionsangabe 304-E abzusetzen. Zum Beispiel können sich die Betriebskosten in solch einem alternativen Szenario um 10 $ verringern (z. B. aufgrund von Zahlung an den Fahrernutzer von Nancys Konto), die Reisezeit kann sich um fünf Minuten erhöhen, und die Anzahl der Mitfahrer kann sich gegenüber der aktuellen Anzahl um zwei erhöhen.
5 veranschaulicht eine beispielhafte Nutzerschnittstelle 500 der Tourenplanungsanwendung 170 zur Auswahl von Mitfahr-Optionen 402. Wie veranschaulicht wird, kann die Nutzerschnittstelle 500 dem Nutzer der Tourenplanungsanwendung 170 über ein Display der mobilen Einrichtung 152 dargestellt werden. Als eine andere Möglichkeit kann die Nutzerschnittstelle 500 dem Nutzer über ein Display eines gepaarten Fahrzeugs 102 bereitgestellt werden.
Die Nutzerschnittstelle 500 kann ein Listensteuerelement 504 beinhalten, das dazu ausgelegt ist, eine Auflistung von Mitfahr-Optionen 402 der Datenkriterien anzuzeigen, die vom Nutzer ausgewählt werden können. Wie gezeigt wird, wird jede der Mitfahr-Optionen 402 als einer von mehreren auswählbaren Listeneinträgen 506 angezeigt. Die Nutzerschnittstelle 500 kann auch eine Titelbezeichnung 508 beinhalten, um dem Nutzer anzuzeigen, dass die Nutzerschnittstelle 500 zur Auswahl der Mitfahr-Optionen 402 dient.
Wie veranschaulicht wird, enthält das Listensteuerelement 504 der Tourenplanungsanwendung 170 einen Eintrag 506-A zum Fahren mit David, wie in der Mitfahr-Option 402-B spezifiziert, einen Eintrag 506-B zum Fahren mit Nancy, wie in der Mitfahr-Option 402-C spezifiziert, einen Eintrag 506-C zum Fortsetzen des Alleinfahrens 168, wie in der Mitfahr-Option 402-A spezifiziert, und einen Eintrag 506-D zum Verschieben der Entscheidung, ob Ridesharing gemacht werden soll. Es sei angemerkt, dass die genauen Optionen, die Anzahl der Optionen und die Reihenfolge der Optionen lediglich ein Beispiel darstellen. Zum Beispiel kann die Nutzerschnittstelle 500 in einem alternativen Beispiel den Nutzer auffordern: „Zwei Personen auf der Route müssen mitgenommen werden und würden gerne nach [Positionsangabe 304-E] fahren; möchten Sie sie mitnehmen und einige Kosten einsparen?“ (Es sei angemerkt, dass die Nutzerschnittstelle 500 in anderen Beispielen von Mitfahrern verwendet werden kann, um Fahrzeuge 102 zum Mitfahren auszuwählen.)
Das Listensteuerelement 504 kann als ein Menü arbeiten, so dass ein Nutzer der Nutzerschnittstelle 500 sowohl in der Lage sein kann, durch die Listeneinträge des Listensteuerelements 504 zu scrollen, um einen aktuell ausgewählten Listeneintrag 510 anzupassen (z. B. unter Verwendung von Auf- und Ab-Pfeiltasten), als auch den aktuell ausgewählten Listeneintrag 510 aufzurufen (z. B. unter Verwendung einer Auswahltaste). In einigen Fällen kann das Listensteuerelement 504 auf einem Touchscreen-Display angezeigt werden, so dass der Nutzer in der Lage sein kann, das Listensteuerelement 504 zu berühren, um einen Menüpunkt auszuwählen und aufzurufen. Als anderes Beispiel kann die Nutzerschnittstelle 500 eine Sprachbefehlsauswahl der Menüpunkte unterstützen. Um zum Beispiel das Mitnehmen von David auszuwählen, kann der Nutzer eine Push-to-Talk-Taste drücken oder ein Sprachbefehls-Einleitungsschlüsselwort sagen und den Sprachbefehl „Fahrt mit David“ oder „Mitfahr-Option 1 wählen“ sprechen.
Die Tourenplanungsanwendung 170 kann dazu ausgelegt sein, als Reaktion auf die Auswahl des Nutzers die Auswahl an den Ridesharing-Server 208 zu senden. Die Tourenplanungsanwendung 170 kann weiterhin dazu ausgelegt sein, dem Ridesharing-Server 208 Positionsaktualisierungen der Position des Fahrzeugs 102 bereitzustellen, um dem Ridesharing-Server 208 zu ermöglichen, Aktualisierungen für die anderen Nutzer in Bezug auf den Status der Fahrt des gemeinsam genutzten Fahrzeugs 102 bereitzustellen.
Die Tourenplanungsanwendung 170 kann dazu ausgelegt sein, wenn das Fahrzeug 102 in einem Beispiel die Route 306 befährt und die Position des Fahrzeugs 102 (wie sie z. B. über das GPS-Modul 146 bestimmt wird) in eine vorbestimmte Entfernung von der Positionsangabe 304-C kommt, die Positionsangabe 304-C, die auf der Karte 302 des Fahrers angezeigt wird, blinken zu lassen oder anders hervorzuheben. Gleichermaßen können die Nutzer, wenn Nutzer im Fahrzeug 102 fahren, in der Lage sein, die Tourenplanungsanwendung 170 zu nutzen, um eine nächste Etappe der Route 306 zu prüfen. Falls zum Beispiel der Nutzer dazu eingeplant ist, ein erstes Ridesharing-Fahrzeug 102 zu verlassen, um in ein zweites Ridesharing-Fahrzeug 102 einzusteigen, kann die Position des nächsten Ridesharing-Fahrzeugs 102 für den Nutzer auf der Karte 302 veranschaulicht werden.
Zusätzlich oder alternativ kann der Ridesharing-Server 208 den Nutzer, der mitgenommen werden soll (in diesem Beispiel z. B. David), über die erwartete Wartezeit bis zur Fahrzeugankunft informieren. In einem Beispiel kann ein Nutzer, der darauf wartet, mitgenommen zu werden, Informationen vom Ridesharing-Server 208 in Bezug auf den Status des Mitnehmens empfangen. In einem Beispiel kann der Nutzer, der das Mitnehmen erwartet, seine mobile Einrichtung 152 nutzen, die die Tourenplanungsanwendung 170 ausführt, um Fahrzeugpositionsverfolgungs-Informationen anzusehen, die die Position des Fahrzeugs 102 angeben, das ihn mitnehmen wird. Als eine zusätzliche oder alternative Möglichkeit kann die Tourenplanungsanwendung 170 Informationen vom Ridesharing-Server 208 empfangen, die die Farbe, die Marke und/oder das Modell des Fahrzeugs 102 angeben, das den Nutzer mitnehmen soll. Auf die Informationen in Bezug auf das Fahrzeug 102, das das Mitnehmen durchführt, kann vom Ridesharing-Server 208 auf dem Mietfahrzeug-Server 210 zugegriffen werden.
Sobald der Nutzer oder die Nutzer mitgenommen worden sind, kann der Fahrer die Tourenplanungsanwendung 170 nutzen, um den Ridesharing-Server 208 über das Mitnehmen zu informieren. In einem Beispiel kann der Nutzer einen Befehl der Tourenplanungsanwendung 170 auswählen (z. B. eine Taste drücken, die angibt, dass der bzw. die Nutzer, die ausgewählt worden waren, an der Positionsangabe 304 mitgenommen zu werden, mitgenommen worden sind). In einem anderen Beispiel kann der Nutzer einen Sprachbefehl oder einen anderen Eingabemechanismus nutzen, um die Tourenplanungsanwendung 170 zu informieren. Zusätzlich oder alternativ kann der Nutzer, der mitgenommen wird, unter Verwendung der Tourenplanungsanwendung 170 seiner mobilen Einrichtung 152 melden, dass er vom Fahrzeug 102 mitgenommen worden ist. Als noch ein weiteres zusätzliches oder alternatives Beispiel können beide Tourenplanungsanwendungen 170, die des Fahrers und die des bzw. der mitzunehmenden Nutzer, Positionsaktualisierungen an den Ridesharing-Server 208 senden, und der Ridesharing-Server 208 kann auf Basis der Gemeinsamkeit der Positionsänderung ableiten, dass die Nutzer zusammen im Fahrzeug 102 fahren.
Es sei angemerkt, dass die monetären Aspekte der Transaktion zwischen dem Fahrer und den Nutzern, die die Fahrt gemeinsam nutzen, unter Verwendung der Dienste des Ridesharing-Servers 208 durchgeführt werden können. Anstatt dass zum Beispiel eine monetäre Transaktion zwischen dem Fahrer und dem Mitfahrer stattfindet, kann der Ridesharing-Server 208 dazu ausgelegt sein, den Transaktions-Server 214 darüber zu informieren, finanzielle Mittel von einem Konto des Mitfahrers auf ein Konto des Fahrers zu übertragen. In einem anderen Beispiel können der Ridesharing-Server 208 und/oder der Transaktions-Server 214 Transaktionen über einen Abrechnungszeitraum (z. B. 30 Tage usw.) ansammeln und dem Nutzer am Ende des Abrechnungszeitraums ein Guthaben, eine Auszahlung oder eine Rechnung bereitstellen. In einem anderen Beispiel kann eine Kryptowährung oder Scrip-Geld verwendet werden, um finanzielle Mittel zu übertragen (z. B. die in Hong Kong genutzte Octopus Card, die auf den Philippinen genutzte SMART Communication Pasaload, Bitcoin usw.). In einigen Beispielen können Übertragungen gebündelt und aufgerechnet werden, weil sich mehrere kleinere Transaktionen gegeneinander aufheben können.
Dementsprechend kann das System 200 den Nutzern Kosten und Zeit ersparen, z. B. könnte der Nutzer das Fahrzeug 102 mit zusätzlichen Insassen im Fahrzeug 102 auf der Fahrspur für Fahrgemeinschaften fahren. Das System 200 kann auch soziale Netzwerke oder soziale Beziehungen zwischen Leuten aufbauen und widerspiegeln. Zusätzlich können die Nutzer in der Lage sein, Probleme mit der Privatsphäre zu vermeiden, weil Informationen zu Kreditkarten und zu Privatanschriften nicht mit dem Fahrer des Fahrzeugs 102, der die Mitfahrer zu ihren Bestimmungsorten fährt, geteilt werden. Weiterhin kann das System 200 den Mitfahrern ermöglichen, die Fahrer für zukünftige Mitfahrer zu bewerten, was es den Mitfahrern ermöglicht, auf Basis der Bewertung oder des Preises zu bestimmen, welche Fahrt gewählt werden soll, wenn es mehrere Fahrer gibt, die Fahrten anbieten.
Mit Rückbezug auf 3: Die Nutzerschnittstelle 300 kann dazu ausgelegt sein, dem Fahrer Mitfahreroptionen und -abwägungen anzuzeigen. (Z. B. kann die Tourenplanungsanwendung 170 eine Option bereitstellen, um einem Nutzer zu ermöglichen, zwischen der Nutzerschnittstelle 300 und der Nutzerschnittstelle 500 umzuschalten.) In einem Beispiel können die Reichweitenkonturen 308 veranschaulichen, wie weit der Fahrer möglicherweise für ein Mitnehmen zu unterschiedlichen Mitnahmepreisen (z. B. eine 20-$-Kontur) oder mit unterschiedlichen Zeitaufwänden (z. B. eine 20-Minuten-Kontur) reist. In einem Beispiel kann die Tourenplanungsanwendung 170 dem Nutzer ermöglichen, die spezifischen Kriterien zu bearbeiten, die zur Generierung der Reichweitenkonturen 308 verwendet werden. Wie gezeigt wird, kann die Reichweitenkontur 308-A auf dem Kriterium basieren, dass Routen ungefähr 20 $ wert sind, und die Reichweitenkontur 308-B kann auf dem Kriterium basieren, dass Routen ungefähr 30 $ wert sind. Es sei angemerkt, dass die veranschaulichten Reichweitenkonturen 308 lediglich Beispiele sind und dass mehr, weniger und/oder Reichweitenkonturen 308 mit anderen Kriterien verwendet werden können.
Ähnlich wie die Berechnung der Betriebskosten und der Reisezeit für die Mitfahr-Optionen 402 des Datensatzes 400 können die Reichweitenkonturen 308 auf Basis des Ridesharing-Servers 208 berechnet werden, der auf verschiedenen Datenelementen basiert. Wenn die Reichweitenkonturen 308 modelliert werden, kann der Ridesharing-Server 208 die Kartendaten nutzen, um Punkte auf der Route 306 und auf anderen Wegen, die sich über von der Route 306 abzweigende Straßen ausbreiten, zu positionieren.
Zum Erstellen der Reichweitenkonturen 308 kann der Ridesharing-Server 208 dazu ausgelegt sein, die Punkte auf der Route 306 und benachbarte Wege mit gleichen Mitnahmepreis- oder Zeitkostenschätzwerten zu verbinden. Zur Berechnung einer Reichweitenkontur 308 auf Reisezeitbasis können die Grenzen der Reichweitenkontur 308 in einem Beispiel für die Punkte auf der Route 306 und benachbarte Wege unter Verwendung von Informationen berechnet werden, die für den Ridesharing-Server 208 verfügbar sind, wie zum Beispiel Wetterinformationen, die vom Wetterdienst 220 abgerufen oder anders empfangen werden, Verkehrsinformationen für die Wege 206, die vom Verkehrsdienst 222 abgerufen oder anders empfangen werden, und Informationen in Bezug auf die zugrunde liegenden Wege 206, wie zum Beispiel Entfernung, Geschwindigkeitsbeschränkung und durchschnittliche Reisezeit. Die Reichweitenkonturen 308 auf Betriebskostenbasis können für die Punkte auf der Route 306 und benachbarte Wege auf Basis von Informationen berechnet werden, die für den Ridesharing-Server 208 verfügbar sind, wie zum Beispiel die berechneten Reisezeitdaten, Kraftstoffwirkungsgradinformationen für das Fahrzeug 102 (z. B. auf Basis des Modells des Fahrzeugs 102 oder aus dem Mietfahrzeug-Server 210 abgerufener, historisierter Informationen), Kraftstoffkosteninformationen (z. B. durchschnittlicher Benzinpreis für einen Postleitzahlenbereich oder ein anderes Ortsgebiet, in dem sich das Fahrzeug 102 befindet (z. B. die Position, wie sie entsprechend dem GPS-Modul 146 bestimmt wird)) und Tages-, Laufleistungs- oder anderer Mietpreis für das Fahrzeug 102, die aus dem Mietfahrzeug-Server 210 abgerufen werden.
Die Reichweitenkontur 308 kann dementsprechend visuelle Angaben von Kosten oder Zeit auf der Nutzerschnittstelle 300 bereitstellen, die relevant sein können, um zu bestimmen, ob und welche Mitfahr-Optionen 402 von der Nutzerschnittstelle 500 gewählt werden sollen. Für die Fahrer kann die Reichweitenkontur 308 Einsicht darin bereitstellen, wie die Gesamtzeit einer Route 306 zu verringern ist oder wie die Gesamtkosten für das Reisen auf Route 306 zu verringern sind.
In einem Beispiel kann die Tourenplanungsanwendung 170 dazu ausgelegt sein, einen Vorschlag für den Fahrer bereitzustellen, ob und welche der Mitfahr-Optionen 402 ausgewählt werden sollte. Dafür kann die Tourenplanungsanwendung 170 die verfügbaren Möglichkeiten für die Zeit verringern, wie zum Beispiel durch Berechnen, welche der Mitfahr-Optionen 402 eine kürzeste, geschätzte Zeit bereitstellen würde. In einigen Fällen kann die Option einer kürzesten, geschätzten Zeit das Mitnehmen eines oder mehrerer Ridesharing-Teilnehmer beinhalten, zum Beispiel aufgrund der Verfügbarkeit von Fahrspuren für Fahrgemeinschaften. Falls die Kosten verringert werden, würde die Tourenplanungsanwendung 170 berechnen, welche der Mitfahr-Optionen 402 die geringsten, geschätzten Kosten oder eine höchste Rendite bereitstellen würde. In einigen Fällen kann dies nicht nur lediglich bedeuten, all die Mitfahrer mitzunehmen, weil sich zum Beispiel einige Mitfahrer dafür entscheiden können, eine höhere Gebühr zu zahlen, damit ihre Mitnahme mehr erwünscht ist, und andere Mitfahrer können lediglich mehr kosten als der Nutzen, den sie für den Fahrer bereitstellen können (z. B. weil das Fahrzeug 102 verspätet werden würde, so dass die Reise mehr kostet als der Betrag, den der Mitfahrer zahlen würde).
6 veranschaulicht einen beispielhaften Prozess 600 zum Durchführen von Ridesharing für mehrere Nutzer des multimodalen Transportsystems 200. In einem Beispiel kann der Prozess 600 vom Ridesharing-Server 208 durchgeführt werden.
In der Operation 602 empfängt der Ridesharing-Server 208 eine Route 306 von der Tourenplanungsanwendung 170 eines Fahrers. In einem Beispiel kann ein Fahrer ein Fahrzeug 102 von einem Mietdienst des Fahrzeugs 102 mieten, und der Ridesharing-Server 208 kann über den Mietvorgang von einem Mietfahrzeug-Server 210 des Mietdienstes informiert werden. Die Tourenplanungsanwendung 170 kann auf der mobilen Einrichtung 152 des Fahrers installiert werden, und die mobile Einrichtung 152 kann mit dem gemieteten Fahrzeug 102 gepaart werden. Der Fahrer kann weiterhin die Route 306 in die Tourenplanungsanwendung 170 eingeben. Der Ridesharing-Server 208 kann die Route 306 empfangen, die von der Tourenplanungsanwendung 170 an den Ridesharing-Server 208 gesendet werden kann. In einem anderen Beispiel kann der Fahrer einen Bestimmungsort eingeben, und die Tourenplanungsanwendung 170 kann dem Ridesharing-Server 208 eine Ausgangsposition des Nutzers (z. B. aktuelle Position, Position eines Knotenpunkts 202 usw.) und den Bestimmungsort zum Berechnen der Route 306 bereitstellen.
In der Operation 604 überwacht der Ridesharing-Server 208 Positionen eines oder mehrerer Mitfahr-Nutzer, die sich um eine gemeinsam genutzte Fahrt bemühen. In einem Beispiel kann die Tourenplanungsanwendung 170 auf den mobilen Einrichtungen 152 der Mitfahr-Nutzer installiert sein, und der Ridesharing-Server 208 empfängt Positionsinformationen von den mobilen Einrichtungen 152, die von der Tourenplanungsanwendung 170 gesendet werden. Die Positionsinformationen können zum Beispiel durch GPS-Funktionalität der mobilen Einrichtungen 152 bestimmt werden.
In der Operation 606 erzeugt der Ridesharing-Server 208 Reichweitenkonturen 308 für die Route 306. In einem Beispiel kann der Ridesharing-Server 208 eine oder mehrere Reichweitenkonturen 308 bei vom Nutzer spezifizierten Mitnahmepreisen (z. B. eine 20-$-Kontur) oder Zeitaufwänden (z. B. eine 20-Minuten-Kontur) generieren.
In der Operation 608 identifiziert der Ridesharing-Server 208 Mitfahr-Nutzer innerhalb der Reichweitenkontur 308. In einem Beispiel kann der Ridesharing-Server 208 die überwachten Positionen des einen oder der mehreren Mitfahr-Nutzer mit den Reichweitenkonturen 308 vergleichen, um zu bestimmen, welche Nutzer sich möglicherweise innerhalb der Reichweitenkontur 308 befinden.
In der Operation 610 bestimmt der Ridesharing-Server 208, ob irgendwelche Mitfahr-Nutzer innerhalb der Reichweitenkontur 308 verfügbar sind. Falls Nutzer identifiziert werden, geht die Steuerung mit der Operation 614 weiter. Andernfalls geht die Steuerung mit der Operation 612 weiter.
In der Operation 612 fährt der Ridesharing-Server 208 ohne Ridesharing fort. Nach der Operation 612 endet der Prozess 600. In einigen Beispielen kann die Steuerung stattdessen mit der Operation 608 weitergehen, um zu identifizieren, ob zusätzliche Mitfahr-Nutzer innerhalb der Reichweitenkontur 308 verfügbar geworden sind.
In der Operation 614 sendet der Ridesharing-Server 208 Mitfahr-Optionen 402 an die Tourenplanungsanwendung 170 des Fahrers. In einem Beispiel kann der Ridesharing-Server 208 einen Datensatz 400, der mehrere Mitfahr-Optionen 402 enthält, an die Tourenplanungsanwendung 170 des Fahrers senden. Ein beispielhafter Datensatz 400 wird oben mit Bezug auf 4 beschrieben.
In der Operation 616 bestimmt der Ridesharing-Server 208, ob die Auswahl einer oder mehrerer der Mitfahr-Optionen 402 ausgeführt worden ist. In einem Beispiel kann der Fahrer eine oder mehrere der Mitfahr-Optionen 402 unter Verwendung der Nutzerschnittstelle 500 der Tourenplanungsanwendung 170 auswählen, wie oben mit Bezug auf 5 beschrieben worden ist. Als Reaktion auf solch eine Auswahl kann die Tourenplanungsanwendung 170 des Fahrers eine Angabe der vom Fahrer durchgeführten Auswahl senden, und der Ridesharing-Server 208 kann diese empfangen. Falls der Fahrer eine oder mehrere der Mitfahr-Optionen 402 ausgewählt hat, geht die Steuerung mit der Operation 618 weiter. Andernfalls geht die Steuerung mit der Operation 612 weiter.
In der Operation 618 sendet der Ridesharing-Server 208 eine Mitnahmemitteilung an die ausgewählten Mitfahrer. In einem Beispiel kann der Ridesharing-Server 208 eine Mitnahmemitteilung mit dem Status des Mitnehmens vom Ridesharing-Server 208 an die Tourenplanungsanwendung 170 des Mitfahr-Nutzers, der darauf wartet, mitgenommen zu werden, senden. Zum Beispiel kann die Mitnahmemitteilung Informationen in Bezug auf das Fahrzeug 102 des Fahrers enthalten, wie zum Beispiel Farbe, Marke und/oder Modell.
In der Operation 620 führt der Ridesharing-Server 208 Bestätigung der Mitfahrer durch. In einem Beispiel kann der Ridesharing-Server 208 Bestätigung empfangen, die vom Fahrer unter Verwendung seiner Tourenplanungsanwendung 170 eingegeben worden ist, um den Ridesharing-Server 208 über das Mitnehmen zu informieren. Zusätzlich oder alternativ kann der Nutzer, der mitgenommen wird, unter Verwendung der Tourenplanungsanwendung 170 seiner mobilen Einrichtung 152 melden, dass er vom Fahrzeug 102 mitgenommen worden ist. Als noch ein weiteres zusätzliches oder alternatives Beispiel können beide Tourenplanungsanwendungen 170, die des Fahrers und die des bzw. der mitzunehmenden Nutzer, Positionsaktualisierungen an den Ridesharing-Server 208 senden, und der Ridesharing-Server 208 kann auf Basis der Gemeinsamkeit der Positionsänderung ableiten, dass die Nutzer zusammen im Fahrzeug 102 fahren. Nach der Operation 620 endet der Prozess 600.
7 veranschaulicht einen beispielhaften Prozess 700 zum Annehmen von Ridesharing durch einen nicht fahrenden Nutzer des multimodalen Transportsystems 200. In einem Beispiel kann der Prozess 700 von der mobilen Einrichtung 152 eines Nutzers in Kommunikation mit dem Ridesharing-Server 208 durchgeführt werden.
In der Operation 702 empfängt die mobile Einrichtung 152 eine oder mehrere Mitfahr-Optionen 402. In einem Beispiel kann die Tourenplanungsanwendung 170 einen Datensatz 400, der mehrere Mitfahr-Optionen 402 enthält, vom Ridesharing-Server 208 empfangen. Ein beispielhafter Datensatz 400 wird oben mit Bezug auf 4 beschrieben.
In der Operation 704 nimmt die mobile Einrichtung 152 eine oder mehrere Mitfahr-Optionen 402 an. In einem Beispiel zeigt die Tourenplanungsanwendung 170 dem Nutzer eine Nutzerschnittstelle und vom Nutzer empfangene Eingaben, die die Annahme einer oder mehrerer Mitfahr-Optionen 402 angeben. Eine beispielhafte Nutzerschnittstelle 500 wird oben mit Bezug auf 5 beschrieben.
In der Operation 706 sendet und/oder empfängt die mobile Einrichtung 152 Positionsaktualisierungen. In einem Beispiel kann die Tourenplanungsanwendung 170 dem Ridesharing-Server 208 Positionsaktualisierungen der Position des Fahrzeugs 102 bereitzustellen, um dem Ridesharing-Server 208 zu ermöglichen, Aktualisierungen für die anderen Nutzer in Bezug auf den Status der Fahrt des gemeinsam genutzten Fahrzeugs 102 bereitzustellen. In einem anderen Beispiel kann die Tourenplanungsanwendung 170 Fahrzeugpositionsverfolgungsinformationen vom Ridesharing-Server 208 empfangen, die die Position des Fahrzeugs 102 angeben, das ihn mitnehmen wird.
In der Operation 708 führt die mobile Einrichtung 152 Bestätigung des Mitfahrers durch, für die Beispiele oben mit Bezug auf die Operation 620 beschrieben werden. Nach der Operation 708 endet der Prozess 700.
Somit kann das multimodale Transportsystem 200 ermöglichen, einen Satz Mitfahr-Nutzer als innerhalb einer eine Fahrerroute umgebenden Reichweitenkontur zu identifizieren, die ein Schwellenwertmaximum von Kosten und/oder Zeit angibt; einen Satz Mitfahr-Optionen an eine Fahrereinrichtung zu senden, wobei die Mitfahr-Optionen die Mitfahr-Nutzer angeben; und von der Einrichtung eine Auswahl zum Mitnehmen eines der Mitfahr-Nutzer zu empfangen.
Varianten des multimodalen Transportsystems 200 sind möglich. In einem Beispiel kann der Ridesharing-Server 208 auch den Datensatz 400, der die mehreren Mitfahr-Optionen 402 enthält, an die Tourenplanungsanwendung 170 der Mitfahrer senden, was es den Mitfahrern ermöglicht, aus den Mitfahr-Optionen 402 auszuwählen, anstelle von oder zusätzlich zur Auswahl durch den Fahrer. Außerdem kann die Tourenplanungsanwendung 170, wenn ausgewählt wird, ob gefahren werden soll, Informationen anzeigen, die sowohl angeben, wie viele Sitze im Fahrzeug 102 verfügbar sind, als auch die Positionen dieser Sitze im Fahrzeug 102 angeben. Als eine andere Variante können zu den Mitfahr-Optionen 402 Informationen in Bezug auf die Vorgaben zur Insassenanzahl des Fahrzeugs 102 zählen, um z. B. zu bestimmen zu helfen, wie viele Nutzer bei der Auswahl einbezogen werden. Als noch eine weitere Möglichkeit können zusätzliche Mitfahrer vom Display der Nutzerschnittstelle 300 verschwinden, wenn ein Fahrzeug 102 die maximale Mitfahrerkapazität erreicht.
Als eine andere Möglichkeit kann das multimodale Transportsystem 200 Mitfahrern beim Reservieren einer nächsten Tour helfen. Zum Beispiel kann eine Bestätigung des Mitfahrers für eine zukünftige Tour unter Verwendung der Tourenplanungsanwendung 170 im Voraus geplant werden. Als noch eine andere Möglichkeit kann der Ridesharing-Fahrer beabsichtigen, das Fahrzeug 102 zu verlassen, um eine Veranstaltung zu besuchen, z. B. eine Konferenz, ist jedoch möglicherweise nicht in der Lage oder willens, einen Parkplatz zu finden. In solch einem Beispiel kann der Ridesharing-Fahrer wählen, dass ein Mitfahrer die Rolle des Fahrers einnimmt, um das Fahrzeug 102 während dieser Zeit zu verwenden, und das Fahrzeug 102 dem ursprünglichen Fahrer zurück zu bringen, sobald das Ereignis abgeschlossen ist.
Obwohl oben Ausführungsbeispiele beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Stattdessen sind die in der Spezifikation verwendeten Begriffe eher beschreibende als einschränkende Begriffe, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Gedanken und vom Schutzbereich der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener Umsetzungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
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 Patentliteratur

US 8400332 [0023]

Claims

System, das Folgendes umfasst: einen Ridesharing-Server, der zu Folgendem ausgelegt ist: einen Satz Mitfahr-Nutzer als innerhalb einer eine Fahrerroute umgebenden Reichweitenkontur zu identifizieren, die ein Schwellenwertmaximum von Kosten und/oder Zeit angibt; einen Satz Mitfahr-Optionen an eine Fahrereinrichtung zu senden, wobei die Mitfahr-Optionen die Mitfahr-Nutzer angeben; und von der Einrichtung eine Auswahl zum Mitnehmen eines der Mitfahr-Nutzer zu empfangen.
System nach Anspruch 1, wobei der Ridesharing-Server weiterhin zu Folgendem ausgelegt ist: Fahrernutzerpositionen von einem Fahrzeug, das die Fahrerroute befährt, zu empfangen; und die Fahrernutzerpositionen von der Fahrereinrichtung an den einen der Mitfahr-Nutzer zu senden, der zum Mitnehmen ausgewählt worden ist.
System nach Anspruch 1, wobei der Ridesharing-Server weiterhin dazu ausgelegt ist, als Reaktion auf die Auswahl eine Mitnahmemitteilung an den einen der Mitfahr-Nutzer zu senden.
System nach Anspruch 1, wobei die Reichweitenkontur entsprechend einem vorbestimmten Mitfahrerkostenschwellenwert und/oder einem vorbestimmten Zeitkostenschwellenwert definiert wird.
System nach Anspruch 1, wobei der Satz Mitfahr-Optionen Insassenanzahl, Mitfahrerkosten- und Zeitkosteninformationen für die Mitfahr-Nutzer enthält.
System nach Anspruch 5, wobei die Mitfahrerkosten- und Zeitkosteninformationen im Satz Mitfahr-Optionen als Kosten- und Zeit-Offsets von einem aktuell gewählten Satz Mitfahrer spezifiziert wird.
System nach Anspruch 1, wobei der Ridesharing-Server weiterhin zu Folgendem ausgelegt ist: Mitfahr-Nutzerpositionen von mobilen Einrichtungen der Mitfahr-Nutzer zu empfangen; und den Satz Mitfahr-Nutzer innerhalb der Reichweitenkontur entsprechend den Mitfahr-Nutzerpositionen zu identifizieren.
System, das Folgendes umfasst: eine mobile Vorrichtung, die zu Folgendem ausgelegt ist: von einem Ridesharing-Server einen Satz Mitfahr-Optionen zu empfangen, der Mitfahr-Nutzer innerhalb einer eine Fahrerroute umgebenden Reichweitenkontur angibt, die einen Schwellenwert von Kosten und/oder Zeit angibt; eine Nutzerschnittstelle anzuzeigen, die die Mitfahr-Optionen enthält; eine Auswahl einer der Mitfahr-Optionen zum Mitnehmen einer der Mitfahr-Nutzer zu empfangen; und die Auswahl an den Ridesharing-Server zu senden.
System nach Anspruch 8, wobei die mobile Einrichtung weiterhin dazu ausgelegt ist, die Fahrerroute und die Reichweitenkontur auf einer Karte eingeblendet anzuzeigen.
System nach Anspruch 9, wobei die mobile Einrichtung weiterhin zu Folgendem ausgelegt ist: Mitfahr-Nutzerpositionen vom Ridesharing-Server zu empfangen; und die Mitfahr-Nutzer innerhalb der Reichweitenkontur entsprechend den Mitfahr-Nutzerpositionen zu identifizieren.
System nach Anspruch 8, wobei die mobile Einrichtung weiterhin dazu ausgelegt ist, an den Ridesharing-Server Fahrernutzerpositionen der mobilen Einrichtung zu senden, die zum Mitnehmen ausgewählten Ridesharing-Nutzern bereitgestellt werden sollen.
System nach Anspruch 8, wobei die Reichweitenkontur entsprechend einem vorbestimmten Mitfahrerkostenschwellenwert und/oder einem vorbestimmten Zeitkostenschwellenwert definiert wird.
System nach Anspruch 8, wobei der Satz Mitfahr-Optionen Insassenanzahl, Mitfahrer-, Kosten- und Zeitkosteninformationen für die Mitfahr-Nutzer enthält.
System nach Anspruch 13, wobei die Mitfahrer-, Kosten- und Zeitkosteninformationen im Satz Mitfahr-Optionen als Kostenunterschiede gegenüber einem aktuell ausgewählten Satz Mitfahrer spezifiziert werden.
System nach Anspruch 13, wobei die mobile Einrichtung weiterhin dazu ausgelegt ist, wenigstens zwei der Folgenden darzustellen: die Insassenanzahl, Mitfahrerkosten- und Zeitkosteninformationen, die im Satz Mitfahr-Optionen in der Nutzerschnittstelle spezifiziert werden.
Computerimplementiertes Verfahren, das Folgendes umfasst: Fahrernutzerpositionen von einer mobilen Einrichtung des Fahrers zu empfangen, die mit einem Fahrzeug, das eine Fahrerroute befährt, verknüpft ist; Mitfahr-Nutzerpositionen von einer mobilen Passagiereinrichtung eines Mitfahr-Nutzers zu empfangen; die Mitnahme des Mitfahr-Nutzers entsprechend der Gemeinsamkeit von Fahrer- und Mitfahr-Nutzerpositionen zu identifizieren; und eine Anforderung zum Bestätigen der Mitnahme an die mobile Einrichtung des Fahrers und/oder die des Passagiers zu senden.
Verfahren nach Anspruch 16, das weiterhin umfasst, die Fahrernutzerpositionen an die mobile Passagiereinrichtung zu senden, um den Mitfahr-Nutzer vom Vorankommen des Fahrzeugs auf der Fahrerroute zu informieren.
Verfahren nach Anspruch 16, das weiterhin Folgendes umfasst: einen Mietfahrzeug-Server nach Fahrzeuginformationen abzufragen, die wenigstens zwei der Folgenden angeben: eine Marke, ein Modell und eine Farbe des Fahrzeugs; und die Fahrzeuginformationen an die mobile Passagiereinrichtung zu senden, um dem Mitfahr-Nutzer beim Identifizieren des Fahrzeugs zu helfen.
Verfahren nach Anspruch 16, das weiterhin Folgendes umfasst: einen Satz Mitfahr-Optionen an die mobile Einrichtung des Fahrers zu senden, wobei die Mitfahr-Optionen einen Satz Mitfahr-Nutzer innerhalb einer Reichweitenkontur identifizieren, die zum Ridesharing verfügbar sind; und von der Einrichtung eine Auswahl einer der Mitfahr-Optionen zum Mitnehmen einer der Mitfahr-Nutzer zu empfangen.
Verfahren nach Anspruch 19, das weiterhin umfasst, den Satz Mitfahr-Nutzer innerhalb der die Fahrerroute umgebenden Reichweitenkontur als jene Nutzer zu identifizieren, die sich innerhalb eines Schwellenwerts von Kosten und/oder Zeit befinden.