DE102019128796A1

DE102019128796A1 - System und verfahren zur authentifizierung von mitfahrdienstanfragen

Info

Publication number: DE102019128796A1
Application number: DE102019128796.0A
Authority: DE
Inventors: Mahmoud Yousef Ghannam; Howard E. Churchwell II.; Soundousse Zouani
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2018-10-25
Filing date: 2019-10-24
Publication date: 2020-04-30
Also published as: US20200134763A1; US10825121B2; CN111105054A

Abstract

Diese Offenbarung stellt ein System und Verfahren zur Authentifizierung von Mitfahrdienstanfragen bereit. Diese Offenbarung beschreibt ein Verfahren und eine Vorrichtung zum Verarbeiten von Mitfahranfragen. Das Verfahren und die Vorrichtung verarbeiten von einem ersten Mobilgerät empfangene Fahrtanfragen und erzeugen einen ersten Hash, der der Fahrtanfrage entspricht. Die Offenbarung beschreibt auch ein Verfahren und eine Vorrichtung zum Verarbeiten von Mitfahrantworten. Das Verfahren und die Vorrichtung empfangen eine Fahrtanfrage von einem Mitfahrerkonto, übertragen eine Fahrtantwort an das Mitfahrerkonto, vergleichen einen ersten Standort mit einem aktuellen Standort, bestimmen, dass eine Differenz zwischen dem ersten Standort und dem aktuellen Standort geringer als ein Schwellenwert ist, führen eine visuelle Analyse einer oder mehrerer Personen in der Nähe des aktuellen Standorts durch, fordern den Mitfahrer auf, sich hörbar zu identifizieren, und bestimmen zumindest teilweise basierend auf der hörbaren und visuellen Identifizierung, dass der Mitfahrer dem Mitfahrerkonto zugeordnet ist.

Description

GEBIET DER OFFENBARUNG
Diese Offenbarung betrifft allgemein Mitfahrdienste und insbesondere die Authentifizierung eines Mitfahrers, der eine Fahrt über einen Mitfahrdienst anfordert.
ALLGEMEINER STAND DER TECHNIK
Mitfahrdienste wie Uber™, Lyft™ und Didi™ sind auf vielen Märkten der Welt weit verbreitet. Oft steigt ein Mitfahrer, der eine Fahrt anfordert, in das falsche Auto ein. Fehler wie diese verschwenden die Zeit des Mitfahrers und des Fahrers. Beispielsweise kann der Fahrer den falschen Mitfahrer abholen und den falschen Mitfahrer zum falschen Ziel fahren, was dazu führt, dass der falsche Mitfahrer eine weitere Fahrt zu dem richtigen Ziel anfordern muss.
Der Fahrer kann den falschen Mitfahrer aufgrund einer Unterbrechung der Kommunikation zwischen dem Netzwerk des Mitfahrdienstes und einem Gerät, mit dem der Mitfahrer eine Fahrt über das Netzwerk des Mitfahrdienstes anfordert, abholender falsche Fahrer kann aufgrund einer Unterbrechung der Kommunikation zwischen dem Netzwerk des Mitfahrdienstes und dem Gerät des Fahrers mit dem falschen Mitfahrer gepaart werden, wenn das Netzwerk des Mitfahrdienstes die Anforderung an das Gerät des Fahrers weiterleitet. In ähnlicher Weise kann der Fahrer den falschen Mitfahrer abholen, wenn das Gerät des Fahrers als Reaktion auf die Fahrtanfrage eine Antwort an das Netzwerk des Mitfahrdienstes sendet und eine Kommunikationsstörung zwischen dem Netzwerk des Mitfahrdienstes und dem Gerät des Fahrers vorliegt. Der Fahrer kann auch den falschen Mitfahrer abholen, wenn das Netzwerk des Mitfahrdienstes die Antwort an das Gerät des Mitfahrers weiterleitet und eine Kommunikationsstörung zwischen dem Netzwerk des Mitfahrdienstes und dem Gerät des Mitfahrers vorliegt.
Ein weiteres häufiges Szenario ist, wenn ein Mitfahrer ein Gerät mit einer oder mehreren anderen Personen teilt und der Mitfahrer eine Fahrt über den Mitfahrdienst unter Verwendung eines oder mehrerer Mitfahrerkonten eines anderen Mitfahrers anfordert. Der Fahrer sendet möglicherweise eine Antwort auf die Anfrage eines Mitfahrers, doch der Fahrer erkennt den Mitfahrer möglicherweise nicht, da das Mitfahrerkonto, von dem der Mitfahrer die Fahrt angefordert hat, einem anderen Mitfahrer zugeordnet ist. Insbesondere, da das Mitfahrerkonto ein Bild aufweisen kann, das dem Mitfahrerkonto des anderen Mitfahrers zugeordnet ist, und der Mitfahrer die Fahrt unter Verwendung des Mitfahrerkontos des anderen Mitfahrers angefordert hat, wird der Fahrer, wenn er an dem festgelegten Abholort ankommt, um den Mitfahrer abzuholen, die Person auf dem Bild und nicht den Mitfahrer suchen. Dies führt dazu, dass der Mitfahrer nicht abgeholt wird oder der Fahrer sich weigert, den Mitfahrer abzuholen, weil der Mitfahrer nicht die Person auf dem Bild ist. Aus einem ähnlichen Grund bemerkt der Mitfahrer, wenn ein Fahrer ein Gerät mit einem oder mehreren anderen Fahrern teilt und der Fahrer auf die Anfrage mit einer Antwort über den Mitfahrdienst unter Verwendung eines oder mehrerer anderer Fahrerkonten antwortet, den Fahrer aufgrund eines Bildes im Fahrerkonto des einen oder der mehreren anderen Fahrerkonten möglicherweise nicht. Infolgedessen kann sich der Mitfahrer weigern, mit dem Fahrer in ein Auto zu steigen, weil der Fahrer nicht die Person auf dem Bild ist.
Wegen der möglichen Unterbrechung der Kommunikation zwischen dem Gerät des Mitfahrers und dem Netzwerk des Mitfahrdienstes und dem Netz des Mitfahrdienstes und dem Gerät des Fahrers kann eine Kette von Vorgängen (z. B. eine Fahrtanfrage und eine der Fahrtanfrage entsprechende Fahrtantwort) mit Fehlern dazu führen, dass ein Fahrer den falschen Fahrer abholt. Eine Möglichkeit, um festzustellen, wann ein Fehler aufgetreten ist, besteht darin, Informationen zu jedem Vorgang zwischen dem Gerät des Mitfahrers, dem Netzwerk für den Mitfahrdienst und dem Gerät des Fahrers zu vergleichender Vergleich kann zumindest teilweise auf einem Konsensprotokoll basieren.
KURZDARSTELLUNG
Diese Erfindung beschreibt ein System zum Authentifizieren von Mitfahrvorgängen zwischen einem Fahrer und einem Mitfahrer unter Verwendung der Blockchain-Technologie. Das System verhindert, dass Mitfahrer im falschen Fahrzeug mitfahren, indem mitfahrerspezifische Informationen und fahrerspezifische Informationen in Form eines Ledgers auf einen Cloud-Server hochgeladen werden. Das System überprüft, ob der Mitfahrer mit dem richtigen Fahrer fährt, indem die mitfahrerspezifischen Informationen und die fahrerspezifischen Informationen überprüft werden. Die mitfahrerspezifischen Informationen umfassen vom Mitfahrer eingegebene Parameter, die den Mitfahrer identifizieren, und die fahrerspezifischen Informationen umfassen vom Fahrer eingegebene Parameter, die den Fahrer des Fahrzeugs identifizieren. Das System überprüft die Parameter, indem es ein Konsensprotokoll anwendet, um die vom Mitfahrer und Fahrer eingegebenen Parameter zu validieren. Wenn die mit den mitfahrerspezifischen Informationen und den fahrerspezifischen Informationen verknüpften Parameter validiert werden, wird die Anfrage erfüllt. Andernfalls wird die Anfrage abgebrochen.
Figurenliste
Eine detaillierte Beschreibung ist im Folgenden unter Bezugnahme auf die begleitenden Zeichnungen dargelegt. Die Verwendung der gleichen Bezugszeichen kann ähnliche oder identische Elemente anzeigen. Verschiedene Ausführungsformen können andere Elemente und/oder Komponenten als die in den Zeichnungen veranschaulichten nutzen und einige Elemente und/oder Komponenten sind möglicherweise in verschiedenen Ausführungsformen nicht vorhanden. Elemente und/oder Komponenten in den Figuren sind nicht unbedingt maßstabsgetreu gezeichnet. In dieser Offenbarung kann je nach Kontext Terminologie im Singular und Plural austauschbar verwendet werden.

1A-1B zeigen ein Netzwerk eines Mitfahrdienstes zum Betreiben eines Mitfahrdienstes gemäß verschiedenen Ausführungsformen der Offenbarung.
2 zeigt ein veranschaulichendes Flussdiagramm einer Cloud eines Mitfahrdienstnetzwerks, die ein Mitfahrerkonto eines Mitfahrers, der eine Fahrt anfordert, mit einem Fahrerkonto eines Fahrers verbindet, der eine Antwort auf die Anfrage ausstellt, gemäß verschiedenen Ausführungsformen der Offenbarung.
3 zeigt ein veranschaulichendes Zeitablaufdiagramm einer Cloud eines Mitfahrdienstnetzwerks, die ein Mitfahrerkonto eines Mitfahrers, der eine Fahrt anfordert, mit einem Fahrerkonto eines Fahrers verbindet, der eine Antwort auf die Anfrage ausstellt, gemäß verschiedenen Ausführungsformen der Offenbarung.
4 zeigt ein veranschaulichendes Flussdiagramm der Cloud des Mitfahrdienstnetzwerks, die eine von einem Mitfahrerkonto empfangene Fahrtanfrage verarbeitet, gemäß verschiedenen Ausführungsformen der Offenbarung.
5 zeigt ein veranschaulichendes Flussdiagramm des Mitfahrdienstnetzwerks, das eine von einem Fahrerkonto empfangene Fahrtantwort verarbeitet, gemäß verschiedenen Ausführungsformen der Offenbarung.
6 zeigt ein veranschaulichendes Flussdiagramm der Cloud des Mitfahrdienstnetzwerks, die den der Anfrage zugeordneten Hash mit einem Fahrtanfrage-Hash vergleicht, der von dem Mitfahrerkonto des Mitfahrers und dem Fahrerkonto des Fahrers empfangen wurde, und den der Antwort zugeordneten Hash mit einem Fahrtantwort-Hash vergleicht, der von dem Mitfahrerkonto des Mitfahrers und dem Fahrerkonto des Fahrers empfangen wurde, gemäß verschiedenen Ausführungsformen der Offenbarung.
7 zeigt ein veranschaulichendes Flussdiagramm zum Bestätigen eines Mitfahrers gemäß den verschiedenen Ausführungsformen der Offenbarung.
8 zeigt eine beispielhafte Architektur eines Mobilgeräts gemäß den verschiedenen Ausführungsformen der Offenbarung.
9 zeigt eine beispielhafte Rechenumgebung gemäß den verschiedenen Ausführungsformen der Offenbarung.

DETAILLIERTE BESCHREIBUNG DER OFFENBARUNG
Die Offenbarung wird im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen, in denen beispielhafte Ausführungsformen der Offenbarung gezeigt sind, ausführlicher beschrieben. Diese Offenbarung kann jedoch in vielen verschiedenen Formen ausgeführt sein und sollte nicht als auf die hierin dargelegten beispielhaften Ausführungsformen beschränkt angesehen werdender einschlägige Fachmann wird erkennen, dass verschiedene Änderungen bezüglich Ausgestaltung und Detail an verschiedenen Ausführungsformen vorgenommen werden können, ohne vom Geist und Umfang der vorliegenden Offenbarung abzuweichen. Daher sollen die Breite und der Umfang der vorliegenden Offenbarung nicht durch eines der beschriebenen Ausführungsbeispiele eingeschränkt werden, sondern sollen lediglich gemäß den folgenden Patentansprüchen und ihren Äquivalenten definiert sein. Die nachstehende Beschreibung dient der Veranschaulichung gegeben und soll nicht erschöpfend oder auf die genaue offenbarte Form beschränkt sein. Es versteht sich, dass alternative Umsetzungen in jeder gewünschten Kombination verwendet werden können, um zusätzliche Hybridimplementierungen der vorliegenden Offenbarung zu bilden. Beispielsweise können beliebige der in Bezug auf eine bestimmte Vorrichtung oder bestimmte Komponente beschriebenen Funktionen von einer anderen Vorrichtung oder Komponente ausgeführt werden. Während konkrete Vorrichtungseigenschaften beschrieben wurden, können sich Ausführungsformen der Offenbarung ferner auf zahlreiche andere Vorrichtungseigenschaften beziehen. Auch wenn die Ausführungsformen in für Strukturmerkmale und/oder methodische Handlungen spezifischer Sprache beschrieben wurden, versteht es sich ferner, dass die Offenbarung nicht notwendigerweise auf die beschriebenen konkreten Merkmale oder Handlungen beschränkt ist. Die konkreten Merkmale und Handlungen werden vielmehr als veranschaulichende Formen der Umsetzung der Ausführungsformen offenbart.
1A zeigt ein Netzwerk eines Mitfahrdienstes zum Betreiben eines Mitfahrdienstes gemäß verschiedenen Ausführungsformen der Offenbarung. Das Mitfahrdienstnetzwerk 100 kann ein Cloud-Netzwerk 106, ein Benutzergerät 105, ein Benutzergerät 104, ein Benutzergerät 109, einen Mobilfunkmast 101 und einen Mobilfunkmast 111 beinhalten. Das Cloud-Netzwerk 106 kann einen oder mehrere Computer und/oder Anwendungen beinhalten, die auf einem oder mehreren Computern ausgeführt werden, die über ein lokales Netzwerk, ein Weitverkehrsnetzwerk oder ein Unternehmensnetzwerk verbunden sind, das vom Mitfahrdienst verwaltet wird. Das Cloud-Netzwerk 106 kann einen oder mehrere Dienste gemäß verschiedenen Modellen hosten. Beispielsweise kann das Cloud-Netzwerk 106 eine Infrastruktur-als-Service-Schicht (IaaS-Schicht), eine Plattform-als-Service-Schicht (PaaS-Schicht) und eine Software-als-Service-Schicht (SaaS-Schicht) hosten. Jede dieser Schichten bietet eine Abstraktion auf zunehmender Ebene, indem die Schichten vertikal gestapelt werden können. Beispielsweise kann die IaaS-Schicht die unterste Schicht sein, die PaaS-Schicht kann sich über der IaaS-Schicht befinden und die SaaS-Schicht kann sich über der PaaS-Schicht befinden.
Die IaaS-Schicht kann Onlinedienste umfassen, die APIs (Application Protocol Interfaces) auf hoher Ebene bereitstellen, mit denen verschiedene Details der zugrundeliegenden Netzwerkinfrastruktur wie physische Computerressourcen, Standort, Datenpartitionierung, Skalierung, Sicherheit, Sicherung usw. dereferenziert werden können. Ein Hypervisor kann virtuelle Maschinen als Gäste laufen lassen. Pools von Hypervisoren innerhalb des Cloud-Netzwerks 106 können eine große Anzahl von virtuellen Maschinen und die Fähigkeit unterstützen, Dienste gemäß den unterschiedlichen Anforderungen des Mitfahrdienstes zu skalieren. Die IaaS-Schicht kann eine Festplatten-Image-Bibliothek für virtuelle Maschinen, einen Raw-Block-Speicher, einen Datei- oder Objektspeicher, Firewalls, Load Balancer, IP-Adressen, virtuelle lokale Netzwerke (VLANs) und Software-Bundles hosten.
Die PaaS-Schicht kann eine Entwicklungsumgebung für Anwendungsentwickler hosten. Die PaaS-Schicht kann Toolkits und Standards für die Entwicklung sowie Kanäle für die Verteilung einer Mitfahreranwendung an Endbenutzer und Zahlungsdienste für Benutzer, um für das Herunterladen der Anwendung zu zahlen, beinhalten. Die PaaS-Schicht kann einen oder mehrere Computer beinhalten, auf denen ein Betriebssystem, eine Programmiersprachen-Ausführungsumgebung, eine Datenbank und/oder ein Webserver laufen. Zu Beispielen für eine PaaS-Schicht gehören unter anderem Microsoft Azure, Oracle Cloud Platform und Google App Engine. Die zugrundeliegenden Computer- und Speicherressourcen werden automatisch skaliert, um sich an den Anwendungsbedarf anzupassen, sodass der Mitfahrdienst die Ressourcen nicht manuell zuweisen muss. Die PaaS-Schicht kann eine Blockchain-as-a-Service (BaaS) beinhalten, die in der IBM Bluemix- und/oder Oracle Cloud-Plattform umgesetzt ist.
Die SaaS-Schicht kann Anwendungssoftware wie Software, die mit dem Mitfahrerkonto und dem Fahrerkonto interagiert, und Datenbanken beinhalten. Die SaaS-Schicht kann auf physischen Maschinen (Bare Metal) umgesetzt werden, ohne zugrundeliegende PaaS- oder IaaS-Schichten zu verwenden.
Das Cloud-Netzwerk 106 kann einen oder mehrere Server beinhalten, die einen oder mehrere Prozessoren, einen oder mehrere Speicherpools und ein oder mehrere computerlesbare Medien beinhalten. Das eine oder die mehreren computerlesbaren Medien können ein Ledger speichern, das jeden Vorgang, der von einem Mitfahrerkonto eines Mitfahrers initiiert wird, und/oder jeden Vorgang, der von einem Fahrerkonto eines Fahrers initiiert wird, aufzeichnet. Das eine oder die mehreren computerlesbaren Medien können auch jeden von dem einen oder den mehreren Prozessoren ausgeführten Vorgang auf dem einen oder den mehreren Servern speichern. Insbesondere können, wenn der eine oder die mehreren Prozessoren einen Vorgang von einem Mitfahrerkonto eines Mitfahrers empfangen können (z. B. eine Fahrtanfrage), der eine oder die mehreren Prozessoren Anweisungen ausführen, die bewirken, dass das eine oder die mehreren computerlesbaren Medien den Vorgang als Hash-Wert (Fahrtanfrage-Hash) im Ledger speichern. Der eine oder die mehreren Prozessoren können einen Vorgang von einem Fahrerkonto des Fahrers empfangen (z. B. eine Fahrtantwort) und Anweisungen ausführen, die bewirken, dass das eine oder die mehreren computerlesbaren Medien den Vorgang als Hash-Wert (Fahrtantwort-Hash) im Ledger speichern.
Wenn der eine oder die mehreren Prozessoren die Fahrtanfrage empfangen, können der eine oder die mehreren Prozessoren Anweisungen ausführen, die den einen oder die mehreren Prozessoren veranlassen, die Fahrtanfrage zu validieren, und der eine oder die mehreren Prozessoren können die Fahrtanfrage an das Fahrerkonto des Fahrers senden. Die Übertragung der Fahrtanfrage an das Fahrerkonto des Fahrers kann von einem oder mehreren Prozessoren gehasht und im Ledger gespeichert werden. Wenn der eine oder die mehreren Prozessoren die Fahrtantwort empfangen, können der eine oder die mehreren Prozessoren Anweisungen ausführen, die den einen oder die mehreren Prozessoren veranlassen, die Fahrtantwort zu validieren, und der eine oder die mehreren Prozessoren können die Fahrtantwort an das Mitfahrerkonto des Mitfahrers übertragen. Die Übertragung der Fahrtantwort auf das Mitfahrerkonto des Mitfahrers kann von einem oder mehreren Prozessoren gehasht und im Ledger gespeichert werden. Eine beispielhafte Ausführungsform des Hashing-Prozesses ist unten in 4 und 5 enthalten.
Die Mobilfunkmasten 101 und 111 sind nur repräsentativ für zwei Mobilfunkmasten, die möglicherweise demselben Mobilfunkanbieter oder möglicherweise verschiedenen Mobilfunkanbietern gehören. Die Mobilfunkmasten 101 und 111 können eine oder mehrere Elektronik(en) enthalten, die ein globales System für das Mobilfunkprotokoll (GSM), ein CDMA-Protokoll (Code Division Multiple Access) oder ein LTE-Protokoll (Long Term Evolution) umsetzen. Die Mobilfunkmasten 101 und 111 können über ein Unternehmensnetzwerk oder Mietleitungen des Mobilfunkanbieters mit dem Cloud-Netzwerk 106 verbunden sein.
Die Mobilgeräte 105, 104 und 109 können Daten über Mobilfunkmasten 101 und 111 an das Cloud-Netzwerk 106 senden und empfangen. Beispielsweise kann das Mobilgerät 105 über den Mobilfunkmast 101 und die Verbindungen 152 und 142 eine Verbindung zum Cloud-Netzwerk 106 herstellen. Das Mobilgerät 109 kann über den Mobilfunkmast 111 und die Verbindungen 122 und 132 eine Verbindung zum Cloud-Netzwerk 109 herstellen. Das Mobilgerät 104 kann über den Mobilfunkmast 101 und die Verbindungen 153 und 142 eine Verbindung zum Cloud-Netzwerk 109 herstellen. Das Mobilgerät 105 kann eine oder mehrere computerausführbare Anweisungen, die einem Fahrerkonto zugeordnet sind, auf einem oder mehreren Prozessoren im Mobilgerät 105 ausführen, die es dem Mobilgerät 105 ermöglichen, eine Fahrerantwort auf eine Fahrtanfrage zu übertragen, die vom Mobilgerät 104 oder Mobilgerät 109 übertragen wurde. Das Mobilgerät 104 kann eine oder mehrere computerausführbare Anweisungen, die einem Mitfahrerkonto zugeordnet sind, auf einem oder mehreren Prozessoren im Mobilgerät 104 ausführen, die es dem Mobilgerät 104 ermöglichen, eine Fahrtanfrage über das Cloud-Netzwerk 106 an das Mobilgerät 105 zu übertragen. Das Mobilgerät 109 kann eine oder mehrere computerausführbare Anweisungen, die einem Mitfahrerkonto zugeordnet sind, auf einem oder mehreren Prozessoren im Mobilgerät 109 ausführen, die es dem Mobilgerät 109 ermöglichen, eine Fahrtanfrage über das Cloud-Netzwerk 106 an das Mobilgerät 105 zu übertragen.
Das Automobil 110 kann von einem Fahrer (in 1A nicht gezeigt) gefahren werden, oder das Automobil 110 kann ein autonomes Fahrzeug sein. Das Automobil 110 kann eine oder mehrere Hardwarekomponenten eines mobilen Geräts, wie beispielsweise des mobilen Geräts 105, beinhalten, die in die Hardware des Automobils 110 eingebettet sein können. Die eine oder mehreren Komponenten können einen oder mehrere Prozessoren, einen oder mehrere Transceiver, eine oder mehrere Antennen, ein oder mehrere Mikrofone, einen oder mehrere Lautsprecher, eine oder mehrere Anzeigen und/oder ein oder mehrere Funkgeräte beinhalten, die in einem Armaturenbrett des Automobils 110 oder im gesamten Automobil 110 beinhaltet sein können. Die Platzierung der Hardwarekomponenten in dem Automobil 110 kann optimal platziert werden, um einen Mitfahrer zu authentifizieren, der eine Fahrt angefordert hat. Das Automobil 110 kann eine Straße entlang fahren und in der Nähe eines Ortes anhalten, an dem sich ein Mitfahrer voraussichtlich aufhalten wird.
Der Mitfahrer 102 kann eine erste Person sein, die das Mobilgerät 104 hält, und kann die erste Person sein, die einem ersten Mitfahrerkonto zugeordnet ist, das eine Fahrt anfordert. Der Mitfahrer 102 kann ein Gepäckstück haben (z. B. Gepäckstück 103).Der Mitfahrer 108 kann eine zweite Person sein, die die mobile Vorrichtung 109 hält, und kann die zweite Person sein, die einem zweiten Mitfahrerkonto zugeordnet ist, das eine Fahrt anfordert. Der Fahrer 108 kann zwei Gepäckstücke haben (z. B. Gepäckstück 106 und Gepäckstück 107).Wenn das Automobil 110 die Straße entlang fährt, kann entweder der Fahrer des Automobils 110 nach dem Mitfahrer suchen, der einem Bild entspricht, das dem Mitfahrerkonto des Mitfahrers zugeordnet ist, oder eine Kamera an dem Automobil 110 kann ein Bild in einem Bereich des Mitfahrerstandorts aufnehmen, das in dem Fahrerkonto aufgezeichnet wird. Die Kamera kann das Bild an einen oder mehrere Prozessoren im Automobil 110 oder an einen oder mehrere Server im Cloud-Netzwerk 106 senden, um eine Gesichtserkennung durchzuführen, um zu bestimmen, dass sich a) ein Mitfahrer in dem Bereich befindet, und b) der Mitfahrer der Mitfahrer ist, der dem Konto des Mitfahrers zugeordnet ist, das eine Fahrt angefordert hat. Der eine oder die mehreren Prozessoren im Automobil 110 oder der eine oder die mehreren Server im Cloud-Netzwerk 106 können das aufgenommene Bild mit dem Bild vergleichen, das dem Mitfahrerkonto des Mitfahrers zugeordnet ist, und bestimmen, dass der Mitfahrer in dem Bereich der Mitfahrer ist, der abgeholt werden soll (der Mitfahrer, der die Fahrt angefordert hat).
In einigen Ausführungsformen kann das Fahrerkonto des Fahrers computerausführbare Anweisungen beinhalten, die einen Prozessor in dem Mobilgerät 105 veranlassen können, Anweisungen auszuführen, die eine Kamera in dem Mobilgerät 105 dazu veranlassen, den Fahrer aufzufordern, mit dem Aufzeichnen des Bereichs des Standorts zu beginnen, an dem sich der Mitfahrer voraussichtlich befindet. Der Fahrer kann auf die Aufforderung reagieren und eine Taste auf einer Anzeige des mobilen Geräts 105 drücken, die das mobile Gerät 105 dazu veranlassen kann, mit der Aufzeichnung von Videomaterial zu beginnen oder eine Reihe von Fotografien in dem Bereich aufzunehmen, während der Fahrer auf der Suche nach dem Mitfahrer den Bereich durchschwenkt. Die Kamera kann ein Bild des Videomaterials oder die Fotoserie an einen oder mehrere Prozessoren in dem Mobilgerät 105 oder an einen oder mehrere Server in dem Cloud-Netzwerk 106 senden, um eine Gesichtserkennung durchzuführen, um zu bestimmen, dass es a) sich ein Mitfahrer in dem Bereich aufhält, und b) der Mitfahrer der Fahrer ist, der dem Mitfahrerkonto zugeordnet ist, das eine Fahrt angefordert hat. Der eine oder die mehreren Prozessoren im Automobil 105 oder der eine oder die mehreren Server im Cloud-Netzwerk 106 können das aufgenommene Bild mit dem Bild vergleichen, das dem Mitfahrerkonto des Mitfahrers zugeordnet ist, und bestimmen, dass der Mitfahrer in dem Bereich der Mitfahrer ist, der abgeholt werden soll (Mitfahrer, der die Fahrt angefordert hat).Dies ist ein Beispiel dafür, wie ein Mitfahrer authentifiziert werden kann.
In einigen Ausführungsformen kann das Mobilgerät 105 Audiotöne vom Mitfahrer erfassen, um zu bestimmen, dass der Mitfahrer, der die Fahrt angefordert hat, der Mitfahrer ist, den der Fahrer abholen soll. In anderen Ausführungsformen kann das Automobil 110 ein oder mehrere Mikrofone enthalten, die Audiotöne vom Mitfahrer erfassen können, um zu bestimmen, dass der Mitfahrer, der die Audiodaten bereitgestellt hat, der Mitfahrer ist, der die Fahrt angefordert hat, und der Mitfahrer ist, den der Fahrer abholen soll. Wenn zum Beispiel zwei Mitfahrer nebeneinander stehen, kann der Fahrer das Mobilgerät 105 außerhalb des Automobils 110 platzieren und die beiden Mitfahrer fragen, ob sie eine Fahrt angefordert haben. Das Fahrerkonto des Fahrers kann eine oder mehrere computerausführbare Anweisungen beinhalten, die den einen oder die mehreren Prozessoren in dem Mobilgerät 105 dazu veranlassen können, ein Mikrofon zur Aufnahme von Audiosignalen zu veranlassen, die von den beiden Mitfahrern erzeugt werden, wenn sie mit dem Fahrer sprechen, um zu bestätigen, dass sie eine Fahrt angefordert haben. Wenn der Fahrer zum Beispiel nach dem Namen der Mitfahrer fragt, kann das Mikrofon in dem Mobilgerät 105 als Reaktion auf die Frage des Fahrers ein Audiosignal erfassen, das einem von den Mitfahrern erzeugten hörbaren Ton entspricht. Der eine oder die mehreren Prozessoren können eine Sprachverarbeitungsanalyse des hörbaren Tons durchführen, um zu bestimmen, wer der richtige Mitfahrer ist. Dies ist ein weiteres Beispiel für die Authentifizierung des richtigen Mitfahrers. Beispielsweise kann ein erster Mitfahrer eine Fahrt unter Verwendung eines Mitfahrerkontos eines zweiten Mitfahrers anfordern, und der erste Mitfahrer kann versuchen, in das Automobil 110 einzusteigen, jedoch kann der Fahrer des Automobils 110 bestätigen, dass der Mitfahrer, der die Fahrt angefordert hat, der zweite Mitfahrer ist, indem er den ersten Mitfahrer fragt, ob er der zweite Mitfahrer ist. Wenn der erste Mitfahrer sagt, dass er der zweite Mitfahrer ist, kann das Mobilgerät 105 einen hörbaren Ton aufzeichnen, der mit der Antwort des ersten Mitfahrers auf die Frage des Fahrers assoziiert ist, und der eine oder die mehreren Prozessoren des Mobilgeräts 105 können als Ergebnis der Durchführung der Sprachverarbeitungsanalyse bestimmen, dass der erste Mitfahrer nicht der zweite Mitfahrer ist. Der eine oder die mehreren Prozessoren in dem Mobilgerät 105 können dies erreichen, indem sie computerausführbare Anweisungen ausführen, die den einen oder die mehreren Prozessoren veranlassen, einen zuvor aufgezeichneten hörbaren Ton, der vom zweiten Mitfahrer erzeugt wurde, mit dem hörbaren Ton zu vergleichen, der vom ersten Mitfahrer erzeugt wurde. In einigen Ausführungsformen können ein oder mehrere Server im Cloud-Netzwerk 112 die Sprachverarbeitungsanalyse durchführen und den ersten Mitfahrer authentifizieren. Der eine oder die mehreren Server können Edge-Server sein, die sich an oder in der Nähe von Mobilfunkmasten 111 oder 101 befinden können. In den Ausführungsformen, in denen das Automobil 110 ein autonomes Fahrzeug ist, können ein oder mehrere Prozessoren im Automobil 110 die Sprachverarbeitungsanalyse durchführen oder ein Signal, das ein Audiosignal enthält, das dem hörbaren Ton entspricht, an den einen oder die mehreren Server übertragen, und der eine oder die mehreren Server können den ersten Mitfahrer authentifizieren.
Ein Fahrer des Automobils 110 kann an anderen Mitfahrern vorbeifahren, basierend auf der Kleidung, die sie tragen, der Anzahl von Gepäckstücken, die sie dabei haben, oder anderen persönlichen Gegenständen, die sie möglicherweise mit sich führen. Da das Automobil 110 eine oder mehrere Kameras umfassen kann, können die eine oder mehreren Kameras Aufnahmen eines Bereichs in der Nähe des Standortes, an dem sich der Fahrer voraussichtlich aufhält, aufzeichnen und die Kleidung, die ein Fahrer trägt, die Anzahl der Gepäckstücke, die er dabei hat, oder andere persönliche Gegenstände, die er bei sich führt, identifizieren. Der eine oder die mehreren Prozessoren im Automobil 110 können basierend auf den Aufnahmen die Kleidung einer Person auf einem Bürgersteig bestimmen und können eine Bildverarbeitungsanalyse durchführen, um zu bestimmen, ob die Kleidung der Person auf dem Bürgersteig der Kleidung entspricht, die der Mitfahrer angab, als der Mitfahrer seine Anfrage auf eine Fahrt übermittelte. Dies ist ein weiteres Beispiel dafür, wie der eine oder die mehreren Prozessoren den Mitfahrer möglicherweise authentifizieren können.
Der eine oder die mehreren Prozessoren können basierend auf den Aufnahmen die Anzahl von Gepäckstücken neben einer Person auf einem Bürgersteig bestimmen und können eine Bildverarbeitungsanalyse durchführen, um zu bestimmen, ob die Anzahl von Gepäckstücken neben der Person auf dem Bürgersteig der Anzahl von Gepäckstücken entspricht, die der Mitfahrer angab, als der Mitfahrer seine Anfrage auf eine Fahrt übermittelte. Der eine oder die mehreren Prozessoren können sogar ein Bild des in den Aufnahmen erfassten Gepäcks mit einem Bild des Gepäcks vergleichen, das ein Mitfahrer möglicherweise auf einem Foto aufgenommen hat. Der eine oder die mehreren Prozessoren können eine Bildverarbeitungsanalyse durchführen, um zu bestimmen, ob das in den Aufnahmen erfasste Gepäck mit dem Gepäck auf dem Foto identisch ist. Der Mitfahrer kann dann basierend auf dem einen oder den mehreren Prozessoren authentifiziert werden, die bestimmen, dass das Gepäck dasselbe ist. Der eine oder die mehreren Prozessoren in des Mobilgeräts 105 können einen Mitfahrer auch auf ähnliche Weise authentifizieren, da das Automobil 110 den Mitfahrer basierend auf der Anzahl von Kleidungsstücken, die er trägt, der Anzahl von Gepäckstücken, die der Mitfahrer bei sich hat, und/oder den physischen Aspekten des Gepäcks selbst authentifizieren kann. Zum Beispiel kann in 1B das Automobil 110 am Mitfahrer 102 vorbeifahren, weil das Mobilgerät 105 bestimmen kann, dass der Mitfahrer 102 ein Gepäckstück (z. B. das Gepäckstück 103) bei sich hat, während der Mitfahrer 108 zwei Gepäckstücke (z. B. das Gepäckstück 106 und das Gepäckstück 107) bei sich hat und der Fahrer des Automobils 110 einen Mitfahrer mit zwei Gepäckstücken abholen soll. Der Fahrer wird neben dem Mitfahrer 108 anhalten, weil das Mobilgerät 105 bestimmt, dass der Mitfahrer 108 der richtige Mitfahrer ist, der abgeholt werden soll. Es ist zu beachten, dass der Fahrer auch anhand der visuellen Bestimmung der Anzahl der Gepäckstücke, die ein Mitfahrer bei sich hat, bestimmen kann, wo er anhalten soll.
2 zeigt ein veranschaulichendes Flussdiagramm einer Cloud eines Mitfahrdienstnetzwerks, die ein Mitfahrerkonto eines Mitfahrers, der eine Fahrt anfordert, mit einem Fahrerkonto eines Fahrers verbindet, der eine Antwort auf die Anfrage ausstellt, gemäß verschiedenen Ausführungsformen der Offenbarung. Es versteht sich, dass der dargestellte Ablauf geändert werden kann, um Schritte zu löschen oder weitere Schritte einzuschließen. Während sich die folgende Beschreibung auf ein Verfahren (d. h. das Verfahren 200) bezieht, das von dem einen oder den mehreren Servern im Cloud-Netzwerk 106 ausgeführt wird, versteht es sich, dass das Verfahren ganz oder teilweise von einer anderen Vorrichtung als de einen oder den mehreren Servern ausgeführt werden (z. B. einem Edge-Server, der sich an oder in der Nähe der Mobilfunkmasten 101 und/oder 111 befindet).
Nach einem anfänglichen Startschritt kann das Cloud-Netzwerk 106 bei Schritt 202 veranlassen, einen Smart-Vertrag an ein Mitfahrerkonto zu senden. Der Smart-Vertrag kann eine oder mehrere Bedingungen beinhalten, die erfüllt oder von einem Mitfahrer akzeptiert werden müssen, bevor der Mitfahrer eine Fahrt anfordern kann. Die eine oder die mehreren Voraussetzungen können Alter, Alkoholkonsum und/oder die Vereinbarung, sich nicht als andere Mitfahrer auszugeben, beinhalten. Beispielsweise können der eine oder die mehreren Server im Cloud-Netzwerk 106 den Smart-Vertrag über den Mobilfunkmast 111 an das Mobilgerät 109 übertragen. Insbesondere können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern den Smart-Vertrag an einen Prozessor auf dem Mobilgerät 109 übertragen, der Anweisungen ausführt, die dem Mitfahrerkonto auf dem Mobilgerät 109 entsprechen.
Das Verfahren kann mit Schritt 204 fortfahren und bestimmen, ob das Cloud-Netzwerk 106 die Annahme des Smart-Vertrags vom Mitfahrer über das Mitfahrerkonto empfängt. Wenn das Cloud-Netzwerk 106 keine Annahme des Smart-Vertrags empfängt, kann das Verfahren mit Schritt 206 fortfahren, bei dem das Cloud-Netzwerk 106 veranlassen kann, eine Nachricht an das Mitfahrerkonto zu senden, die angibt, dass der Smart-Vertrag akzeptiert werden muss, um fortzufahren. Das heißt, das Cloud-Netzwerk 106 muss eine Nachricht vom Mitfahrerkonto empfangen, die angibt, dass der Mitfahrer die Bedingungen des Smart-Vertrags akzeptiert hat, damit das Verfahren mit Schritt 208 fortfahren kann. Beispielsweise können der eine oder die mehreren Prozessoren im Cloud-Netzwerk 106 die Nachricht an den Prozessor auf dem Mobilgerät 109 senden.
In einigen Ausführungsformen kann das Cloud-Netzwerk 106 den Smart-Vertrag erneut an das Mitfahrerkonto senden, wenn das Cloud-Netzwerk 106 keine Annahme vom Mitfahrerkonto empfängt. Das heißt, das Verfahren kann zu Schritt 202 zurückkehren. Wenn das Cloud-Netzwerk 106 nach einer bestimmten Anzahl von Malen keine Annahme von dem Mitfahrerkonto empfängt, kann das Cloud-Netzwerk 106 das erneute Senden des Smart-Vertrags an das Mitfahrerkonto stoppen. Wenn das Cloud-Netzwerk 106 eine Annahme des Smart-Vertrags von dem Mitfahrerkonto empfängt, kann das Verfahren mit Schritt 208 fortfahren. Beispielsweise können der eine oder die mehreren Prozessoren im Cloud-Netzwerk 106 den Smart-Vertrag erneut an den Prozessor im Mobilgerät 109 übertragen, bis eine Annahme des Smart-Vertrags vom Mitfahrer eingeht. Der eine oder die mehreren Prozessoren können jedoch die erneute Übertragung des Smart-Vertrags an den Prozessor im Mobilgerät 109 nach einer begrenzten Anzahl von Malen beenden und die Verbindung zum Mobilgerät 109 trennen.
Bei Schritt 208 kann das Cloud-Netzwerk 106 veranlassen, den Smart-Vertrag an ein Fahrerkonto zu senden. Beispielsweise können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern in dem Cloud-Netzwerk 106 den Smart-Vertrag an einen Prozessor in dem Mobilgerät 105 übertragen. Insbesondere können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern den Smart-Vertrag an einen Prozessor auf dem Mobilgerät 105 übertragen, der Anweisungen ausführt, die dem Fahrerkonto auf dem Mobilgerät 105 entsprechen.
Das Fahrerkonto kann ein einem Fahrer zugeordnetes Konto sein, das mit einem dem Mitfahrerkonto zugeordneten Mitfahrer gepaart sein kann. Das heißt, der Fahrer kann mit einem Mitfahrer gepaart werden, den der Fahrer abholen kann, nachdem der Smart-Vertrag vom Fahrer akzeptiert wurde. Ein Mitfahrer kann mit einem Fahrer gepaart werden, nachdem sowohl der Mitfahrer als auch der Fahrer den Smart-Vertrag akzeptiert haben. Das Verfahren zum Paaren des Mitfahrers mit dem Fahrer wird nachstehend in den Schritten 212 bis 214 beschrieben.
Das Verfahren kann mit Schritt 210 fortfahren, bei dem das Cloud-Netzwerk 106 bestimmen kann, ob es die Annahme des Smart-Vertrags von dem Fahrerkonto empfängt. Wenn das Cloud-Netzwerk 106 keine Annahme des Smart-Vertrags empfängt, kann das Verfahren zu Schritt 208 zurückkehren, bei dem das Cloud-Netzwerk 106 veranlassen kann, den Smart-Vertrag an das Fahrerkonto zu senden, mit der Angabe, dass der Smart-Vertrag akzeptiert werden muss, um fortzufahren. Beispielsweise können der eine oder die mehreren Prozessoren im Cloud-Netzwerk 106 die Nachricht an den Prozessor auf dem Mobilgerät 105 senden. Wenn das Cloud-Netzwerk 106 nach einer bestimmten Anzahl von Malen keine Annahme von dem Fahrerkonto empfängt, kann das Cloud-Netzwerk 106 das erneute Senden des Smart-Vertrags an das Mitfahrerkonto stoppen. Wenn das Cloud-Netzwerk 106 eine Annahme des Smart-Vertrags von dem Fahrerkonto empfängt, kann das Verfahren mit Schritt 212 fortfahren. Beispielsweise können der eine oder die mehreren Prozessoren im Cloud-Netzwerk 106 den Smart-Vertrag erneut an den Prozessor im Mobilgerät 105 übertragen, bis eine Annahme des Smart-Vertrags vom Fahrer eingeht. Der eine oder die mehreren Prozessoren können jedoch die erneute Übertragung des Smart-Vertrags an den Prozessor im Mobilgerät 105 nach einer begrenzten Anzahl von Malen beenden und die Verbindung zum Mobilgerät 105 trennen.
Nachdem der Smart-Vertrag von dem Mitfahrerkonto und dem Fahrerkonto akzeptiert wurde, kann das Verfahren mit Schritt 212 fortfahren, und das Cloud-Netzwerk 106 kann eine Fahrtanfrage verarbeiten, die von dem Mitfahrerkonto empfangen wird. Beispielsweise können der eine oder die mehreren Server im Cloud-Netzwerk 106 eine Fahrtanfrage vom Mobilgerät 109 empfangen. Das Cloud-Netzwerk 106 kann die Fahrtanfrage gemäß den Schritten in Verfahren 400 verarbeiten und die Fahrtanfrage als einen Hash-Wert speichern. Nachdem das Cloud-Netzwerk 106 die Fahrtanfrage verarbeitet hat, kann das Cloud-Netzwerk 106 eine vom Fahrerkonto empfangene Fahrtantwort verarbeiten. Das Cloud-Netzwerk 106 kann die Fahrtanfrage gemäß den Schritten in Verfahren 500 verarbeiten und die Fahrtantwort als einen Hash-Wert speichern. Beispielsweise können der eine oder die mehreren Server im Cloud-Netzwerk 106 eine Fahrtanfrage vom Mobilgerät 105 empfangen. Die Fahrtantwort kann von dem einen oder den mehreren Servern als Reaktion auf die Fahrtanfrage empfangen und verarbeitet werden.
Nachdem die Fahrtanfrage und die Fahrtantwort verarbeitet wurden, kann das Cloud-Netzwerk 106 bei Schritt 216 bestimmen, ob das Fahrerkonto das Mitfahrerkonto bestätigen konnte. In einigen Ausführungsformen kann der Fahrer den Mitfahrer visuell bestätigen, basierend darauf, wie er aussieht, was er trägt und möglicherweise basierend auf dem Gepäck, das der Mitfahrer bei sich hat oder auf andere Weise mit sich führt. Wenn der Mitfahrer bestätigt ist, kann die Fahrt bei Schritt 220 abgeschlossen werden. Wenn das Mitfahrerkonto/der Mitfahrer nicht durch das Fahrerkonto/den Fahrer bestätigt wird, kann das Cloud-Netzwerk 106 bei Schritt 218 eine Fehlermeldung an das Mitfahrerkonto und/oder das Fahrerkonto ausstellen. Beispielsweise können der eine oder die mehreren Server im Cloud-Netzwerk 106 die Fehlermeldung an das Mitfahrerkonto und das Fahrerkonto ausstellen.
3 zeigt ein veranschaulichendes Zeitablaufdiagramm einer Cloud eines Mitfahrdienstnetzwerks, die ein Mitfahrerkonto eines Mitfahrers, der eine Fahrt anfordert, mit einem Fahrerkonto eines Fahrers verbindet, der eine Antwort auf die Anfrage ausstellt, gemäß verschiedenen Ausführungsformen der Offenbarung.
Das Ledger 301 kann in dem einen oder den mehreren Servern in einem Cloud-Netzwerk ähnlich dem Cloud-Netzwerk 106 gespeichert sein. Das Mitfahrerkonto 302 kann ein Mitfahrerkonto sein, das auf dem Mobilgerät eines Mitfahrers (z. B. dem Mobilgerät 104 und/oder dem Mobilgerät 109) ausgeführt wird. Das Fahrerkonto 303 kann ein Fahrerkonto sein, das auf dem Mobilgerät eines Fahrers (z. B. dem Mobilgerät 105) ausgeführt wird. Die Vorgänge (304-328) in dem Zeitablaufdiagramm 300 können stattfinden, nachdem das Mitfahrerkonto 302 und das Fahrerkonto 303 einen Smart-Vertrag akzeptiert haben, wie oben in 2 beschrieben. Das Ledger 301 kann eine Fahrtanfrage (z. B. Fahrtanfrage 304) von dem Mitfahrerkonto 302 empfangen. Beispielsweise kann das Mitfahrerkonto 302 auf dem Mobilgerät 109 ausgeführt werden, und das Mitfahrerkonto 302 kann die Fahrtanfrage 304 an das Ledger 301 übertragen, wenn der Mitfahrer 108 eine Taste auswählt, die auf dem Mobilgerät 109 angezeigt wird und einer Fahrtanfrage entspricht.
Nachdem das Ledger 301 die Fahrtanfrage 304 empfangen hat, kann das Ledger 301 einen ersten Teil eines Fahrtanfrageschlüssels 305 empfangen. Der erste Teil des Fahrtanfrageschlüssels 305 kann ein erster Teil eines Fahrtanfrageschlüssels sein. Der Fahrtanfrageschlüssel kann den ersten Teil des Fahrtanfrageschlüssels und einen zweiten Teil des Fahrtanfrageschlüssels 306 beinhalten. Der erste Teil des Fahranforderungsschlüssels 305 kann in dem Mitfahrerkonto 302 gespeichert sein, und der zweite Teil des Fahrtanfrageschlüssels 306 kann in dem Ledger 301 gespeichert sein. Das Ledger 301 und das Fahrerkonto 302 können den Fahrtanfrageschlüssel durch Hashing einer Kombination des ersten Teils 305 und des zweiten Teils 306 des Fahrtanfrageschlüssels validieren. Wenn beispielsweise das Ledger 301 den ersten Teil des Fahrtanfrageschlüssels 305 empfängt, können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 den ersten Teil des Fahrtanfrageschlüssels 305 im Ledger 301 speichern. Das Ledger 301 kann auch den zweiten Teil des Fahrtanfrageschlüssels 306 speichern, und der eine oder die mehreren Prozessoren können eine Fahrtanfrage-Hash-Funktion auf den ersten Teil des Fahrtanfrageschlüssels 305 und den zweiten Teil des Fahrtanfrageschlüssels 306 anwenden, um den Fahrtanfrageschlüssel zu validieren. Da das Ledger 301 den zweiten Teil des Fahrtanfrageschlüssels (den zweiten Teil des Fahrtanfrageschlüssels 306) speichert, überträgt das Ledger 301 den zweiten Teil des Fahrtanfrageschlüssels 306 an das Mitfahrerkonto 302. Da das Mitfahrerkonto 302 den ersten Teil des Fahrtanfrageschlüssels 305 speichert, kann der Prozessor in dem Mobilgerät 109 die Fahrtanfrage-Hash-Funktion auf den ersten Teil des Fahrtanfrageschlüssels 305 und den zweiten Teil des Fahrtanfrageschlüssels 306 anwenden, um den Fahrtanfrageschlüssel zu validieren. Der resultierende Hash-Wert kann ein erster Fahrtanfrage-Hash sein.
Das Ledger 301 kann den ersten Teil des Fahrtanfrageschlüssels 305 und die Fahrtanfrage 308 an das Fahrerkonto 303 übertragen. Das Ledger 301 kann den zweiten Teil des Fahrtanfrageschlüssels 310 an das Fahrerkonto 303 übertragen. Der Schlüssel im zweiten Teil des Fahrtanfrageschlüssels 310 ist der gleiche wie der Schlüssel im zweiten Teil des Fahrtanfrageschlüssels 306. Das Ledger 301 kann den ersten Teil des Fahrtanfrageschlüssels 305 und des Fahrtanfrageschlüssels 308 und den zweiten Teil des Fahrtanfrageschlüssels 310 an das Fahrerkonto 303 übertragen, so dass das Fahrerkonto 303 den Fahrtanfrageschlüssel validieren kann. Der Schlüssel im zweiten Teil des Fahrtanfrageschlüssels 310 ist der gleiche wie der Schlüssel im zweiten Teil des Fahrtanfrageschlüssels 306. Da das Fahrerkonto 303 den ersten Teil des Fahrtanfrageschlüssels 305 und des Fahrtanfrageschlüssels 308 und den zweiten Teil des Fahrtanfrageschlüssels 310 empfängt und speichert, kann der Prozessor in des Mobilgeräts 105 die Fahrtanfrage-Hash-Funktion auf den ersten Teil des Fahrtanfrageschlüssels anwenden, der im ersten Teil des Fahrtanfrageschlüssels und der Fahrtanfrage 308 empfangen wurde. Der Prozessor in des Mobilgeräts 105 kann auch den zweiten Teil des Fahrtanfrageschlüssels 310 empfangen, um den Fahrtanfrageschlüssel zu validieren. Der resultierende Hash-Wert kann ein zweiter Fahrtanfrage-Hash sein.
Das Ledger 301 kann eine Fahrtantwort 312 von dem Fahrerkonto 303 als Reaktion auf das Senden des zweiten Teils des Fahrtanfrageschlüssels 310 an das Fahrerkonto 303 empfangen. Das Ledger 301 kann auch den ersten Teil des Fahrtantwortschlüssels 314 empfangen, und das Hauptbuch 301 kann den zweiten Teil des Fahrtantwortschlüssels 316 an das Fahrerkonto 303 übertragen. Da das Ledger 301 den zweiten Teil des Fahrtantwortschlüssels speichert, können der eine oder die mehreren Prozessoren eine Fahrtantwort-Hash-Funktion auf den zweiten Teil des Fahrtantwortschlüssels 316 und den ersten Teil des Fahrtantwortschlüssels 314 anwenden, um den Fahrantwortschlüssel zu validieren. Da das Fahrerkonto 303 den ersten Teil des Fahrtantwortschlüssels 314 speichert, kann der Prozessor in dem Mobilgerät 105 die Fahrtantwort-Hash-Funktion auf den ersten Teil des Fahrtantwortschlüssels 314 und den zweiten Teil des Fahrtantwortschlüssels 316 anwenden, um den Fahrtantwortschlüssel zu validieren. Der resultierende Hash-Wert kann ein zweiter Fahrtantwort-Hash sein.
Das Ledger 301 kann den ersten Teil des Fahrtantwortschlüssels und die Fahrtantwort 318 an das Mitfahrerkonto 302 übertragen. Das Ledger 301 kann auch den zweiten Teil des Fahrtantwortschlüssels 320 an das Mitfahrerkonto 302 übertragen. Das Mitfahrerkonto 302 kann die Fahrtantwort-Hash-Funktion auf den ersten Teil des Fahrtantwortschlüssels und den zweiten Teil des Fahrtantwortschlüssels 320 anwenden, um den Fahrtantwortschlüssel zu validieren. Der resultierende Hash-Wert kann ein erster Fahrtantwort-Hash sein.
Das Ledger 301 kann einen ersten Fahrtanfrage-Hash 322 von dem Mitfahrerkonto 302 und einen ersten Fahrtantwort-Hash 324 von dem Mitfahrerkonto 302 empfangendes Ledger 301 kann dann einen zweiten Fahrtanfrage-Hash 326 und einen zweiten Fahrtantwort-Hash 328 von dem Fahrerkonto 303 empfangen. Das Ledger 301 kann den ersten Fahrtanfrage-Hash 320, den ersten Fahrtanfrage-Hash 322, den zweiten Fahrtanfrage-Hash 326 und den zweiten Fahrtantwort-Hash 328 speichern. Der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 können den ersten Fahrtanfrage-Hash 322 mit einem Fahrtanfrage-Hash vergleichen, der von dem einen oder den mehreren Prozessoren erzeugt wurde, um einen Fahrtanfrageschlüssel zu validierendes heißt, der Fahrtanfrage-Hash, der von dem einen oder den mehreren Prozessoren zum Validieren des Fahrtanfrageschlüssels erzeugt wird, kann mit dem ersten Fahrtanfrage-Hash 324 verglichen werden und kann auch mit dem zweiten Fahrtanfrage-Hash 326 verglichen werden. Der eine oder die mehreren Prozessoren können den Fahrtanfrage-Hash, der von dem einen oder den mehreren Prozessoren generiert wurde, mit dem ersten Fahrtanfrage-Hash 324 vergleichen und können ihn auch mit dem zweiten Fahrtanfrage-Hash 326 vergleichen, um einen Standort des Mobilgeräts 109 zu bestimmen. In ähnlicher Weise können der eine oder die mehreren Prozessoren den Fahrtantwort-Hash, der von dem einen oder den mehreren Prozessoren erzeugt wird, mit dem ersten Fahrtantwort-Hash 325 vergleichen und können ihn auch mit dem zweiten Fahrtantwort-Hash 328 vergleichen, um einen Standort des Mobilgeräts 105 zu bestimmen Die Details des Prozesses zum Bestimmen eines Standorts eines auf einem Mobilgerät ausgeführten Mitfahrerkontos und eines auf einem Mobilgerät ausgeführten Fahrerkontos werden nachstehend in den 4-5 ausführlicher erläutert.
4 zeigt ein veranschaulichendes Flussdiagramm der Cloud des Mitfahrdienstnetzwerks, die eine von einem Mitfahrerkonto empfangene Fahrtanfrage verarbeitet, gemäß verschiedenen Ausführungsformen der Offenbarung. Es versteht sich, dass der dargestellte Ablauf geändert werden kann, um Schritte zu löschen oder weitere Schritte einzuschließen. Während sich die folgende Beschreibung auf ein Verfahren (d. h. das Verfahren 400) bezieht, das von dem einen oder den mehreren Servern im Cloud-Netzwerk 106 ausgeführt wird, versteht es sich, dass das Verfahren ganz oder teilweise von einer anderen Vorrichtung als de einen oder den mehreren Servern ausgeführt werden (z. B. einem Edge-Server, der sich an oder in der Nähe der Mobilfunkmasten 101 und/oder 111 befindet).
Bei Schritt 402 kann das Cloud-Netzwerk 106 eine Fahrtanfrage von dem Mitfahrerkonto empfangen. Wie oben erläutert, ist die Fahrtanfrage ein Vorgang und wird in einem Ledger gespeichert (z. B. Ledger 301, wie durch Ledger 931 umgesetzt).Die Fahrtanfrage wird als Hash-Wert im Ledger gespeichert. Das Cloud-Netzwerk 106 kann dann einen ersten Teil eines ersten Schlüssels, der der Fahrtanfrage zugeordnet ist, von dem Mitfahrerkonto empfangen. Beispielsweise kann das Ledger 301 den ersten Teil eines ersten Schlüssels von dem Mitfahrerkonto 302 empfangen. Das Verfahren kann dann mit Schritt 406 fortfahren, bei dem das Cloud-Netzwerk 106 einen zweiten Teil des ersten Schlüssels, der der Fahrtanfrage zugeordnet ist, an das Mitfahrerkonto überträgt. Beispielsweise kann das Ledger 301 den zweiten Teil des ersten Schlüssels an das Mitfahrerkonto 302 übertragen. Das Verfahren kann dann mit Schritt 408 fortfahren, bei dem das Cloud-Netzwerk 106 den ersten Teil des ersten Schlüssels und die Fahrtanfrage an das Fahrerkonto überträgt. Beispielsweise kann das Ledger 301 den ersten Teil des ersten Schlüssels und die Fahrtanfrage an das Fahrerkonto 303 übertragen. Das Verfahren kann dann mit Schritt 410 fortfahren, bei dem das Cloud-Netzwerk 106 den zweiten Teil des ersten Schlüssels an das Fahrerkonto überträgt. Beispielsweise kann das Ledger 301 den zweiten Teil des ersten Schlüssels an das Fahrerkonto 303 übertragen.
Das Verfahren kann dann mit Schritt 412 fortfahren, bei dem das Cloud-Netzwerk 106 ein erstes Mal bestimmen kann, zu dem die Fahrtanfrage von dem Mitfahrerkonto übertragen wurde. Beispielsweise kann das Ledger 301 einen Zeitpunkt bestimmen, zu dem die Fahrtanfrage durch das Mitfahrerkonto 302 übertragen wurde. Insbesondere können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 einen Zeitstempel in der Fahrtanfrage identifizieren und den Zeitpunkt bestimmen, zu dem das Mitfahrerkonto die Fahrtanfrage übertragen hat. Da das Ledger 301 die Fahrtanfrage als Hash-Wert speichert, speichert das Ledger 301 zusammen mit der Fahrtanfrage auch den Zeitpunkt, zu dem das Mitfahrerkonto die Fahrtanfrage übertragen hat.
Das Ledger 301 speichert auch den Standort des Mitfahrergeräts, auf dem das Mitfahrerkonto installiert ist. Es ist zu beachten, dass, obwohl der Zeitpunkt, zu dem die Fahrtanfrage übertragen wurde, ein eindeutiger Wert ist, der vom Prozessor in dem Mitfahrergerät berechnete Hash-Wert der Fahrtanfrage geringfügig von dem Hash-Wert abweichen kann, der von dem einen oder mehrere Prozessoren auf dem einen oder den mehreren Servern berechnet wurde. Der Grund, warum sich der vom Prozessor berechnete Hash-Wert von dem von dem einen oder den mehreren Prozessoren berechneten Hash-Wert unterscheiden kann, liegt darin, dass sich der vom Prozessor im Mitfahrergerät ermittelte Standort von dem vom einen oder den mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 bestimmten Standort unterscheiden kann.
Das Verfahren kann dann mit Schritt 414 fortfahren, bei dem das Cloud-Netzwerk 106 basierend auf der Fahrtanfrage einen ersten Standort eines Mitfahrergeräts bestimmen kann, das dem Mitfahrerkonto (z. B. dem Mitfahrerkonto 302) zugeordnet ist. Beispielsweise kann das Ledger 301 einen Standort eines Mobilgeräts (z. B. des Mobilgeräts 104 und/oder des Mobilgeräts 109) bestimmen, an dem das Mobilegerät die Fahrtanfrage übertragen hat. Das Mitfahrerkonto kann dem Mobilgerät zugeordnet sein. Insbesondere können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 basierend auf Standortkoordinaten (z. B. Globalpositionierungssystem(GPS)-Koordinaten) in der Fahrtanfrage einen Standort identifizieren, an dem die Fahrtanfrage von dem Mitfahrergerät übertragen wurde. Der eine oder die mehreren Prozessoren können den Standort des Mitfahrergeräts bestimmen, wenn das Mitfahrerkonto, das auf einem Prozessor des Fahrergeräts ausgeführt wird, die Fahrtanfrage übertragen hat. Da das Ledger 301 die Fahrtanfrage als Hash-Wert speichert, speichert das Ledger 301 zusammen mit der Fahrtanfrage auch den Zeitpunkt, zu dem das Mitfahrergerät die Fahrtanfrage übertragen hat. Da der Standort des Mitfahrergeräts, an dem die Fahrtanfrage, wie von dem einen oder den mehreren Prozessoren bestimmt, übertragen wurde, sich von dem Standort des Mitfahrergeräts, wie von dem Prozessor im Mitfahrergerät bestimmt, unterscheiden kann, kann der im Ledger 301 gespeicherte Hash-Wert der Fahrtanfrage, des Zeitpunkts und des Standorts, an dem die Fahrtanfrage übertragen wurde, sich von dem vom Prozessor im Mitfahrergerät bestimmten Hash-Wert unterscheiden.
Der Grund, warum sich der vom Prozessor im Mitfahrergerät bestimmte Standort von dem vom einen oder den mehreren Prozessoren bestimmten Standort unterscheiden kann, kann darin liegen, dass ein GPS-Empfänger im Mitfahrergerät die GPS-Koordinaten falsch berechnet. Beispielsweise kann der GPS-Empfänger GPS-Koordinaten für das Mitfahrergerät berechnen, die nicht mit einem Standort übereinstimmen, an dem ein Mitfahrer abgeholt werden würde. Zum Beispiel kann der GPS-Empfänger die GPS-Koordinaten eines verlassenen Gebäudes berechnen und der Prozessor kann bestimmen, dass die GPS-Koordinaten mit dem tatsächlichen Standort des Mitfahrergeräts übereinstimmen. Da der Hash-Wert auf dem Standort des Mitfahrergeräts basiert, der mit den GPS-Koordinaten übereinstimmt, basiert der Hash-Wert auf den Koordinaten des verlassenen Gebäudes. Der eine oder die mehreren Server können jedoch Zugriff auf zusätzliche Kartendaten haben, mit denen der eine oder die mehreren Prozessoren bestimmen können, dass sich das Mitfahrergerät nicht im verlassenen Gebäude befindet, sondern auf einem Bürgersteig, beispielsweise neben dem verlassenen Gebäude. Dementsprechend können der eine oder die mehreren Prozessoren bestimmen, dass sich die GPS-Koordinaten des Mitfahrergeräts von den vom GPS-Empfänger berechneten GPS-Koordinaten unterscheiden. Infolgedessen unterscheidet sich der im Ledger 301 für das Mitfahrergerät gespeicherte Standort von dem im Mitfahrerkonto 302 gespeicherten Standort. Das Fahrerkonto 303 kann auch den Standort des Fahrergeräts vom Ledger 301 empfangen und speichern, und der Prozessor in dem Fahrergerät kann bestimmen, dass sich der Standort des Mitfahrergeräts von dem im Mitfahrerkonto 302 gespeicherten Standort unterscheidet. Der Standort des Mitfahrergeräts, der vom Prozessor im Fahrergerät bestimmt wird, kann sich von dem Standort unterscheiden, der im Ledger 301 gespeichert ist.
Nach dem Bestimmen des Zeitpunkts und des Standorts, an dem das Mitfahrergerät die Fahrtanfrage übertragen hat, kann das Verfahren mit Schritt 416 fortfahren. Bei Schritt 416 kann das Cloud-Netzwerk 106 einen oder mehrere Mitfahrerparameter bestimmen, die einem Mitfahrer entsprechen, der dem Mitfahrerkonto zugeordnet ist. Beispielsweise kann die Mitfahrerin 108 ein Bild aufnehmen, das in ihrem Mitfahrerkonto (z. B. dem Mitfahrerkonto 302) aufgezeichnet wird. Der eine oder die mehreren Mitfahrerparameter, die dem Mitfahrer zugeordnet sind, können Haarfarbe, Augenfarbe, eine beliebige Anzahl von Gesichtsparametern (z. B. Form von Lippen, Augen, Nase, Augenbrauen, Ohren usw.) sein, die von einem Menschen oder einer Gesichtserkennungssoftware erkennbar sind. Der eine oder die mehreren Mitfahrerparameter können auch persönlich identifizierbare Markierungen wie Narben und/oder Tätowierungen sein. Zusätzlich können der eine oder die mehreren Mitfahrerparameter Kleidung beinhalten, die der Mitfahrer zum Zeitpunkt der Übermittlung der Fahrtanfrage durch den Mitfahrer trägt. Mindestens ein Teil dieses einen oder dieser mehreren Mitfahrerparameter kann vom Mitfahrer über ein Beschreibungsfeld des Mitfahrerkontos oder über ein Bild eingegeben worden sein, das der Mitfahrer zu dem Zeitpunkt aufgenommen hat, als das Mitfahrerkonto die Fahrtanfrage übertragen hat. Da das Ledger 301 die Fahrtanfrage als Hash-Wert speichert, speichert das Ledger 301 zusammen mit der Fahrtanfrage auch den einen oder die mehreren Mitfahrerparameter, die dem Mitfahrer entsprechen. Da der eine oder die mehreren Mitfahrerparameter jedes Mitfahrers eindeutig sind (abgesehen von eineiigen Zwillingen), kann der Hash-Wert der Fahrtanfrage einen weiteren Eindeutigkeitsgrad aufweisen, der auf dem einen oder den mehreren Mitfahrerparametern basiert, die dem Mitfahrer entsprechen. Nach Schritt 416 kann das Verfahren mit Schritt 418 fortfahren, wo das Cloud-Netzwerk 106 das erste Mal, den ersten Standort und einen oder mehrere Mitfahrerparameter an das Fahrerkonto übertragen kann. Beispielsweise kann das Ledger 301 das erste Mal, dass die Fahrtanfrage übertragen wurde, den ersten Standort des Mitfahrergeräts, als die Fahrtanfrage übertragen wurde, und den einen oder die mehreren Mitfahrerparameter an das Fahrerkonto 303 übertragen.
Bei Schritt 420 kann das Cloud-Netzwerk 106 einen ersten Hash erzeugen, der der Fahrtanfrage zugeordnet ist, zumindest teilweise basierend auf dem ersten Teil des ersten Schlüssels, dem zweiten Teil des ersten Schlüssels, dem ersten Zeitpunkt, dem ersten Standort und dem einen oder den mehreren Mitfahrerparametern. Insbesondere können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern in dem Cloud-Netzwerk 106 den ersten Hash erzeugen und dann den ersten Hash in dem Ledger (z. B. dem Ledger 301) bei Schritt 422 speichern. Nachdem das Cloud-Netzwerk 106 den ersten Hash im Ledger gespeichert hat, kann das Verfahren zum Verfahren 200 zurückkehren.
5 zeigt ein veranschaulichendes Flussdiagramm des Mitfahrdienstnetzwerks, das eine von einem Fahrerkonto empfangene Fahrtantwort verarbeitet, gemäß verschiedenen Ausführungsformen der Offenbarung. Es versteht sich, dass der dargestellte Ablauf geändert werden kann, um Schritte zu löschen oder weitere Schritte einzuschließen. Während sich die folgende Beschreibung auf ein Verfahren (d. h. das Verfahren 500) bezieht, das von dem einen oder den mehreren Servern im Cloud-Netzwerk 106 ausgeführt wird, versteht es sich, dass das Verfahren ganz oder teilweise von einer anderen Vorrichtung als de einen oder den mehreren Servern ausgeführt werden (z. B. einem Edge-Server, der sich an oder in der Nähe der Mobilfunkmasten 101 und/oder 111 befindet).
Bei Schritt 502 kann das Cloud-Netzwerk 106 eine Fahrtantwort von dem Fahrerkonto empfangen. Wie oben erläutert, ist die Fahrtantwort ein Vorgang und wird in einem Ledger gespeichert (z. B. Ledger 301, wie durch Ledger 931 umgesetzt). Die Fahrtantwort wird als Hash-Wert im Ledger gespeichert. Das Cloud-Netzwerk 106 kann dann einen ersten Teil eines zweiten Schlüssels, der der Fahrantwort zugeordnet ist, von dem Fahrerkonto empfangen. Beispielsweise kann das Ledger 301 den ersten Teil eines zweiten Schlüssels von dem Fahrerkonto 303 empfangen. Das Verfahren kann dann mit Schritt 506 fortfahren, bei dem das Cloud-Netzwerk 106 einen zweiten Teil des zweiten Schlüssels, der der Fahrtantwort zugeordnet ist, an das Fahrerkonto überträgt. Beispielsweise kann das Ledger 301 den zweiten Teil des zweiten Schlüssels an das Fahrerkonto 303 übertragen. Das Verfahren kann dann mit Schritt 508 fortfahren, bei dem das Cloud-Netzwerk 106 den ersten Teil des zweiten Schlüssels und die Fahrtantwort an das Mitfahrerkonto übertragen kann. Beispielsweise kann das Ledger 301 den ersten Teil des zweiten Schlüssels und die Fahrtantwort an das Mitfahrerkonto 302 übertragen. Das Verfahren kann dann mit Schritt 510 fortfahren, bei dem das Cloud-Netzwerk 106 den zweiten Teil des zweiten Schlüssels an das Mitfahrerkonto übertragen kann. Beispielsweise kann das Ledger 301 den zweiten Teil des zweiten Schlüssels an das Mitfahrerkonto 302 übertragen.
Das Verfahren kann dann mit Schritt 512 fortfahren, bei dem das Cloud-Netzwerk 106 ein erstes Mal bestimmen kann, zu dem die Fahrtantwort von dem Fahrerkonto übertragen wurde. Beispielsweise kann das Ledger 301 einen Zeitpunkt bestimmen, zu dem die Fahrtantwort von dem Fahrerkonto 303 gesendet wurde. Insbesondere können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 einen Zeitstempel in der Fahrtantwort identifizieren und den Zeitpunkt bestimmen, zu dem das Fahrerkonto die Fahrtantwort übertragen hat. Da das Ledger 301 die Fahrtantwort als Hash-Wert speichert, speichert das Ledger 301 zusammen mit der Fahrtantwort auch den Zeitpunkt, zu dem das Fahrerkonto die Fahrtantwort gesendet hat. Das Ledger 301 speichert auch den Speicherort des Fahrergeräts, auf dem das Fahrerkonto installiert ist. Es ist zu beachten, dass, obwohl der Zeitpunkt, zu dem die Fahrtantwort übertragen wurde, ein eindeutiger Wert ist, der vom Prozessor in dem Fahrergerät berechnete Hash-Wert der Fahrtantwort geringfügig von dem Hash-Wert abweichen kann, der von dem einen oder mehrere Prozessoren auf dem einen oder den mehreren Servern berechnet wurde. Der Grund, warum sich der vom Prozessor berechnete Hash-Wert von dem von dem einen oder den mehreren Prozessoren berechneten Hash-Wert unterscheiden kann, liegt darin, dass sich der vom Prozessor im Fahrergerät ermittelte Standort von dem vom einen oder den mehreren Prozessoren in dem einen oder den mehreren Servern bestimmten Standort unterscheiden kann.
Das Verfahren kann dann mit Schritt 514 fortfahren, bei dem das Cloud-Netzwerk 106 einen ersten Standort eines dem Fahrerkonto (z. B. dem Fahrerkonto 303) zugeordneten Fahrergeräts basierend auf der Fahrtantwort bestimmen kann. Beispielsweise kann das Ledger 301 einen Standort eines Mobilgeräts (z. B. des Mobilgeräts 105) bestimmen, an dem das Mobilgerät die Fahrantwort übertragen hat. Das Fahrerkonto kann dem Mobilgerät zugeordnet sein. Insbesondere können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 basierend auf Standortkoordinaten (z. B. GPS-Koordinaten) in der Fahrtantwort einen Standort identifizieren, an dem die Fahrtantwort von dem Fahrergerät übertragen wurde. Der eine oder die mehreren Prozessoren können den Standort des Fahrergeräts bestimmen, wenn das auf einem Prozessor des Fahrergeräts ausgeführte Fahrerkonto die Fahrtantwort übertragen hat. Da das Ledger 301 die Fahrtantwort als Hash-Wert speichert, speichert das Ledger 301 zusammen mit der Fahrtantwort auch den Standort, an dem das Fahrerkonto die Fahrtantwort gesendet hat. Da der Standort des Fahrergeräts, an dem die Fahrtantwort, wie von dem einen oder den mehreren Prozessoren bestimmt, übertragen wurde, sich von dem Standort des Fahrergeräts, wie von dem Prozessor im Fahrergerät bestimmt, unterscheiden kann, kann der im Ledger 301 gespeicherte Hash-Wert der Fahrtantwort, des Zeitpunkts und des Standorts, an dem die Fahrtantwort übertragen wurde, sich von dem vom Prozessor im Fahrergerät bestimmten Hash-Wert unterscheiden.
Der Grund, warum sich der vom Prozessor im Fahrergerät bestimmte Standort von dem vom einen oder den mehreren Prozessoren bestimmten Standort unterscheiden kann, kann darin liegen, dass ein GPS-Empfänger im Fahrergerät die GPS-Koordinaten falsch berechnet. Zum Beispiel kann der GPS-Empfänger GPS-Koordinaten für das Fahrergerät berechnen, die nicht mit einem Standort übereinstimmen, an dem ein Fahrer sein Auto fahren könnte. Zum Beispiel kann der GPS-Empfänger die GPS-Koordinaten eines Gewässers berechnen, und der Prozessor kann bestimmen, dass die GPS-Koordinaten mit dem tatsächlichen Standort des Fahrergeräts übereinstimmen. Da der Hash-Wert auf dem Standort des Fahrergeräts basiert, der mit den GPS-Koordinaten übereinstimmt, basiert der Hash-Wert auf den Koordinaten eines Standorts auf dem Gewässer. Der eine oder die mehreren Server haben jedoch möglicherweise Zugriff auf zusätzliche Kartendaten, mit denen der eine oder die mehreren Prozessoren bestimmen können, dass sich das Fahrergerät nicht im Gewässer befindet, sondern auf einer Straße, z. B. auf einer an das Gewässer angrenzenden Promenade. Dementsprechend können der eine oder die mehreren Prozessoren bestimmen, dass sich die GPS-Koordinaten des Fahrergeräts von den vom GPS-Empfänger berechneten GPS-Koordinaten unterscheiden. Infolgedessen unterscheidet sich der im Ledger 301 für das Fahrergerät gespeicherte Standort von dem im Fahrerkonto 303 gespeicherten Standort. Das Mitfahrerkonto 302 kann auch den Standort des Fahrergeräts von dem Ledger 301 empfangen und speichern, und der Prozessor in dem Mitfahrergerät kann bestimmen, dass sich der Standort des Fahrergeräts von dem in dem Fahrerkonto 303 gespeicherten Standort unterscheidet. Der Standort des Fahrergeräts, der vom Prozessor im Mitfahrergerät bestimmt wird, kann sich von dem Standort unterscheiden, der im Ledger 301 gespeichert ist.
Nach dem Bestimmen des Zeitpunkts und des Standorts, an dem das Fahrergerät die Fahrantwort übertragen hat, kann das Verfahren mit Schritt 516 fortfahren. Bei Schritt 516 kann das Cloud-Netzwerk 106 einen oder mehrere Fahrerparameter bestimmen, die einem Fahrer entsprechen, der dem Fahrerkonto zugeordnet ist. Beispielsweise kann ein mit dem Mobilgerät 105 verbundener Fahrer ein Bild aufnehmen, das in seinem Fahrerkonto (z. B. dem Fahrerkonto 303) aufgezeichnet wird. Der eine oder die mehreren Fahrerparameter, die dem Fahrer zugeordnet sind, können Haarfarbe, Augenfarbe, eine beliebige Anzahl von Gesichtsparametern (z. B. Form von Lippen, Augen, Nase, Augenbrauen, Ohren usw.) sein, die von einem Menschen oder einer Gesichtserkennungssoftware erkennbar sind. Der eine oder die mehreren Fahrerparameter können auch persönlich identifizierbare Markierungen wie Narben und/oder Tätowierungen sein. Zusätzlich können der eine oder die mehreren Fahrerparameter Kleidung beinhalten, die der Fahrer zum Zeitpunkt der Übertragung der Fahrtantwort durch den Fahrer trägt. Jeder des einen oder mehreren Fahrerparameter kann vom Fahrer über ein Beschreibungsfeld des Fahrerkontos oder ein Bild eingegeben worden sein, das der Fahrer zu dem Zeitpunkt aufgenommen hat, als das Fahrerkonto die Fahrtanfrage übertragen hat. Da das Ledger 301 die Fahrtantwort als Hash-Wert speichert, speichert das Ledger 301 zusammen mit der Fahrtantwort auch den einen oder die mehreren Fahrerparameter, die dem Fahrer entsprechen. Da der eine oder die mehreren Fahrerparameter jedes Fahrers eindeutig sind (abgesehen von eineiigen Zwillingen), kann der Hash-Wert der Fahrtantwort einen weiteren Eindeutigkeitsgrad aufweisen, der auf dem einen oder den mehreren Fahrerparametern basiert, die dem Fahrer entsprechen. Nach Schritt 516 kann das Verfahren mit Schritt 518 fortfahren, bei dem das Cloud-Netzwerk 106 einen oder mehrere zweite Parameter bestimmen kann, die einem dem Fahrer zugeordneten Automobil entsprechen. Zum Beispiel können Marke, Modell, Baujahr, Ausstattung und Farbe des Automobils basierend auf einem Bild des Automobils bestimmt werden, das vom Fahrer auf dem Fahrerkonto gespeichert wurde. In einigen Ausführungsformen können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 Bilderkennungsanweisungen ausführen, die den einen oder die mehreren Prozessoren veranlassen, das Automobil basierend auf dem Bild zu klassifizieren. Zum Beispiel können der eine oder die mehreren Prozessoren Marke, Modell, Baujahr, Ausstattung und Farbe des Automobils basierend auf einer Analyse des Bildes bestimmen.
Das Verfahren kann dann mit Schritt 520 fortfahren, bei dem das Cloud-Netzwerk 106 das erste Mal, den ersten Standort und einen oder mehrere Fahrerparameter an das Fahrerkonto übertragen kann. Beispielsweise kann das Ledger 301 das erste Mal, dass die Fahrtantwort übertragen wurde, den ersten Standort des Fahrergeräts, als die Fahrtantwort übertragen wurde, und den einen oder die mehreren Fahrerparameter an das Mitfahrerkonto 302 übertragen. Bei Schritt 522 kann das Cloud-Netzwerk 106 einen zweiten Hash erzeugen, der der Fahrtanfrage zugeordnet ist, zumindest teilweise basierend auf dem ersten Teil des zweiten Schlüssels, dem zweiten Teil des zweiten Schlüssels, dem ersten Zeitpunkt, dem ersten Standort und dem einen oder den mehreren Fahrerparametern. Insbesondere können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern im Cloud-Netzwerk 106 den zweiten Hash erzeugen und dann den zweiten Hash in dem Ledger (z. B. dem Ledger 301) bei Schritt 522 speichern. Nachdem das Cloud-Netzwerk 106 den zweiten Hash im Ledger gespeichert hat, kann das Verfahren zum Verfahren 200 zurückkehren.
6 zeigt ein veranschaulichendes Flussdiagramm der Cloud des Mitfahrdienstnetzwerks, die den der Anfrage zugeordneten Hash mit einem Fahrtanfrage-Hash vergleicht, der von dem Mitfahrerkonto und dem Fahrerkonto empfangen wurde, und den der Antwort zugeordneten Hash mit einer Fahrtantwort vergleicht, die von dem Mitfahrerkonto und dem Fahrerkonto empfangen wurde, gemäß verschiedenen Ausführungsformen der Offenbarung. Es versteht sich, dass der dargestellte Ablauf geändert werden kann, um Schritte zu löschen oder weitere Schritte einzuschließen. Während sich die folgende Beschreibung auf ein Verfahren (d. h. das Verfahren 600) bezieht, das von dem einen oder den mehreren Servern im Cloud-Netzwerk 106 ausgeführt wird, versteht es sich, dass das Verfahren ganz oder teilweise von einer anderen Vorrichtung als de einen oder den mehreren Servern ausgeführt werden (z. B. einem Edge-Server, der sich an oder in der Nähe der Mobilfunkmasten 101 und/oder 111 befindet).
Bei Schritt 602 kann das Cloud-Netzwerk 106 einen ersten Fahrtanfrage-Hash von dem Mitfahrerkonto empfangen, der einem Zeitpunkt und einem Standort des Mitfahrergeräts zugeordnet ist, das dem Mitfahrerkonto entspricht, das die Fahrtanfrage übertragen hat. Beispielsweise kann das Ledger 301 einen ersten Fahrtanfrage-Hash empfangen, der einem Zeitpunkt und einem Standort des Mobilgeräts zugeordnet ist, das die Fahrtanfrage übertragen hat und auf dem das Mitfahrerkonto 302 installiert ist. Beispielsweise kann ein in einem oder mehreren Servern des Cloud-Netzwerks 106 gespeichertes Ledger den ersten Fahrtanfrage-Hash von einem Mitfahrerkonto empfangen, das auf dem Mobilgerät 109 installiert ist, und der erste Fahrtanfrage-Hash kann dem Zeitpunkt und dem Standort des Mobilgeräts 109 entsprechen. Es sei angemerkt, dass der Fahrtanfrage-Hash auch einem ersten Teil eines ersten Schlüssels und einem zweiten Teil des ersten Schlüssels zugeordnet sein kann. Der erste Schlüssel kann ein Schlüssel sein, den das Mitfahrerkonto und das Ledger zum Codieren von Vorgängen verwenden, die zwischen dem Ledger und dem Mitfahrerkonto gesendet werden. Beispielsweise können der erste Teil des ersten Schlüssels (z. B. bei Schritt 404) und der zweite Teil des ersten Schlüssels (z. B. bei Schritt 406) vom Mitfahrerkonto verwendet werden, um den ersten Fahrtanfrage-Hash zu berechnen. Es sei auch angemerkt, dass der Fahrtanfrage-Hash auch dem einen oder den mehreren Mitfahrerparametern zugeordnet sein kann (z. B. bei Schritt 418).
Nachdem der erste Fahrtanfrage-Hash empfangen wurde, kann das Verfahren mit Schritt 604 fortfahren, bei dem das Cloud-Netzwerk 106 einen ersten Fahrtantwort-Hash von dem Mitfahrerkonto empfangen kann, der einem Zeitpunkt und einem Standort des Fahrergeräts zugeordnet ist, das dem Fahrerkonto entspricht, das die Fahrtantwort übertragen hat. Beispielsweise kann das Ledger 301 einen ersten Fahrtantwort-Hash empfangen, der einem Zeitpunkt und einem Standort des Mobilgeräts zugeordnet ist, das die Fahrtanfrage übertragen hat und auf dem das Fahrerkonto 303 installiert ist. Beispielsweise kann ein in einem oder mehreren Servern des Cloud-Netzwerks 106 gespeichertes Ledger den ersten Fahrtantwort-Hash von einem Mitfahrerkonto empfangen, das auf dem Mobilgerät 109 installiert ist, und der erste Fahrtantwort-Hash kann dem Zeitpunkt und dem Standort des Mobilgeräts 105 entsprechender Grund, warum der erste Fahrantwort-Hash von dem auf dem Mobilgerät 109 installierten Mitfahrerkonto empfangen wird, besteht darin, dass das Mitfahrerkonto die gleichen Informationen speichert, die im Fahrerkonto und im Ledger gespeichert sind, wie oben erläutert. Es sei angemerkt, dass der erste Fahrantwort-Hash auch einem ersten Teil eines zweiten Schlüssels und einem zweiten Teil des zweiten Schlüssels zugeordnet sein kann. Der zweite Schlüssel kann ein Schlüssel sein, den das Fahrerkonto und das Ledger zum Codieren von Vorgängen verwenden, die zwischen dem Ledger und dem Fahrerkonto gesendet werden. Beispielsweise können der erste Teil des zweiten Schlüssels (z. B. bei Schritt 508) und der zweite Teil des zweiten Schlüssels (z. B. bei Schritt 510) vom Mitfahrerkonto verwendet werden, um den ersten Fahrantwort-Hash zu berechnen. Es sei auch angemerkt, dass der erste Fahrtantwort-Hash auch dem einen oder den mehreren Fahrerparametern zugeordnet sein kann (z. B. bei Schritt 520).
Nachdem der erste Fahrantwort-Hash empfangen wurde, kann das Verfahren mit Schritt 606 fortfahren, bei dem das Cloud-Netzwerk 106 einen zweiten Fahrtanfrage-Hash von dem Fahrerkonto empfangen kann, der einem Zeitpunkt und einem Standort des Mitfahrergeräts zugeordnet ist, das dem Mitfahrerkonto entspricht, das die Fahrtanfrage übertragen hat. Beispielsweise kann das Ledger 301 einen zweiten Fahrtanfrage-Hash empfangen, der einem Zeitpunkt und einem Standort des Mobilgeräts zugeordnet ist, das die Fahrtanfrage übertragen hat und auf dem das Mitfahrerkonto 302 installiert ist. Beispielsweise kann ein in einem oder mehreren Servern des Cloud-Netzwerks 106 gespeichertes Ledger den zweiten Fahrtanfrage-Hash von einem Fahrerkonto empfangen, das auf dem Mobilgerät 105 installiert ist, und der zweite Fahrtanfrage-Hash kann dem Zeitpunkt und dem Standort des Mobilgeräts 109 entsprechen. Der Grund, warum der zweite Fahrantwort-Hash von dem auf dem Mobilgerät 105 installierten Mitfahrerkonto empfangen wird, besteht darin, dass das Fahrerkonto die gleichen Informationen speichert, die im Mitfahrerkonto und im Ledger gespeichert sind, wie oben erläutert. Es sei angemerkt, dass der zweite Fahrtanfrage-Hash auch einem ersten Teil eines ersten Schlüssels und einem zweiten Teil des ersten Schlüssels zugeordnet sein kann. Beispielsweise können der erste Teil des ersten Schlüssels (z. B. bei Schritt 508) und der zweite Teil des ersten Schlüssels (z. B. bei Schritt 510) vom Fahrerkonto verwendet werden, um den zweiten Fahrtanfrage-Hash zu berechnen. Es sei auch angemerkt, dass der zweite Fahrtanfrage-Hash auch dem einen oder den mehreren Mitfahrerparametern zugeordnet sein kann (z. B. bei Schritt 418).
Nachdem der zweite Fahrtanfrage-Hash empfangen wurde, kann das Verfahren mit Schritt 608 fortfahren, bei dem das Cloud-Netzwerk 106 einen zweiten Fahrtantwort-Hash von dem Fahrerkonto empfangen kann, der einem Zeitpunkt und einem Standort des Fahrergeräts zugeordnet ist, das dem Fahrerkonto entspricht, das die Fahrtantwort übertragen hat.
Beispielsweise kann das Ledger 301 einen ersten Fahrtantwort-Hash empfangen, der einem Zeitpunkt und einem Standort des Mobilgeräts zugeordnet ist, das die Fahrtanfrage übertragen hat und auf dem das Fahrerkonto 303 installiert ist. Beispielsweise kann ein in einem oder mehreren Servern des Cloud-Netzwerks 106 gespeichertes Ledger den zweiten Fahrtanfrage-Hash von einem Fahrerkonto empfangen, das auf dem Mobilgerät 105 installiert ist, und der zweite Fahrtanfrage-Hash kann dem Zeitpunkt und dem Standort des Mobilgeräts 105 entsprechen. Es sei angemerkt, dass der zweite Fahrtantwort-Hash auch einem ersten Teil eines zweiten Schlüssels und einem zweiten Teil des zweiten Schlüssels zugeordnet sein kann. Der zweite Schlüssel kann ein Schlüssel sein, den das Fahrerkonto und das Ledger zum Codieren von Vorgängen verwenden, die zwischen dem Ledger und dem Fahrerkonto gesendet werden. Beispielsweise können der erste Teil des zweiten Schlüssels (z. B. bei Schritt 508) und der zweite Teil des zweiten Schlüssels (z. B. bei Schritt 510) vom Fahrerkonto verwendet werden, um den zweiten Fahrtantwort-Hash zu berechnen. Es sei auch angemerkt, dass der zweite Fahrtantwort-Hash auch dem einen oder den mehreren Fahrerparametern zugeordnet sein kann (z. B. bei Schritt 520).
Bei Schritt 610 kann das Cloud-Netzwerk 106 bestimmen, ob der erste Fahrtanfrage-Hash dem ersten Hash entspricht. Beispielsweise können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 einen ersten Fahrtanfrage-Hash-Wert, der dem ersten Fahrtanfrage-Hash entspricht, mit einem ersten Hash-Wert, der dem ersten Hash entspricht, vergleichen und bestimmen, ob der Vergleich eine Fahrtanfrage-Hash-Metrik erfüllt. Beispielsweise kann eine Fahrtanfrage-Hash-Metrik, die zum Vergleichen des ersten Fahrtanfrage-Hash-Werts mit dem ersten Hash-Wert verwendet werden kann, ein Modul des ersten Fahrtanfrage-Hash-Werts und des ersten Hash-Werts sein. Der Modul kann ein numerischer Wert sein, der einer vorzeichenlosen Differenz des ersten Fahrtanfrage-Hashwerts und des ersten Hashwerts (absoluter Wert der Differenz des ersten Fahrtanfrage-Hashwerts und des ersten Hashwerts) entspricht. Das Cloud-Netzwerk 106 kann bestimmen, dass der erste Fahrtanfrage-Hash-Wert und der erste Hash-Wert ausreichend gleich sind, zumindest teilweise basierend darauf, dass der numerische Wert geringer als ein festgelegter Wert ist (z. B. eine reelle Zahl). Wie oben erwähnt, können die Fahrtanfrage-Hash-Werte, die in dem Fahrerkonto, dem Ledger und dem Mitfahrerkonto gespeichert sind, aufgrund der Standorte, die von dem Fahrergerät, dem Cloud-Netzwerk und dem Mitfahrergerät bestimmt werden, sich geringfügig unterscheiden. Da die Fahrtanfrage-Hash-Werte sich geringfügig unterscheiden können, kann das Cloud-Netzwerk 106 bestimmen, ob der numerische Wert geringer als der festgelegte Wert ist. Wenn das Cloud-Netzwerk 106 bestimmt, dass der numerische Wert nicht geringer als der festgelegte Wert ist, kann das Cloud-Netzwerk 106 eine Nachricht an das Mitfahrerkonto senden, um einen aktualisierten Standort des Mitfahrergeräts anzufordern, und die vorzeichenlose Differenz basierend auf dem aktualisierten Standort erneut bestimmen. Wenn der numerische Wert der vorzeichenlosen Differenz immer noch nicht geringer als der festgelegte Wert ist, kann das Verfahren enden und zu Verfahren 200 zurückkehren, wo bei Schritt 218 eine Fehlermeldung an das Mitfahrergerät ausgestellt werden kann. Andernfalls kann das Verfahren mit Schritt 612 fortfahren.
Bei Schritt 612 kann das Cloud-Netzwerk 106 bestimmen, ob der zweite Fahrtanfrage-Hash dem ersten Hash entspricht. Beispielsweise können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 einen zweiten Fahrtanfrage-Hash-Wert, der dem zweiten Fahrtanfrage-Hash entspricht, mit einem ersten Hash-Wert, der dem ersten Hash entspricht, vergleichen und bestimmen, ob der Vergleich die oben beschriebene Fahrtanfrage-Hash-Metrik erfüllt. Das Cloud-Netzwerk 106 kann bestimmen, dass der zweite Fahrtanfrage-Hash-Wert und der erste Hash-Wert ausreichend gleich sind, zumindest teilweise basierend darauf, dass der numerische Wert geringer als der oben beschriebene festgelegte Wert ist. Wie oben erwähnt, können die Fahrtanfrage-Hash-Werte, die in dem Fahrerkonto, dem Ledger und dem Mitfahrerkonto gespeichert sind, aufgrund der Standorte, die von dem Fahrergerät, dem Cloud-Netzwerk 106 und dem Mitfahrergerät bestimmt werden, sich geringfügig unterscheiden. Da die Fahrtanfrage-Hash-Werte sich geringfügig unterscheiden können, kann das Cloud-Netzwerk 106 bestimmen, ob der numerische Wert geringer als der festgelegte Wert ist. Wenn das Cloud-Netzwerk 106 bestimmt, dass der numerische Wert nicht geringer als der festgelegte Wert ist, kann das Cloud-Netzwerk 106 eine Nachricht an das Mitfahrerkonto senden, um einen aktualisierten Standort des Mitfahrergeräts anzufordern, und die vorzeichenlose Differenz basierend auf dem aktualisierten Standort erneut bestimmen. Wenn der numerische Wert der vorzeichenlosen Differenz immer noch nicht geringer als der festgelegte Wert ist, kann das Verfahren enden und zu Verfahren 200 zurückkehren, wo bei Schritt 218 eine Fehlermeldung an das Mitfahrergerät ausgestellt werden kann. Andernfalls kann das Verfahren mit Schritt 614 fortfahren.
Bei Schritt 614 kann das Cloud-Netzwerk 106 bestimmen, ob der erste Fahrantwort-Hash dem zweiten Hash entspricht. Beispielsweise können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 einen ersten Fahrtantwort-Hash-Wert, der dem ersten Fahrtantwort-Hash entspricht, mit einem zweiten Hash-Wert, der dem zweiten Hash entspricht, vergleichen und bestimmen, ob der Vergleich eine Fahrtantwort-Hash-Metrik erfüllt. Beispielsweise kann eine Fahrantwort-Hash-Metrik, die zum Vergleichen des ersten Fahrtantwort-Hash-Werts mit dem zweiten Hash-Wert verwendet werden kann, ein Modul des ersten Fahrtantwort-Hash-Werts und des zweiten Hash-Werts sein. Der Modul kann ein numerischer Wert sein, der einer vorzeichenlosen Differenz des ersten Fahrtantwort-Hash-Werts und des zweiten Hash-Werts (absoluter Wert der Differenz des ersten Fahrtantwort-Hash-Werts und des zweiten Hash-Werts) entspricht. Das Cloud-Netzwerk 106 kann bestimmen, dass der erste Fahrtantwort-Hash-Wert und der zweite Hash-Wert ausreichend gleich sind, zumindest teilweise basierend darauf, dass der numerische Wert geringer als ein festgelegter Wert ist (z. B. eine reelle Zahl).Wie oben erwähnt, können die Fahrtantwort-Hash-Werte, die in dem Fahrerkonto, dem Ledger und dem Mitfahrerkonto gespeichert sind, aufgrund der Standorte, die von dem Fahrergerät, dem Cloud-Netzwerk 106 und dem Mitfahrergerät bestimmt werden, sich geringfügig unterscheiden. Da die Fahrtantwort-Hash-Werte sich geringfügig unterscheiden können, kann das Cloud-Netzwerk 106 bestimmen, ob der numerische Wert geringer als der festgelegte Wert ist. Wenn das Cloud-Netzwerk 106 bestimmt, dass der numerische Wert nicht geringer als der festgelegte Wert ist, kann das Cloud-Netzwerk 106 eine Nachricht an das Fahrerkonto senden, um einen aktualisierten Standort des Fahrergeräts anzufordern, und die vorzeichenlose Differenz basierend auf dem aktualisierten Standort erneut bestimmen. Wenn der numerische Wert der vorzeichenlosen Differenz immer noch nicht geringer als der festgelegte Wert ist, kann das Verfahren enden und zu Verfahren 200 zurückkehren, wo bei Schritt 218 eine Fehlermeldung an das Fahrergerät ausgestellt werden kann. Andernfalls kann das Verfahren mit Schritt 616 fortfahren.
Bei Schritt 616 kann das Cloud-Netzwerk 106 bestimmen, ob der zweite Fahrantwort-Hash dem zweiten Hash entspricht. Beispielsweise können der eine oder die mehreren Prozessoren in dem einen oder den mehreren Servern des Cloud-Netzwerks 106 einen zweiten Fahrtantwort-Hash-Wert, der dem zweiten Fahrtantwort-Hash entspricht, mit einem zweiten Hash-Wert, der dem zweiten Hash entspricht, vergleichen und bestimmen, ob der Vergleich die oben beschriebene Fahrtantwort-Hash-Metrik erfüllt. Das Cloud-Netzwerk 106 kann bestimmen, dass der zweite Fahrtantwort-Hash-Wert und der zweite Hash-Wert ausreichend gleich sind, zumindest teilweise basierend darauf, dass der numerische Wert geringer als ein festgelegter Wert ist (z. B. eine reelle Zahl).Wie oben erwähnt, können die Fahrtantwort-Hash-Werte, die in dem Fahrerkonto, dem Ledger und dem Mitfahrerkonto gespeichert sind, aufgrund der Standorte, die von dem Fahrergerät, dem Cloud-Netzwerk 106 und dem Mitfahrergerät bestimmt werden, sich geringfügig unterscheiden. Da die Fahrtantwort-Hash-Werte sich geringfügig unterscheiden können, kann das Cloud-Netzwerk 106 bestimmen, ob der numerische Wert geringer als der festgelegte Wert ist. Wenn das Cloud-Netzwerk 106 bestimmt, dass der numerische Wert nicht geringer als der festgelegte Wert ist, kann das Cloud-Netzwerk 106 eine Nachricht an das Fahrerkonto senden, um einen aktualisierten Standort des Fahrergeräts anzufordern, und die vorzeichenlose Differenz basierend auf dem aktualisierten Standort erneut bestimmen. Wenn der numerische Wert der vorzeichenlosen Differenz immer noch nicht geringer als der festgelegte Wert ist, kann das Verfahren enden und zu Verfahren 200 zurückkehren, wo bei Schritt 218 eine Fehlermeldung an das Fahrergerät ausgestellt werden kann.
Das Cloud-Netzwerk 106 kann die Fahrtanfrage-Hashes mit dem ersten Hash vergleichen, um zu überprüfen, ob sich ein anderer Mitfahrer oder Fahrer nicht bei dem Mitfahrerkonto und/oder dem Fahrerkonto angemeldet hat, nachdem die Fahrtanfrage und/oder die Fahrtantwort empfangen wurden. Zum Beispiel kann das Cloud-Netzwerk 106 den ersten Hash nach dem Empfang der Fahrtanfrage erzeugen, wie oben unter Bezugnahme auf 4 erläutert. Dieser Hash kann auf dem ersten Schlüssel, dem ersten Zeitpunkt, dem ersten Standort und/oder einem oder mehreren Mitfahrerparametern basieren. Das Cloud-Netzwerk 106 kann anfordern, dass das Mitfahrerkonto und das Fahrerkonto einen Hash senden, der der Fahrtanfrage zugeordnet ist.
Das Cloud-Netzwerk 106 kann anfordern, dass das Mitfahrerkonto und das Fahrerkonto einen Hash senden, um zu überprüfen, dass der Mitfahrer dieselbe Person ist, deren Mitfahrerkonto die Fahrtanfrage gesendet hat, und dass der Fahrer dieselbe Person ist, deren Fahrerkonto die Fahrtanfrage empfangen hat. Wenn ein zweiter Mitfahrer bei dem Mitfahrerkonto auf einem anderen Gerät angemeldet ist und das Cloud-Netzwerk einen der Fahrtanfrage zugeordneten Hash empfängt, der die obige Metrik nicht erfüllt, kann das Cloud-Netzwerk 106 bestimmen, dass ein zweiter Mitfahrer bei dem Mitfahrerkonto angemeldet ist. Beispielsweise kann das Cloud-Netzwerk 106 bestimmen, dass ein zweiter Mitfahrer bei dem Mitfahrerkonto angemeldet ist, wenn der Modul des von dem Mitfahrerkonto empfangenen Hashs und des ersten Hashs größer als ein erster Schwellenwert ist. Dieser erste Schwellenwert kann anzeigen, dass sich das Fahrergerät an einen Standort bewegt hat, der nicht mit dem Standort übereinstimmt, an dem die Fahrtanfrage übertragen wurde. Ein anderes Beispiel, bei dem der Modul größer als ein anderer Schwellenwert sein kann, kann sein, wenn ein oder mehrere Parameter, die dem Mitfahrer zugeordnet sind, zwischen dem Zeitpunkt, zu dem die Fahrtanfrage von dem Mitfahrerkonto übertragen wurde, und dem Zeitpunkt, zu dem der Hash von dem Mitfahrerkonto empfangen wird, unterschiedlich sind.
Das Cloud-Netzwerk 106 kann anfordern, dass das Fahrerkonto einen Hash sendet, der der Fahrtanfrage zugeordnet ist, um sicherzustellen, dass der Fahrer den richtigen Mitfahrer am richtigen Standort abholt. Wie oben erwähnt, kann das Fahrerkonto bestimmen, dass der Abholort nicht derselbe ist, wie der, der kommuniziert wurde, da die von dem Fahrergerät erzeugten GPS-Koordinatenmit einem Standort übereinstimmen, der von einem Fahrzeug nicht erreichbar ist (z. B. einem Gewässer).Das Cloud-Netzwerk 106 kann auch den Hash von dem Fahrerkonto anfordern, weil möglicherweise durch die falsche Aufzeichnung von der Fahrtanfrage zugeordneten Informationen (z. B. erster Schlüssel, erstes Mal, dass die Fahrtanfrage übertragen wurde, erster Standort des Mitfahrergeräts bei Übertragung der Fahrtanfrage und/oder ein oder mehrere Mitfahrerparameter) durch das Fahrerkonto Fehler eingeführt wurden. Das Cloud-Netzwerk 106 kann auch den Hash von dem Fahrerkonto anfordern, um Situationen in den Griff zu bekommen, in denen sich die von dem Fahrerkonto aufgezeichneten Informationen von den vom Cloud-Netzwerk 106 übertragenen Informationen unterscheiden können, wenn sich ein zweiter Fahrer bei dem Fahrerkonto auf einem zweiten Fahrergerät anmeldet. Beispielsweise kann das zweite Fahrergerät einen Zeitpunkt und einen Standort des Mitfahrergeräts in dem Fahrerkonto aufzeichnen, die sich von dem ersten Zeitpunkt und dem ersten Standort unterscheiden. Das Cloud-Netzwerk 106 kann bestimmen, dass eine Diskrepanz vorliegt, indem bestimmt wird, dass ein Modul des von dem Fahrerkonto empfangenen Hashs und des ersten Hashs größer als ein festgelegter Wert ist, wie oben erläutert.
Das Cloud-Netzwerk 106 kann Hashes von dem Mitfahrerkonto und dem Fahrerkonto in Bezug auf die Fahrtantwort anfordern und bestimmen, dass in ähnlichen Szenarien wie den oben in Bezug auf die Fahrtanfrage beschriebenen Abweichungen vorliegen.
7 zeigt ein veranschaulichendes Flussdiagramm zum Bestätigen eines Mitfahrers gemäß den verschiedenen Ausführungsformen der Offenbarung. Während die folgende Beschreibung sich auf ein Verfahren (d. h. ein Verfahren 700) bezieht, das von einem Fahrer in einem Automobil 110 durchgeführt wird, versteht es sich, dass das Verfahren ganz oder teilweise von einer anderen Vorrichtung als einem Fahrer in einem Automobil 110 durchgeführt werden kann (z. B. von dem Automobil 110).Das heißt, in einigen Ausführungsformen kann das Automobil 110 ein autonomes Fahrzeug sein und kann einige oder alle der Schritte in Verfahren 700 ausführen.
Bei Schritt 702 kann ein Fahrerkonto eine Fahrtanfrage von einem Mitfahrerkonto empfangen. Das Fahrerkonto kann auch einen Zeitstempel empfangen, der einem Zeitpunkt zugeordnet ist, zu dem die Fahrtanfrage übertragen wurde, und einen Standort des Mitfahrergeräts, als die Fahrtanfrage übertragen wurde. Das Fahrerkonto kann auch einen ersten Schlüssel empfangen, der der Fahrtanfrage zugeordnet ist, sowie einen oder mehrere Mitfahrerparameter, die physisch identifizierenden Merkmalen des Mitfahrers zugeordnet sind, wie oben erläutert. Es ist anzumerken, dass die Fahrtanfrage von dem Mitfahrerkonto über das Cloud-Netzwerk 106 empfangen wird, wie in 3 oben dargestellt. Wie oben erwähnt, speichert ein Ledger die Fahrtanfrage, den ersten Schlüssel, Zeitpunkt und Standort, an dem die Fahrtanfrage von dem Mitfahrergerät übertragen wurde, und den einen oder die mehreren Mitfahrerparameter.
In einigen Ausführungsformen kann das Fahrerkonto, nachdem das Fahrerkonto die Fahrtanfrage empfangen hat, einen der Fahrtanfrage zugeordneten Hash zumindest teilweise basierend auf dem ersten Schlüssel, dem ersten Zeitpunkt, dem ersten Standort und dem einen oder den mehreren Fahrerparametern berechnen.
Bei Schritt 704 kann ein Fahrerkonto eine Fahrtantwort an das Mitfahrerkonto als Reaktion auf den Empfang der Fahrtanfrage übertragen. Das Fahrerkonto kann auch einen Zeitstempel übertragen, der einem Zeitpunkt zugeordnet ist, zu dem die Fahrantwort übertragen wurde, und einen Standort des Fahrergeräts, als die Fahrtantwort gesendet wurde. Das Fahrerkonto kann auch einen zweiten Schlüssel, der der Fahrantwort zugeordnet ist, sowie einen oder mehrere Fahrerparameter, die physisch identifizierenden Merkmalen des Fahrers zugeordnet sind, wie oben erläutert, an das Mitfahrerkonto übertragen. Es ist anzumerken, dass die Fahrtantwort, der zweite Schlüssel, der Zeitpunkt, der Standort und ein oder mehrere Fahrerparameter über das Cloud-Netzwerk 106 an das Mitfahrerkonto übertragen werden, wie in 3 oben dargestellt. Wie oben erwähnt, speichert das Ledger die Fahrtantwort, den zweiten Schlüssel, den Zeitpunkt und den Standort, an dem die Fahrtantwort von dem Fahrergerät übertragen wurde, und den einen oder die mehreren Fahrerparameter.
In einigen Ausführungsformen kann das Fahrerkonto, nachdem das Fahrerkonto die Fahrtanfrage empfangen hat, einen der Fahrtanfrage zugeordneten Hash zumindest teilweise basierend auf dem ersten Schlüssel, dem ersten Zeitpunkt, dem ersten Standort und dem einen oder den mehreren Fahrerparametern berechnen.
Bei Schritt 706 kann das Fahrerkonto den ersten Standort eines Mobilgeräts, auf dem das Mitfahrerkonto computerausführbare Anweisungen ausführt, mit einem aktuellen Standort des Mobilgeräts vergleichen. Das heißt, der Fahrer eines Automobils oder das Automobil selbst kann bestimmen, ob sich das Automobil am ersten Standort (Abholort) befindet, indem der aktuelle Standort des Automobils mit dem Standort des ersten Standorts verglichen wird. Bei Schritt 710 kann das Fahrerkonto bestimmen, ob eine Differenz zwischen Koordinaten des ersten Standorts und Koordinaten des aktuellen Standorts geringer als ein Schwellenwert ist. Wenn die Differenz zwischen den Koordinaten des ersten Standorts und den Koordinaten des aktuellen Standorts nicht geringer als der Schwellenwert ist, kann das Verfahren mit Schritt 708 fortfahren, bei dem das Automobil weiterfahren kann, bis die Differenz zwischen den Koordinaten des ersten Standorts und den Koordinaten des aktuellen Standorts geringer ist als der Schwellenwert. Wenn die Differenz zwischen den Koordinaten des ersten Standorts und den Koordinaten des aktuellen Standorts geringer als der Schwellenwert ist, kann das Verfahren mit Schritt 712 fortfahren, bei dem der Fahrer und/oder das Automobil eine visuelle Analyse einer oder mehrerer Personen in der Nähe des aktuellen Standorts durchführen können. Beispielsweise kann der Fahrer eine oder mehrere Personen visuell inspizieren und ein oder mehrere Merkmale jeder der einen oder mehreren Personen mit dem einen oder den mehreren Mitfahrerparametern vergleichen, um den Mitfahrer zu identifizieren. In einigen Ausführungsformen kann ein Fahrergerät, wie z. B. das Fahrergerät 105, an einer Armaturenbretthalterung am Automobil befestigt sein, die so positioniert ist, dass das Sichtfeld einer Kamera des Fahrergeräts die Außenseite des Fahrzeugs erfasst (z. B. durch die Windschutzscheibe oder Fahrerseitenscheibe des Automobils).Die Kamera kann in die Lage versetzt werden, Fotos oder Videomaterial aufzunehmen, wodurch das Fahrerkonto eine visuelle Analyse der einen oder mehreren Personen außerhalb des Fahrzeugs durchführen kann. In einigen Ausführungsformen kann das Automobil mit einer oder mehreren Kameras ausgestattet sein, die die visuelle Analyse im Wesentlichen auf die gleiche Weise durchführen können.
Nachdem das Fahrergerät und/oder das Automobil die visuelle Analyse durchgeführt haben, kann das Verfahren mit Schritt 714 fortfahren, bei dem das Fahrerkonto und/oder das Automobil den Mitfahrer unter der einen oder den mehreren Personen visuell identifizieren können. In einigen Ausführungsformen kann das Fahrerkonto den Mitfahrer zumindest teilweise basierend auf einer Gesichtserkennungsanalyse bestimmen, bei der ein oder mehrere Bilder, die den aufgenommenen Fotografien entsprechen, mit einem Bild des Mitfahrers verglichen werden, das dem Mitfahrerkonto zugeordnet ist. Basierend auf dem Vergleich kann das Fahrerkonto den Mitfahrer unter einer oder mehreren Personen identifizieren. In einigen Ausführungsformen kann das Automobil selbst die Gesichtserkennungsanalyse im Wesentlichen auf die gleiche Weise durchführen.
Bei Schritt 716 kann der Fahrer und/oder das Automobil anfordern, dass der Mitfahrer sich hörbar selbst identifiziert. Beispielsweise kann der Fahrer den Mitfahrer auffordern, seinen Namen sowie zusätzliche Informationen wie etwa den Zielort des Mitfahrers anzugeben, um zu bestätigen, dass der richtige Mitfahrer abgeholt wird. In einigen Ausführungsformen kann das Fahrergerät einen Mikrofonanschluss öffnen und Audiosignale empfangen und analysieren, die dem vom Mitfahrer während des Sprechens erzeugten hörbaren Ton entsprechen, und eine Sprachverarbeitungsanalyse durchführen, um zu bestimmen, ob der Mitfahrer die Person ist, für die er sich ausgibt. Beispielsweise kann ein Fahrerkonto auf dem Fahrergerät Anweisungen ausführen, die das Fahrerkonto veranlassen, die Audiosignale mit einem oder mehreren Signalen zu vergleichen, die einem im Mitfahrerkonto aufgezeichneten hörbaren Ton zugeordnet sind. Beispielsweise kann das Fahrerkonto das eine oder die mehreren Signale vom Cloud-Netzwerk anfordern, das das eine oder die mehreren Audiosignale speichern kann. In einigen Ausführungsformen kann das Automobil mit einem oder mehreren Mikrofonen ausgestattet sein und kann die Sprachverarbeitungsanalyse im Wesentlichen auf die gleiche Weise durchführen.
Bei Schritt 718 können der Fahrer, das Fahrergerät und/oder das Automobil zumindest teilweise auf der visuellen und akustischen Identifikation des Mitfahrers bestimmen, dass der Mitfahrer dem Mitfahrerkonto zugeordnet ist, das die Fahrtanfrage übertragen hat.
8 zeigt eine beispielhafte Architektur eines Mobilgeräts gemäß den verschiedenen Ausführungsformen der Offenbarung. Die Mobilgeräte 104, 105 und 109 können einen oder mehrere Prozessoren 820, (eine) Eingabe-/Ausgabe- (E/A-) Schnittstelle(n) 822, ein Funkgerät 824, (eine) Netzwerkschnittstelle(n) 826 und einen Speicher 830 beinhalten.
Die Prozessoren 820 der Mobilgeräte 104, 105 und 109 können nach Bedarf in Hardware, Software, Firmware oder Kombinationen davon umgesetzt sein. Software- oder Firmware-Umsetzungen des einen oder der mehreren Prozessoren 820 können computerausführbare oder maschinenausführbare Anweisungen beinhalten, die in einer geeigneten Programmiersprache geschrieben sind, um die verschiedenen beschriebenen Funktionen auszuführen. Hardware-Umsetzungen der Prozessoren 820 können dazu konfiguriert sein, computerausführbare oder maschinenausführbare Anweisungen auszuführen, um die verschiedenen beschriebenen Funktionen durchzuführen. In beispielhaften Ausführungsformen können die Prozessoren 820 dazu konfiguriert sein, Anweisungen, Software und/oder Anwendungen auszuführen, die in dem Speicher 830 gespeichert sind. Der eine oder die mehreren Prozessoren 820 können unter anderem eine Zentraleinheit (CPU), einen digitalen Signalprozessor (DSP), einen Rechner mit reduziertem Befehlssatz (RISC), einen Rechner mit komplexem Befehlssatz (CISC), einen Mikroprozessor, einen Mikrocontroller, ein feldprogrammiertes Gate Array (FPGA) oder eine beliebige Kombination davon beinhalten. Die Mobilgeräte 104, 105 und 109 können auch einen Chipsatz (nicht gezeigt) zum Steuern der Kommunikation zwischen dem einen oder den mehreren Prozessoren 820 und einer oder mehreren der anderen Komponenten der Mobilgeräte 104, 105 und 109 beinhalten. Der eine oder die mehreren Prozessoren 820 können auch einen oder mehrere anwendungsspezifische integrierte Schaltkreise (ASICs) oder anwendungsspezifische Standardprodukte (ASSPs) zur Abwicklung bestimmter Datenverarbeitungsfunktionen oder -aufgaben beinhalten.
Die eine oder mehreren E/A-Geräteschnittstellen 822 können die Verwendung eines oder mehrerer (E/A-) Geräte oder Benutzerschnittstellen 846 ermöglichen, beispielsweise eines berührungsempfindlichen Bildschirms, einer Tastatur und/oder einer Maus. Die Mitfahrer 102 und 108 und/oder ein Fahrer können in der Lage sein, Bilder, Sensordaten und Kommunikationsphaseninformationen von den Mobilgeräten 104, 105 und 109 zu verwalten, indem sie mit den Benutzerschnittstellen 846 über die E/A-Schnittstellen 822 interagieren. Die Netzwerkschnittstellen 826 können es den Mobilgeräten 104, 105 und 109 ermöglichen, über das Netzwerk 106 und/oder über andere geeignete Kommunikationskanäle zu kommunizieren. Beispielsweise können die Mobilgeräte 104, 105 und 109 dazu konfiguriert sein, mit gespeicherten Datenbanken, anderen Computergeräten oder Servern, Benutzerendgeräten oder anderen Geräten in den Netzwerken 106 zu kommunizieren.
Das Sende-/Empfangsgerät oder Funkgerät 824 kann ein beliebiges geeignetes Funkgerät zum Senden und/oder Empfangen von Funkfrequenzsignalen (HF-Signalen) in der Bandbreite und/oder den Kanälen beinhalten, die den Kommunikationsprotokollen entsprechen, mit denen die Mobilgeräte 104, 105 und 109 mit anderen Servern 110 über die Mobilfunk-Basisstation 108 kommunizieren. Die Funkkomponente 824 kann Hardware und/oder Software zum Modulieren von Kommunikationssignalen gemäß vorab festgelegten Übertragungsprotokollen beinhalten. Die Funkkomponente 824 kann dazu konfiguriert sein, Kommunikationssignale für ein oder mehrere Kommunikationsprotokolle zu erzeugen, einschließlich unter anderem Wi-Fi, direktes Wi-Fi, Bluetooth, 3G-Mobilkommunikation, 4G-Mobilkommunikation, Long-term Evolution (LTE)., WiMax, direkte Satellitenkommunikation oder Kombinationen davon. In alternativen Ausführungsformen können Protokolle für Kommunikationen zwischen relativ benachbarten Mobilgeräten 104, 105 und 109 verwendet werden, wie beispielsweise Bluetooth, dedizierte Nahbereichskommunikation (DSRC) oder andere paketierte Funkkommunikationen. Die Funkkomponente 824 kann einen beliebigen bekannten Empfänger und ein beliebiges Basisband beinhalten, die zur Kommunikation über die Kommunikationsprotokolle der Mobilgeräte 104, 105 und 109 geeignet sind. Die Funkkomponente kann ferner einen rauscharmen Verstärker (LNA), zusätzliche Signalverstärker, einen Analog-Digital-Wandler (A/D-Wandler), einen oder mehrere Puffer und ein digitales Basisband beinhalten. In bestimmten Ausführungsformen können die von der Funkkomponente 824 erzeugten und über die Antenne 840 übertragenen Kommunikationssignale eine In-Phase-Komponente (I) und eine Quadraturphasenkomponente (Q) beinhalten, wobei die In-Phase-Komponente und die Quadraturphasenkomponente im wesentlichen orthogonal zueinander sind. In anderen beispielhaften Ausführungsformen kann das übertragene Kommunikationssignal durch alternative Transceiver-Implementierungen erzeugt werden, einschließlich beispielsweise volldigitaler polarer RF-Transceiver, wobei die I- und Q-Informationen vom kartesischen Koordinatensystem auf die Polarkoordinatensysteme (Amplitude und Phase) abgebildet werden können. Das Funkgerät kann ferner dazu konfiguriert sein, Phaseninformationen wie etwa IQ-Phasendaten auf ein von den Mobilgeräten 104, 105 und 109 übertragenes Signal zu messen und zu codieren.
Der Speicher 830 kann eine oder mehrere flüchtige und/oder nichtflüchtige Speichervorrichtungen beinhalten, einschließlich unter anderem magnetische Speichereinrichtungen, Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM), dynamischer RAM (DRAM), statischer RAM (SRAM), synchroner dynamischer RAM (SDRAM), SDRAM mit doppelter Datenübertragungsrate (DDR) (DDR-SDRAM), RAM-BUS-DRAM (RDRAM), Flash-Speichervorrichtungen, elektrisch löschbarer programmierbarer Nur-Lese-Speicher (EEPROM), nichtflüchtiger RAM (NVRAM), entfernbarer USB-Speicher (Universal Serial Bus) oder Kombinationen davon.
Der Speicher 830 kann Programmanweisungen speichern, die auf den Prozessoren 820 geladen und ausgeführt werden können, sowie Daten, die während der Ausführung dieser Programme erzeugt oder empfangen werden. In dem Speicher 830 können Softwaremodule gespeichert sein, einschließlich eines Betriebssystem- (O/S-) Moduls 832, eines Anwendungsmoduls 834, eines Kommunikationsmoduls 836 und eines Bildgebungsmoduls 840. Jedes der auf dem Speicher 830 gespeicherten Module und/oder Software kann bei Ausführung durch die Prozessoren 820 Funktionalität für die Mobilgeräte 104, 105 und 109 b erei tstell en.
Auf dem O/S-Modul 832 können ein oder mehrere Betriebssysteme gespeichert sein. Die Prozessoren 820 können dazu konfiguriert sein, auf ein oder mehrere Betriebssysteme zuzugreifen und diese auszuführen, die in dem (O/S-) Modul 832 gespeichert sind, um die Systemfunktionen der Mobilgeräte 104, 105 und 109 zu betreiben. Systemfunktionen, wie sie vom Betriebssystem verwaltet werden, können Speicherverwaltung, Prozessorressourcenverwaltung, Treiberverwaltung, Anwendungssoftwareverwaltung, Systemkonfiguration und dergleichen beinhalten. Das Betriebssystem kann eine beliebige Art geeigneter Betriebssysteme sein, einschließlich unter anderem Google® Android®, Microsoft® Windows®, Microsoft® Windows® Server®, Linux, Apple® OS-X® oder dergleichen.
Das Anwendungs- (Anwendungen-) Modul 834 kann Anweisungen und/oder Anwendungen enthalten, die von den Prozessoren 820 ausgeführt werden können, um eine oder mehrere Funktionen bereitzustellen, die den Mobilgeräten 104, 105 und 109 zugeordnet sind, einschließlich Funktionen, die sich auf das Bereitstellen von Bildern und Sensordaten und/oder drahtlosen Kommunikationssignalphaseninformationen sowie auf das Empfangen von Kartendaten und/oder Bildern zum Rendern an die Mitfahrer 102 und 108 und/oder einen Fahrer beziehen. Diese Anweisungen und/oder Anwendungen können in bestimmten Aspekten mit dem (O/S-) Modul 832 und/oder anderen Modulen der Mobilgeräte 104, 105 und 109 interagieren. Auf dem Anwendungsmodul 834 können Anweisungen, Software und/oder Code gespeichert sein, die von den Prozessoren 820 gestartet und/oder ausgeführt werden können, um eine oder mehrere damit verbundene Anwendungen und Funktionen auszuführen. Diese Anwendungen können unter anderem Funktionen wie Webbrowsing, Business, Kommunikation, Grafik, Textverarbeitung, Veröffentlichung, Tabellenkalkulation, Datenbanken, Spiele, Bildung, Unterhaltung, Medien, Projektplanung, Engineering, Zeichnen oder Kombinationen davon beinhalten.
Auf dem Kommunikationsmodul 836 können Anweisungen gespeichert sein, die es den Mobilgeräten 104, 105 und 109 bei Ausführung durch die Prozessoren 820 ermöglichen, eine Vielzahl von Kommunikationsfunktionen bereitzustellen. In einem Aspekt können die Prozessoren 820 durch Ausführen von Anweisungen, die in dem Kommunikationsmodul 836 gespeichert sind, dazu konfiguriert sein, Kommunikationssignale zu demodulieren und/oder zu decodieren, die von den Mobilgeräten 104, 105 und 109 über die Antenne 840 und das Funkgerät 824 empfangen werden. Die Prozessoren 820 können ferner dazu konfiguriert sein, eine oder mehrere Phaseninformationen zu identifizieren, die auf den empfangenen Kommunikationssignalen von der Mobilfunk-Basisstation 108 übertragen werden. Die empfangenen Kommunikationssignale können weiterhin Audio-, Bakendaten, Handshake-, Informations- und/oder andere Daten tragen. In einem anderen Aspekt können die Prozessoren 820 durch Ausführen von Anweisungen von mindestens dem Kommunikationsmodul 836 dazu konfiguriert sein, Kommunikationssignale über das Funkgerät 824 und/oder die Antenne 830 zu erzeugen und zu übertragen. Die Prozessoren können Kommunikationssignale codieren und/oder modulieren, die von den Mobilgeräten 104, 105 und 109 übertragen werden sollen.
Auf dem Bildgebungsmodul 840 können Anweisungen gespeichert sein, die bei Ausführung durch die Prozessoren 820 die Mobilgeräte 104, 105 und 109 dazu konfigurieren, eine Vielzahl von Bildgebungsfunktionen bereitzustellen. In einem Aspekt können die Prozessoren 820 dazu konfiguriert sein, das Erfassen eines Bildes über einen Bildsensor (nicht gezeigt) zu initiieren. In einigen beispielhaften Ausführungsformen können die Prozessoren 820 einige vorläufige Bildmanipulationsprozesse ausführen, bevor das Bild über das Netzwerk 106 an den Server 110 übertragen wird. In einigen anderen beispielhaften Ausführungsformen können die Prozessoren 820 dazu konfiguriert sein, nur Bilder zu übertragen, die möglicherweise Verbesserungen für die Abbildung einer bestimmten Struktur b erei tstell en.
9 zeigt eine beispielhafte Rechenumgebung gemäß den verschiedenen Ausführungsformen der Offenbarung. 9 veranschaulicht einen des einen oder der mehreren Server im Cloud-Netzwerk 106, die ein Ledger (d. h. ein Ledger 931) im Speicher (d. h. im Speicher 930) speichern, gemäß einem oder mehreren Aspekten der Offenbarung. Die beispielhafte Rechenumgebung 900 ist nur veranschaulichend und soll keine Einschränkung hinsichtlich des Verwendungsumfangs oder der Funktionalität der Architektur einer solchen Rechenumgebung suggerieren oder anderweitig vermitteln. Zusätzlich sollte die Rechenumgebung 900 nicht so ausgelegt werden, dass sie irgendeine Abhängigkeit oder Anforderung in Bezug auf eine oder eine Kombination von Komponenten aufweist, die in dieser beispielhaften Rechenumgebung dargestellt sind.
Die Rechenumgebung 900 stellt ein Beispiel einer Softwareumsetzung der verschiedenen Aspekte oder Merkmale der Offenbarung dar, bei der die Verarbeitung oder Ausführung der in Verbindung mit der hierin beschriebenen Leistungssteuerung beschriebenen Operationen, einschließlich der Verarbeitung von übermittelten Informationen (z. B. codiert, moduliert und/oder angeordnet) gemäß dieser Offenbarung, als Reaktion auf die Ausführung einer oder mehrerer Softwarekomponenten bei der Rechenvorrichtung 910 durchgeführt werden kann. Es versteht sich, dass die eine oder mehreren Softwarekomponenten die Rechenvorrichtung 910 oder jede andere Rechenvorrichtung, die solche Komponenten enthält, eine bestimmte Maschine zum Speichern von Vorgängen, die von den Mobilgeräten 104, 105 und 109 empfangen werden, und zum Speichern von Vorgängen, die zu den Mobilgeräten 104, 105 und 109 wie hierin beschrieben gesendet werden, rendern kann. Eine Softwarekomponente kann in einer oder mehreren computerzugänglichen Anweisungen verkörpert sein oder diese umfassen, z. B. computerlesbare und/oder computerausführbaren Anweisungen. Zumindest ein Teil der computerzugänglichen Anweisungen kann eine oder mehrere der hier offenbarten beispielhaften Techniken verkörpern. Um beispielsweise ein solches Verfahren zu verkörpern, kann zumindest der Teil der computerzugänglichen Anweisungen in einem nichtflüchtigen Computerspeichermedium bestehen bleiben (z. B. gespeichert, verfügbar gemacht oder gespeichert und verfügbar gemacht) und von einem Prozessor ausgeführt werden. Die eine oder mehreren computerzugänglichen Anweisungen, die eine Softwarekomponente verkörpern, können zu einem oder mehreren Programmmodulen zusammengesetzt werden, die beispielsweise an der Rechenvorrichtung 910 oder anderen Rechenvorrichtungen kompiliert, verknüpft und/oder ausgeführt werden können. Im Allgemeinen umfassen solche Programmmodule Computercode, Routinen, Programme, Objekte, Komponenten, Informationsstrukturen (z. B. Datenstrukturen und/oder Metadatenstrukturen) usw., die bestimmte Aufgaben (z. B. eine oder mehrere Operationen) als Reaktion auf die Ausführung durch einen oder mehrere Prozessoren, die in die Rechenvorrichtung 910 integriert oder funktional damit gekoppelt sein können, durchführen.
Die verschiedenen beispielhaften Ausführungsformen der Offenbarung können mit zahlreichen anderen Umgebungen oder Konfigurationen von Allzweck- oder Spezial-Rechensystemen betrieben werden. Beispiele bekannter Rechensysteme, Umgebungen und/oder Konfigurationen, die zur Umsetzung verschiedener Aspekte oder Merkmale der Offenbarung im Zusammenhang mit der Leistungssteuerung geeignet sein können, einschließlich der Verarbeitung von übermittelten Informationen (z. B. codiert, moduliert und/oder angeordnet) gemäß den hierin beschriebenen Merkmalen, können PCs, Server-Computer, Laptop-Geräte, Handheld-Rechenvorrichtungen wie etwa mobile Tablets tragbare Rechenvorrichtungen und Multiprozessorsysteme umfassen. Zusätzliche Beispiele können Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputer, Großrechner, Blade-Computer, speicherprogrammierbare Steuerungen, verteilte Computerumgebungen, die eines der oben genannten Systeme oder Geräte umfassen, und dergleichen beinhalten.
Wie dargestellt, kann die Rechenvorrichtung 910 einen oder mehrere Prozessoren 914, eine oder mehrere Eingabe/Ausgabe- (E / A-) Schnittstellen 916, einen Speicher 930 und eine Busarchitektur 932 (auch als Bus 932 bezeichnet) umfassen, die verschiedene Funktionselemente er Rechenvorrichtung 910 funktional koppelt. Der Bus 932 kann mindestens eines von einem Systembus, einem Speicherbus, einem Adressbus oder eine Nachrichtenbus beinhalten und kann den Austausch von Informationen (Daten, Metadaten und/oder Signalisierung) zwischen dem/den Prozessor/en (914), der/den E/A-Schnittstelle(n) 916 und/oder dem Speicher 930 oder den jeweiligen Funktionselementen darin ermöglichen. In Szenarien, in denen der oder die Prozessoren 914 mehrere Prozessoren beinhalten, kann die Rechenvorrichtung 910 paralleles Rechnen verwenden.
Die E/A-Schnittstelle(n) 916 können die Kommunikation von Informationen zwischen der Rechenvorrichtung und einer externen Vorrichtung, wie etwa einer anderen Rechenvorrichtung, z. B. einem Netzwerkelement oder einem Endbenutzergerät, ermöglichen oder auf andere Weise erleichtern. Eine solche Kommunikation kann eine direkte Kommunikation oder eine indirekte Kommunikation beinhalten, wie etwa den Informationsaustausch zwischen der Rechenvorrichtung 910 und der externen Vorrichtung über ein Netzwerk oder Elemente davon. Wie dargestellt, können die E/A-Schnittstellen 916 eine(n) oder mehrere Netzwerkadapter(n) 918, Peripherieadapter(n) 922 und Anzeigeeinheit(en) 926 umfassen. Solche Adapter können die Konnektivität zwischen der externen Vorrichtung und einem oder mehreren der Prozessoren 914 oder dem Speicher 930 ermöglichen oder erleichtern. In einem Aspekt kann mindestens einer des/der Netzwerkadapter 918 die Rechenvorrichtung 910 funktional mit einer oder mehreren Rechenvorrichtungen 970 über eine oder mehrere Verkehrs- und Signalisierungsleitungen 964 koppeln, die den Austausch von Verkehr 962 und Signalisierung 964 zwischen der Rechenvorrichtung 910 und der einen oder den mehreren Rechenvorrichtungen 970 ermöglichen oder erleichtern können. Eine solche Netzwerkkopplung, die zumindest teilweise von dem zumindest einen des/der Netzwerkadapter 918 bereitgestellt wird, kann in einer verdrahteten Umgebung, einer drahtlosen Umgebung oder beiden umgesetzt werden. Die Informationen, die von dem mindestens einen Netzwerkadapter übermittelt werden, können aus der Umsetzung einer oder mehrerer Operationen in einem Verfahren der Offenbarung resultieren. Eine solche Ausgabe kann eine beliebige Form visueller Darstellung sein, einschließlich unter anderem Text, Grafik, Animation, Audio, Tastsinn und dergleichen. In bestimmten Szenarien können die Rechenvorrichtungen 970 beliebige Mobilgeräte 104, 105 und 109 sein. Zusätzlich oder alternativ können die Anzeigeeinheit(en) 926 Funktionselemente (z. B. Leuchten, wie etwa Leuchtdioden; eine Anzeige, wie etwa eine Flüssigkristallanzeige (LCD), Kombinationen davon oder dergleichen) beinhalten. Dies kann die Steuerung des Betriebs der Rechenvorrichtung 910 ermöglichen oder die Übermittlung oder Offenlegung der Betriebszustände der Rechenvorrichtung 910 ermöglichen.
Die Funkeinheit 920 kann einen oder mehrere Prozessoren, Transceiver und Antennen umfassen, die kommunikativ mit dem einen oder den mehreren Prozessoren und Transceivern gekoppelt sind. Die Funkeinheit 920 kann Signale unter Verwendung der Antenne und des Transceivers übertragen und empfangen.
In einem Aspekt stellt der Bus 932 einen oder mehrere mögliche Typen von Busstrukturen dar, einschließlich eines Speicherbusses oder einer Speichersteuerung, eines Peripheriebusses, eines beschleunigten Grafik Ports und eines Prozessors oder eines lokalen Busses unter Verwendung einer beliebigen einer Vielzahl von Busarchitekturen Beispielsweise können solche Architekturen einen ISA-Bus (Industry Standard Architecture), einen MCA-Bus (Micro Channel Architecture), einen EISA-Bus (Enhanced ISA), einen lokalen VESA-Bus (Video Electronics Standards Association), einen AGP-Bus (Accelerated Graphics Port), und einen PCI-Bus (Peripheral Component Interconnects), einen PCI-Express-Bus, ein PCMCIA-Bus (PC Memory Card Industry Association), einen USB (Universal Serial Bus) und dergleichen umfassen. Der Bus 932 und alle hier beschriebenen Busse können über eine drahtgebundene oder drahtlose Netzwerkverbindung implementiert werden, und jedes der Subsysteme, einschließlich des Prozessors 914, des Speichers 930 und der Speicherelemente darin und der E / A-Schnittstelle (s) 916 kann in einem oder mehreren entfernten Computergeräten 970 an physisch getrennten Orten enthalten sein, die durch Busse dieser Form verbunden sind, um ein vollständig verteiltes System zu implementieren.
Die Rechenvorrichtung 910 kann eine Vielzahl von computerlesbaren Medien umfassen. Computerlesbare Medien können alle verfügbaren (und nicht flüchtigen) Medien sein, auf die eine Rechenvorrichtung zugreifen kann. In einem Aspekt können computerlesbare Medien nichtflüchtige Computerspeichermedien (oder computerlesbare nichtflüchtige Speichermedien) und Kommunikationsmedien umfassen. Beispielhafte computerlesbare nichtflüchtige Speichermedien können beliebige verfügbare Medien sein, auf die die Rechenvorrichtung 910 zugreifen kann, und können beispielsweise sowohl flüchtige als auch nichtflüchtige Medien und entfernbare und/oder nicht entfernbare Medien umfassen. In einem Aspekt kann der Speicher 930 computerlesbare Medien in Form von flüchtigem Speicher umfassen, wie etwa Direktzugriffsspeicher (RAM) und/oder nichtflüchtigen Speicher, wie etwa Nur-Lese-Speicher (ROM).
Der Speicher 930 kann ein Ledger 931 umfassen. Der Systeminformationsspeicher 933 kann Anweisungen umfassen, die den/die Prozessor(en) 914 veranlassen, jeden von den Mobilgeräten 104, 105 und 109 empfangenen Vorgang als Hash zu senden und jeden an die Mobilgeräte 104, 105 und 109 gesendeten Vorgang als Hash zu speichern, wie oben beschrieben. Solche Informationen können mindestens eines von Codeanweisungen, Informationsstrukturen oder dergleichen beinhalten. Mindestens eine der einen oder mehreren Schnittstellen 950 (z. B. Anwendungsprogrammierschnittstelle(n)) kann die Übermittlung von Informationen zwischen zwei oder mehreren Komponenten innerhalb des Funktionsbuchs 931 ermöglichen oder erleichtern. Die Informationen, die von dem mindestens einen Netzwerkadapter übermittelt werden, können aus der Umsetzung einer oder mehrerer Operationen in einem Verfahren der Offenbarung resultieren.
Zusätzlich kann der Speicher 930 computerzugängliche Anweisungen und Informationen (z. B. Daten und/oder Metadaten) umfassen, die den Betrieb und/oder die Verwaltung (z. B. Upgrades, Softwareinstallation, eine andere Konfiguration oder dergleichen) der Rechenvorrichtung 910 ermöglichen oder erleichtern. Dementsprechend kann der Speicher 930, wie dargestellt, ein Speicherelement 942 (bezeichnet als OS-Befehl(e) 942) umfassen, das ein oder mehrere Programmmodule umfassen, die ein oder mehrere Betriebssysteme verkörpern oder beinhalten, wie etwa ein Windows-Betriebssystem, Unix, Linux, Symbian, Android, Chromium und im Wesentlichen jedes Betriebssystem, das für mobile Rechenvorrichtungen oder verbundene Rechenvorrichtungen geeignet ist. In einem Aspekt kann die betriebliche und/oder architektonische Komplexität der Rechenvorrichtung 910 ein geeignetes Betriebssystem vorgeben. Der Speicher 930 umfasst auch einen Systeminformationsspeicher 946 mit Daten und/oder Metadaten, die den Betrieb und/oder die Verwaltung der Rechenvorrichtung 910 ermöglichen oder erleichtern. Auf Elemente der OS-Anweisung(en) 942 und des Systeminformationsspeichers 946 kann von mindestens einem der Prozessoren 914 zugegriffen werden oder sie können darauf bearbeitet werden.
Die Rechenvorrichtung 910 und/oder einer der Rechenvorrichtungen 970 kann ein Netzteil (nicht gezeigt) enthalten, die Komponenten oder Funktionselemente in solchen Geräten mit Strom versorgen kann. Das Netzteil kann ein wiederaufladbares Netzteil sein, z. B. eine wiederaufladbare Batterie, und es kann einen oder mehrere Transformatoren beinhalten, um einen Leistungspegel zu erzielen, der für den Betrieb der Rechenvorrichtung 910 und/oder einer der Rechenvorrichtung(en) 970 geeignet ist, sowie Komponenten, Funktionselemente und zugehörige Schaltungen. In bestimmten Szenarien kann das Netzteil an ein herkömmliches Stromnetz angeschlossen werden, um es aufzuladen und sicherzustellen, dass derartige Vorrichtungen betriebsbereit sind. In einem Aspekt kann das Netzteil eine E/A-Schnittstelle (z. B. einen der Netzwerkadapter 918) zum betriebsmäßigen Anschluss an das herkömmliche Stromnetz umfassen. In einem anderen Aspekt kann das Netzteil eine Energieumwandlungskomponente, wie beispielsweise ein Solarpanel, beinhalten, um zusätzliche oder alternative Energiequellen oder Autonomie für die Rechenvorrichtung 910 und/oder eine der Rechenvorrichtung(en) 970 bereitzustellen.
Die Rechenvorrichtung 910 kann in einer Netzwerkumgebung betrieben werden, indem Verbindungen zu einer oder mehreren entfernten Rechenvorrichtungen 970 verwendet werden. Eine entfernte Rechenvorrichtung kann beispielsweise ein PC, ein tragbarer Computer, ein Server, ein Router, ein Netzwerkcomputer, ein Peer-Gerät oder anderer gemeinsamer Netzwerkknoten usw. sein. Wie hierin beschrieben, können Verbindungen (physikalisch und/oder logisch) zwischen der Rechenvorrichtung 910 und einer Rechenvorrichtung der einen oder mehreren entfernten Rechenvorrichtungen 970 über eines oder mehrere von Verkehr 962 oder Signalisierung 964 hergestellt werden, die (eine) drahtgebundene Verbindung(en) und/oder (eine) drahtlose Verbindung(en) und mehrere Netzwerkelemente (wie Router oder Switches, Konzentratoren, Server und dergleichen) umfassen können, die ein lokales Netzwerk (LAN) und/oder ein Weitverkehrsnetz (WAN) bilden. Solche Netzwerkumgebungen sind in Wohnungen, Büros, unternehmensweiten Computernetzwerken, Intranets, lokalen Netzwerken und Weitverkehrsnetzwerken üblich und verbreitet.
Blöcke der Blockdiagramme und Ablaufdiagramme unterstützen Kombinationen von Mitteln zum Durchführen der angegebenen Funktionen, Kombinationen von Elementen oder Schritten zum Durchführen der angegebenen Funktionen und Programmanweisungsmittel zum Durchführen der angegebenen Funktionen. Es versteht sich ferner, dass jeder Block der Blockdiagramme und Ablaufdiagramme und Kombinationen aus Blöcken in den Blockdiagrammen und/oder Ablaufdiagrammen durch speziell dazu dienende hardwarebasierte Computersysteme, die die angegebenen Funktionen, Elemente oder Schritte durchführen, oder Kombinationen von speziell dazu dienender Hardware und Computeranweisungen, implementiert werden können.
Ausführungsbeispiele
In einigen Fällen können die nachfolgenden Beispiele zusammen oder getrennt durch die hierin beschriebenen Systeme und Verfahren umgesetzt werden.

Beispiel 1 kann ein Verfahren beinhalten, das Folgendes umfasst: Verarbeiten einer Fahrtanfrage, die von einem ersten Mobilgerät empfangen wurde, durch einen oder mehrere Computer, die mit mindestens einem Speicher verbunden sind; und Erzeugen eines ersten Hashs, der der Fahrtanfrage entspricht, durch den einen oder die mehreren Computer.
Beispiel 2 kann das Verfahren von Beispiel 1 beinhalten, ferner umfassend: Speichern des ersten Hashs in einem Ledger durch den einen oder die mehreren Computer, wobei das Ledger in dem mindestens einen Speicher gespeichert ist.
Beispiel 3 kann das Verfahren von Beispiel 1 und/oder ein anderes Beispiel hierin beinhalten, ferner umfassend: Übertragen der Fahrtanfrage durch den einen oder die mehreren Computer an ein zweites Mobilgerät.
Beispiel 4 kann das Verfahren von Beispiel 3 und/oder ein anderes Beispiel hierin beinhalten, ferner umfassend: Verarbeiten einer Fahrtantwort von dem zweiten mobilen Gerät durch den einen oder die mehreren Computer als Reaktion auf die Fahrtanfrage; und Erzeugen eines zweiten Hashs, der der Fahrtantwort entspricht, durch den einen oder die mehreren Computer.
Beispiel 5 kann das Verfahren von Beispiel 4 und/oder ein anderes Beispiel hierin beinhalten, ferner umfassend: Speichern des zweiten Hashs durch den einen oder die mehreren Computer in einem Ledger, wobei das Ledger in dem mindestens einen Speicher gespeichert ist.
Beispiel 6 kann das Verfahren von Beispiel 4 und/oder ein anderes Beispiel hierin beinhalten, ferner umfassend: Übertragen der Fahrtantwort durch den einen oder die mehreren Computer an das erste Mobilgerät.
Beispiel 7 kann eine Vorrichtung beinhalten, die Folgendes umfasst: mindestens einen Speicher, in dem computerausführbare Anweisungen gespeichert sind; und mindestens einen Prozessor, der dazu konfiguriert ist, auf den mindestens einen Speicher zuzugreifen und die computerausführbaren Anweisungen auszuführen, um: eine von einem ersten Mobilgerät empfangene Fahrtanfrage zu verarbeiten; und einen ersten Hash, der der Fahrtanfrage entspricht, zu erzeugen.
Beispiel 8 kann die Vorrichtung von Beispiel 7 und/oder ein anderes Beispiel hierin beinhalten, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, um: die Fahrtanfrage an ein zweites Mobilgerät zu übertragen.
Beispiel 9 kann die Vorrichtung von Beispiel 7 und/oder ein anderes Beispiel hierin beinhalten, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, um: eine Fahrtanfrage von dem zweiten Mobilgerät als Reaktion auf die Fahrtanfrage zu verarbeiten; ein zweites zweiten Hash entsprechend der Fahrtanfrage zu erzeugen; und den zweiten Hash in einem Ledger zu speichern.
Beispiel 10 kann die Vorrichtung von Beispiel 9 und/oder ein anderes Beispiel hierin beinhalten, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, um: die Fahrtanfrage an das erste Mobilgerät zu übertragen.
Beispiel 11 kann die Vorrichtung von Beispiel 8 und/oder ein anderes Beispiel hierin beinhalten, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, um: einen ersten Teil eines Fahrtanfrageschlüssels an das zweite Mobilgerät zu übertragen.
Beispiel 12 kann die Vorrichtung von Beispiel 11 und/oder ein anderes Beispiel hierin beinhalten, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, um: einen zweiten Teil des Fahrtanfrageschlüssels an das zweite Mobilgerät zu übertragen.
Beispiel 13 kann die Vorrichtung von Beispiel 9 und/oder ein anderes Beispiel hierin beinhalten, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, um: einen ersten Teil eines Fahrtantwortschlüssels an das erste Mobilgerät zu übertragen.
Beispiel 14 kann die Vorrichtung von Beispiel 13 und/oder ein anderes Beispiel hierin beinhalten, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, um: einen zweiten Teil des Fahrtantwortschüssels an das erste Mobilgerät zu übertragen.
Beispiel 15 kann ein Verfahren beinhalten, das Folgendes umfasst: Empfangen einer Fahrtanfrage von einem Mitfahrerkonto durch einen oder mehrere Computer; Übertragen einer Fahrtantwort durch den einen oder die mehreren Computer an das Mitfahrerkonto; Vergleichen eines ersten Standorts durch den einen oder die mehreren Computer mit einem aktuellen Standort, wenn sich der eine oder die mehreren Computer dem ersten Standort nähern; Bestimmen durch den einen oder die mehreren Computer, dass eine Differenz zwischen dem ersten Standort und dem aktuellen Standort geringer als ein Schwellenwert ist; Durchführen einer visuellen Analyse einer oder mehrerer Personen in der Nähe des aktuellen Standorts; Anfordern, dass sich ein Mitfahrer unter der einen oder den mehreren Personen hörbar identifiziert; und Bestimmen, zumindest teilweise basierend auf der hörbaren Identifizierung und der visuellen Identifizierung, dass der Mitfahrer dem Mitfahrerkonto zugeordnet ist.
Beispiel 16 kann das Verfahren von Beispiel 15 und/oder ein anderes Beispiel hierin beinhalten, ferner umfassend: Empfangen eines ersten Teils eines Fahrtanfrageschlüssels durch den einen oder die mehreren Computer; und Empfangen eines zweiten Teils des Fahrtanfrageschlüssels durch den einen oder die mehreren Computer.
Beispiel 17 kann das Verfahren von Beispiel 15 und/oder ein anderes Beispiel hierin beinhalten, ferner umfassend: Übertragen eines ersten Teils eines Fahrtanfrageschlüssels durch den einen oder die mehreren Computer; und Empfangen eines zweiten Teils des Fahrtanfrageschlüssels durch den einen oder die mehreren Computer.
Beispiel 18 kann das Verfahren von Beispiel 15 und/oder ein anderes Beispiel hierin beinhalten, ferner umfassend: Übertragen eines zweiten Fahrtanfrage-Hashs durch den einen oder die mehreren Computer; und Übertragen eines zweiten Fahrtantwort-Hashs durch den einen oder die mehreren Computer.
Beispiel 19 kann das Verfahren von Beispiel 15 und/oder ein anderes Beispiel hierin beinhalten, wobei das Durchführen der visuellen Analyse einer oder mehrerer Personen in der Nähe des aktuellen Standorts Folgendes umfasst: Vergleichen der einen oder mehreren Personen mit einem Bild des Mitfahrers, das in dem einen oder den mehreren Computern gespeichert ist.
Beispiel 20 kann das Verfahren von Beispiel 15 und/oder ein anderes Beispiel hierin beinhalten, wobei die hörbare Identifizierung zumindest teilweise auf dem Vergleichen eines hörbaren Signals des Mitfahrers mit einem hörbaren Signal basiert, das von dem Mitfahrerkonto empfangen wird, das dem Mitfahrer zugeordnet ist.

Viele Modifikationen und andere Umsetzungen der hierin dargelegten Offenbarung sind für die, die von den in der vorstehenden Beschreibung und den zugehörigen Zeichnungen dargestellten Lehren profitieren, ersichtlich. Daher versteht es sich, dass die Offenbarung nicht auf die spezifischen offenbarten Implementierungen beschränkt ist und dass Modifikationen und andere Implementierungen im Umfang der angefügten Patentansprüche beinhaltet sein sollen. Auch wenn spezifische Begriffe hierin benutzt wurden, werden sie lediglich in einem gattungsgemäßen und beschreibenden Sinne und nicht zum Zwecke der Einschränkung verwendet. Konditionalformulierungen, wie etwa unter anderem „kann“, „könnte“, „würde“ oder „möchte“, sollen, sofern nicht spezifisch anders angegeben oder im verwendeten Kontext anders zu versehen, allgemein vermitteln, dass gewisse Umsetzungen bestimmte Merkmale, Elemente und/oder Vorgänge beinhalten könnten, während andere Umsetzungen diese nicht beinhalten. Somit sollen derartige Konditionalformulierungen nicht allgemein implizieren, dass Merkmale, Elemente und/oder Vorgänge in irgendeiner Weise für eine oder mehrere Umsetzungen erforderlich sind, oder dass eine oder mehrere Umsetzungen notwendigerweise Logik zum Entscheiden, mit oder ohne Benutzereingabe oder Eingabeaufforderung, beinhalten, ob diese Merkmale, Elemente und/oder Vorgänge in einer konkreten Ausführungsform beinhaltet sind oder durchgeführt werden sollen.
Gemäß einer Ausführungsform ist die obige Erfindung ferner gekennzeichnet durch: Speichern des ersten Hashs in einem Ledger durch den einen oder die mehreren Computer, wobei das Ledger in dem mindestens einen Speicher gespeichert ist.
Gemäß einer Ausführungsform ist die obige Erfindung ferner gekennzeichnet durch: Speichern des zweiten Hashs in einem Ledger durch den einen oder die mehreren Computer, wobei das Ledger in dem mindestens einen Speicher gespeichert ist.
Gemäß einer Ausführungsform ist die obige Erfindung ferner gekennzeichnet durch: Übertragen der Fahrtantwort an das erste Mobilgerät durch den einen oder die mehreren Computer.
Gemäß einer Ausführungsform ist der mindestens eine Prozessor ferner dazu konfiguriert, die computerausführbaren Anweisungen auszuführen, um: die Fahrtantwort an das erste Mobilgerät zu übertragen.
Gemäß einer Ausführungsform basiert die hörbare Identifizierung zumindest teilweise auf dem Vergleichen eines hörbaren Signals des Mitfahrers mit einem hörbaren Signal, das von dem Mitfahrerkonto empfangen wird, das dem Mitfahrer zugeordnet ist.

Claims

Verfahren, umfassend: Verarbeiten einer Fahrtanfrage, die von einem ersten Mobilgerät empfangen wurde, durch einen oder mehrere Computer, die an mindestens einen Speicher gekoppelt sind; und Erzeugen eines ersten Hashs, der der Fahrtanfrage entspricht, durch den einen oder die mehreren Computer.
Verfahren nach Anspruch 1, ferner umfassend: Übertragen der Fahrtanfrage an ein zweites Mobilgerät durch den einen oder die mehreren Computer.
Verfahren nach Anspruch 2, ferner umfassend: Verarbeiten einer Fahrtantwort von dem zweiten Mobilgerät durch den einen oder die mehreren Computer als Reaktion auf die Fahrtanfrage; und Erzeugen eines zweiten Hashs, der der Fahrtantwort entspricht, durch den einen oder die mehreren Computer.
Vorrichtung, umfassend: mindestens einen Speicher, der computerausführbare Anweisungen speichert; und mindestens einen Prozessor, der dazu konfiguriert ist, auf den mindestens einen Speicher zuzugreifen und die computerausführbaren Anweisungen auszuführen, zum: Verarbeiten einer Fahrtanfrage, die von einem ersten Mobilgerät empfangen wurde; und Erzeugen eines ersten Hashs, der der Fahrtanfrage entspricht.
Vorrichtung nach Anspruch 4, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, zum: Übertragen der Fahrtanfrage an ein zweites Mobilgerät.
Vorrichtung nach Anspruch 4, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, zum: Verarbeiten einer Fahrtantwort von dem zweiten Mobilgerät als Reaktion auf die Fahrtanfrage; Erzeugen eines zweiten Hashs, der der Fahrtantwort entspricht; und Speichern des zweiten Hashs in einem Ledger.
Vorrichtung nach Anspruch 5, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, zum: Übertragen eines ersten Teils eines Fahrtanfrageschlüssels an das zweite Mobilgerät.
Vorrichtung nach Anspruch 7, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, zum: Übertragen eines zweiten Teils des Fahrtanfrageschlüssels an das zweite Mobilgerät.
Vorrichtung nach Anspruch 6, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, zum: Übertragen eines ersten Teils eines Fahrtantwortschlüssels an das erste Mobilgerät.
Vorrichtung nach Anspruch 9, wobei der mindestens eine Prozessor ferner dazu konfiguriert ist, die computerausführbaren Anweisungen auszuführen, zum: Übertragen eines zweiten Teils des Fahrtantwortschlüssels an das erste Mobilgerät.
Verfahren, umfassend: Empfangen einer Fahrtanfrage von einem Mitfahrerkonto durch einen oder mehrere Computer; Übertragen einer Fahrtantwort an das Mitfahrerkonto durch den einen oder die mehreren Computer; Vergleichen eines ersten Standorts mit einem aktuellen Standort durch den einen oder die mehreren Computer, wenn sich der eine oder die mehreren Computer dem ersten Standort nähern; Bestimmen durch den einen oder die mehreren Computer, dass eine Differenz zwischen dem ersten Standort und dem aktuellen Ort geringer als ein Schwellenwert ist, Durchführen einer visuellen Analyse einer oder mehrerer Personen in der Nähe des aktuellen Standorts, Anfordern, dass sich ein Mitfahrer unter der einen oder den mehreren Personen hörbar identifiziert; und Bestimmen, zumindest teilweise basierend auf der hörbaren Identifizierung und der visuellen Identifizierung, dass der Mitfahrer dem Mitfahrerkonto zugeordnet ist.
Verfahren nach Anspruch 11, ferner umfassend: Empfangen eines ersten Teils eines Fahrtanfrageschlüssels durch den einen oder die mehreren Computer; und Empfangen eines zweiten Teils des Fahrtanfrageschlüssels durch den einen oder die mehreren Computer.
Verfahren nach Anspruch 11, ferner umfassend: Übertragen eines ersten Teils eines Fahrtantwortschlüssels durch den einen oder die mehreren Computer; und Empfangen eines zweiten Teils des Fahrtantwortschlüssels durch den einen oder die mehreren Computer.
Verfahren nach Anspruch 11, ferner umfassend: Übertragen eines zweiten Fahrtanfrage-Hashs durch den einen oder die mehreren Computer; und Übertragen eines zweiten Fahrantwort-Hashs durch den einen oder die mehreren Computer.
Verfahren nach Anspruch 11, wobei das Durchführen der visuellen Analyse einer oder mehrerer Personen in der Nähe des aktuellen Standorts umfasst: Vergleichen der einen oder mehreren Personen mit einem Bild des Mitfahrers, das auf dem einen oder den mehreren Computern gespeichert ist.