DE102020106368A1

DE102020106368A1 - Teilen von fahrzeugdaten mit interessierten parteien

Info

Publication number: DE102020106368A1
Application number: DE102020106368.7A
Authority: DE
Inventors: Jaya Bharath R. Goluguri; Felipe G. Salles; Christopher J. Risberg; Joshua C. Batie
Original assignee: Toyota Motor North America Inc
Current assignee: Toyota Motor North America Inc
Priority date: 2019-03-29
Filing date: 2020-03-09
Publication date: 2020-10-01
Also published as: US20200312048A1; US20210383620A1; JP2020184322A; US10535207B1; CN111753325A; US20230316820A1; US11694486B2; JP7116755B2; US11100728B2

Abstract

Ein beispielhafter Vorgang kann das Bereitstellen eines Wertes für ein Verkehrsmittel basierend auf mit dem Verkehrsmittel zusammenhängenden Sensordaten beinhalten.

Description

Gebiet
Diese Anmeldung betrifft allgemein das Teilen von Fahrzeugdaten und insbesondere das Teilen von Fahrzeugdaten mit interessierten Parteien.
Hintergrund
Verkehrsmittel wie etwa Personenkraftwagen, Motorräder, Lastkraftwagen, Flugzeuge, Züge, etc. unterliegen bei ihrer Verwendung variierenden Verhältnissen wie etwa Straßenverhältnissen, Verkehrsmustern, Leistung anderer Fahrzeuge, Fahrzeugzuständen, Sicherheitsverhältnissen, Wetterverhältnissen, etc. Andere vom Inneren und/oder Äußeren eines Fahrzeugs identifizierbare Arten von Daten beinhalten Nutzeraktionen wie etwa Auswahl von Unterhaltung, Navigationsinformationen, Reifendruck, etc.
Derartige Daten können in einer Datenbank gespeichert werden, die Daten in einer einzigen Datenbank an einem bestimmten Ort vorhält. Dieser Ort ist häufig ein Zentralrechner, beispielsweise eine Desktop-Verarbeitungseinheit (CPU). Auf Informationen, die in einer zentralisierten Datenbank gespeichert sind, kann typischerweise von mehreren verschiedenen Stellen aus zugegriffen werden. Eine zentralisierte Datenbank ist aufgrund ihres einzigen Standortes einfach zu verwalten, pflegen und steuern, insbesondere zu Sicherheitszwecken. Innerhalb einer zentralisierten Datenbank wird Datenredundanz minimiert, da ein einziger Speicherort aller Daten auch impliziert, dass ein gegebener Datensatz nur einen primären Datensatz aufweist.
Jedoch leidet eine zentralisierte Datenbank unter erheblichen Nachteilen. Beispielsweise hat eine zentralisierte Datenbank eine einzige fehleranfällige Stelle. Insbesondere gehen im Fall von Null-Fehler-Toleranz-Überlegungen bei Auftreten eines Fehlers (zum Beispiel eines Hardware-, Firmware- und/oder eines Software-Fehlers) alle Daten innerhalb der Datenbank verloren und die Arbeit aller Anwender wird unterbrochen. Ferner, da ein Datenbankspeichersystem minimale oder keine Datenredundanz aufweist, sind unerwartet verlorengegangene Daten sehr schwer auf andere Weise als durch einen manuellen Vorgang aus einem Backup-Speicher wiederherzustellen. Herkömmlicherweise ist die Fähigkeit einer zentralisierten Datenbank, betrügerische Ansprüche von Entitäten zu verhindern, welche versuchen, Ansprüche für ein einziges Ereignis mehrfach geltend zu machen, beschränkt. Wichtige Informationen, wie etwa Zugriffsberechtigungen und persönliche Nutzerdaten, können weitere Datenverwaltungsinfrastruktur und Abläufe erfordern, um zu gewährleisten, dass Privatsphäre und Einverständnis mit der Weitergabe solcher Daten gewahrt bleiben.
Kurzfassung
Eine beispielhafte Ausführungsform kann ein System bereitstellen, aufweisend einen oder mehrere aus mindestens einem Sensor an einem Verkehrsmittel und einem Server zum Speichern einer Privatsphäreeinstellung für Daten, die dem mindestens einen Sensor zugeordnet ist, wobei basierend auf der Privatsphäreeinstellung Daten gesammelt und von dem mindestens einen Sensor an den Server übertragen werden, wobei die Privatsphäreeinstellung mit einer Anonymität eines dem Verkehrsmittel und den Daten zugeordneten Nutzers verbunden ist, wobei die Daten von dem Server zum Vollziehen einer Aktion verwendet werden, wobei der Server für das Verkehrsmittel einen Wert basierend auf einem Ergebnis der Aktion bereitstellt.
Eine andere beispielhafte Ausführungsform kann ein Verfahren bereitstellen, umfassend einen oder mehrere aus Speichern einer Privatsphäreeinstellung für Daten, die dem mindestens einen Sensor an einem Verkehrsmittel zugeordnet ist, Sammeln von Daten basierend auf der Privatsphäreeinstellung, die dem mindestens einen Sensor zugeordnet ist, Übertragen der Daten an einen Server, wobei die Privatsphäreeinstellung mit einer Anonymität eines dem Verkehrsmittel und den Daten zugeordneten Nutzers verbunden ist, Vollziehen einer Aktion bei dem Server unter Verwendung der Daten, und Bereitstellen, bei dem Server, eines Wertes für das Verkehrsmittel basierend auf dem Ergebnis der Aktion.
Eine weitere beispielhafte Ausführungsform kann ein nichttransitorisches computerlesbares Medium bereitstellen, das Anweisungen aufweist, die, wenn von einem Prozessor gelesen, den Prozessor veranlassen, einen oder mehrere durchzuführen aus: Speichern einer Privatsphäreeinstellung für Daten, die mindestens einem Sensor an einem Verkehrsmittel zugeordnet ist, Sammeln von Daten basierend auf der Privatsphäreeinstellung, die dem mindestens einen Sensor zugeordnet ist, Übertragen der Daten an einen Server, wobei die Privatsphäreeinstellung mit einer Anonymität eines dem Verkehrsmittel und den Daten zugeordneten Nutzers verbunden ist, Vollziehen einer Aktion bei dem Server unter Verwendung der Daten, und Bereitstellen, bei dem Server, eines Wertes für das Verkehrsmittel basierend auf dem Ergebnis der Aktion.
Noch eine weitere beispielhafte Ausführungsform kann ein System bereitstellen, aufweisend einen Server, der ausgelegt ist zum Durchführen eines oder mehrerer aus: Zuweisen von Sensordaten von einem Verkehrsmittel zu einer oder mehreren Kategorien basierend auf Sensordaten-Teilungsberechtigungen, welche in einem Profil gespeichert sind, das einem Verkehrsmittel zugeordnet ist, Senden der Sensordaten an einen oder mehrere Empfänger basierend auf der einen oder den mehreren Kategorien und Bereitstellen eines Wertes für das Verkehrsmittel durch den einen oder die mehreren Empfänger basierend auf den Sensordaten mittels eines Smart Contracts, der sich auf die an den einen oder die mehreren Empfänger gesendeten Sensordaten, den für das Verkehrsmittel bereitgestellten Wert, ein den gesendeten Sensordaten zugeordnetes Datum und ein dem bereitgestellten Wert zugeordnetes Datum bezieht.
Noch eine weitere beispielhafte Ausführungsform kann ein Verfahren bereitstellen, umfassend einen oder mehrere aus Zuweisen von Sensordaten von einem Verkehrsmittel zu einer oder mehreren Kategorien basierend auf Sensordaten-Teilungsberechtigungen, die in einem Profil gespeichert sind, das einem Verkehrsmittel zugeordnet ist, Senden der Sensordaten an einen oder mehrere Empfänger basierend auf der einen oder den mehreren Kategorien, und Bereitstellen eines Wertes für das Verkehrsmittel durch den einen oder die mehreren Empfänger basierend auf den Sensordaten mittels eines Smart Contracts, der sich auf die an den einen oder die mehreren Empfänger gesendeten Sensordaten, den für das Verkehrsmittel bereitgestellten Wert, ein den gesendeten Sensordaten zugeordnetes Datum und ein dem bereitgestellten Wert zugeordnetes Datum bezieht.
Noch eine weitere beispielhafte Ausführungsform kann ein nichttransitorisches computerlesbares Medium bereitstellen, das Anweisungen aufweist, die, wenn von einem Prozessor gelesen, den Prozessor veranlassen, einen oder mehrere durchzuführen aus: Zuweisen von Sensordaten von einem Verkehrsmittel zu einer oder mehreren Kategorien basierend auf Sensordaten-Teilungsberechtigungen, die in einem Profil gespeichert sind, das einem Verkehrsmittel zugeordnet ist, Senden der Sensordaten an einen oder mehrere Empfänger basierend auf der einen oder den mehreren Kategorien, und Bereitstellen eines Wertes für das Verkehrsmittel durch den einen oder die mehreren Empfänger basierend auf den Sensordaten mittels eines Smart Contracts, der sich auf die an den einen oder die mehreren Empfänger gesendeten Sensordaten, den für das Verkehrsmittel bereitgestellten Wert, ein den gesendeten Sensordaten zugeordnetes Datum und ein dem bereitgestellten Wert zugeordnetes Datum bezieht.
Figurenliste

1A veranschaulicht ein Diagramm eines Verkehrsmittelsensordaten-Sammelsystems gemäß beispielhaften Ausführungsformen.
1B veranschaulicht ein Diagramm eines Verkehrsmittelsensordaten-Sammelsystems, das ein verteiltes Transaktionsregister bzw. einen Distributed Ledger nutzt, gemäß beispielhaften Ausführungsformen.
1C veranschaulicht ein Diagramm von Fahrzeugsensordaten, die verarbeitet und an interessierte Dritte verteilt werden, gemäß beispielhaften Ausführungsformen.
2A veranschaulicht eine beispielhafte Peer-Knoten-Konfiguration gemäß beispielhaften Ausführungsformen.
2B veranschaulicht eine Konfiguration eines verteilten Transaktionsregisters gemäß beispielhaften Ausführungsformen.
3 veranschaulicht ein Nachrichtendiagramm eines Verkehrsmittelsensordaten-Sammelsystems gemäß beispielhaften Ausführungsformen.
4A veranschaulicht ein Flussdiagramm eines Verkehrsmittelsensordaten-Sammelprozesses gemäß beispielhaften Ausführungsformen.
4B veranschaulicht ein weiteres Flussdiagramm eines Verkehrsmittelsensordaten-Sammelprozesses gemäß beispielhaften Ausführungsformen.
4C veranschaulicht ein anderes Flussdiagramm eines Verkehrsmittelsensordaten-Sammelprozesses gemäß beispielhaften Ausführungsformen.
4D veranschaulicht noch ein weiteres Flussdiagramm eines Verkehrsmittelsensordaten-Sammelprozesses gemäß beispielhaften Ausführungsformen.
4E veranschaulicht noch ein anderes Flussdiagramm eines Verkehrsmittelsensordaten-Sammelprozesses gemäß beispielhaften Ausführungsformen.
5A veranschaulicht eine beispielhafte Blockchain-Verkehrsmittel-Konfiguration gemäß beispielhaften Ausführungsformen.
5B veranschaulicht eine andere beispielhafte Blockchain-Verkehrsmittel-Konfiguration gemäß beispielhaften Ausführungsformen.
5C veranschaulicht eine weitere beispielhafte Blockchain-Verkehrsmittel-Konfiguration gemäß beispielhaften Ausführungsformen.
6 veranschaulicht einen beispielhaften Datenblock gemäß beispielhaften Ausführungsformen.
7 veranschaulicht ein beispielhaftes System, das eines oder mehrere der beispielhaften Ausführungsformen unterstützt.

Detaillierte Beschreibung
Es versteht sich ohne Weiteres, dass die vorliegenden, in den Figuren hierin allgemein beschriebenen und veranschaulichten Komponenten in einer Vielzahl von unterschiedlichen Konfigurationen angeordnet und gestaltet sein können. Demnach ist die folgende detaillierte Beschreibung der Ausführungsformen mindestens eines Verfahrens, einer Vorrichtung, eines nichttransitorischen computerlesbaren Mediums und Systems wie in den angehängten Figuren dargestellt nicht dazu vorgesehen, den beanspruchten Umfang der Anmeldung zu beschränken, sondern ist lediglich repräsentativ für ausgewählte Ausführungsformen.
Die vorliegenden, in dieser Schrift beschriebenen Merkmale, Strukturen oder Eigenschaften können auf irgendeine geeignete Weise in einer oder mehreren Ausführungsformen kombiniert werden. Beispielsweise weist die Verwendung der Begriffe „beispielhafte Ausführungsformen“, „einige Ausführungsformen“ oder anderer ähnlicher Formulierungen in dieser Schrift auf die Tatsache hin, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft, die im Zusammenhang mit der Ausführungsform beschrieben ist, in mindestens einer Ausführungsform beinhaltet sein kann. Demnach bezieht sich das Auftreten der Begriffe „beispielhafte Ausführungsformen“, „in einigen Ausführungsformen“, „in anderen Ausführungsformen“ oder anderer ähnlicher Formulierungen in dieser Schrift nicht notwendigerweise auf die gleiche Gruppe von Ausführungsformen, und die beschriebenen Merkmale, Strukturen oder Eigenschaften können auf irgendeine geeignete Weise in einer oder mehreren Ausführungsformen kombiniert werden.
Darüber hinaus wird in der Beschreibung von Ausführungsformen zwar womöglich der Begriff „Nachricht“ verwendet, doch ist die Anmeldung auf viele Arten von Netzwerkdaten, wie etwa Paket, Rahmen, Datagramm, etc. anwendbar. Der Begriff „Nachricht“ umfasst auch Paket, Rahmen, Datagramm und beliebige Äquivalente hiervon. Ferner werden in beispielhaften Ausführungsformen zwar womöglich bestimmte Arten von Nachrichten und Nachrichtenübermittlung dargestellt, doch sind sie nicht auf eine bestimmte Art von Nachricht beschränkt, und die Anmeldung ist nicht auf eine bestimmte Art von Nachrichtenübermittlung beschränkt.
Beispielhafte Ausführungsformen sehen Verfahren, Systeme, Komponenten, nichttransitorische computerlesbare Medien, Vorrichtungen und/oder Netzwerke vor, welche ein Sensordatensammel- und -verifizierungssystem für ein Verkehrsmittel (hierin auch als ein Fahrzeug bezeichnet) sowie eine Fahrzeugdatenverteilungs-Konfiguration bereitstellen. Die Sensordaten, die in Form von Kommunikationsaktualisierungsnachrichten wie etwa Drahtlosdatennetz-Kommunikationen und/oder drahtgebundenen Kommunikationsnachrichten empfangen werden, können empfangen und verarbeitet werden, um Nutzerfahrzeugprofilberechtigungen, interessierte Dritte, die zum Empfangen solcher Daten registriert sind, und andere Verarbeitungskomponenten, welche die empfangenen Sensordaten identifizieren und interpretieren, zu identifizieren.
Innerhalb der Kommunikationsinfrastruktur ist eine dezentralisierte Datenbank ein verteiltes Speichersystem, das mehrere miteinander kommunizierende Knoten beinhaltet. Eine Blockchain ist ein Beispiel für eine dezentralisierte Datenbank, die eine unveränderliche Nur-Hinzufüge-(„Append-Only“)-Datenstruktur (d.h. ein verteiltes Transaktionsregister bzw. einen Distributed Ledger) beinhaltet, welche imstande ist, Datensätze zwischen nicht vertrauenswürdigen Parteien vorzuhalten. Die nicht vertrauenswürdigen Parteien werden hierin als Peers, Knoten oder Peer-Knoten bezeichnet. Jeder Peer hält eine Kopie der Datenbankdatensätze vor, und kein einzelner Peer kann die Datenbank-Datensätze abändern, ohne dass zwischen den verteilten Peers ein Konsens bzw. eine Übereinkunft erzielt wird. Beispielsweise können die Peers ein Konsensprotokoll ausführen, um Blockchain-Speichereinträge zu validieren, die Speichereinträge in Blöcke zu gruppieren und über die Blöcke eine Hashkette zu erstellen. Dieser Prozess bildet das Transaktionsregister durch Ordnen der Speichereinträge, wie dies für eine Konsistenz erforderlich ist. In einer öffentlichen oder berechtigungsfreien Blockchain kann jedermann ohne eine spezielle Identität teilnehmen. Öffentliche Blockchains können Kryptowährungen einschließen und Konsens auf Grundlage verschiedener Protokolle wie etwa Proofof-Work (PoW) verwenden. Hingegen sieht eine berechtigungspflichtige Blockchain-Datenbank ein System vor, das Interaktionen zwischen einer Gruppe von Entitäten sichern kann, die ein gemeinsames Ziel verfolgen, einander jedoch nicht völlig vertrauen oder vertrauen können, wie etwa Unternehmen, die Geld, Waren, Informationen und dergleichen austauschen. Die vorliegende Anmeldung kann im Rahmen einer berechtigungspflichtigen und/oder einer berechtigungsfreien Blockchain funktionieren.
Smart Contracts sind vertrauenswürdige verteilte Anwendungen, welche manipulationssichere Eigenschaften der Datenbank mit gemeinsamem oder verteiltem Transaktionsregister (d.h. auch in Form einer Blockchain bzw. Blockkette) sowie eine zugrundeliegende Vereinbarung zwischen Mitgliedsknoten wirksam einsetzen, was als ein Endorsement oder eine Endorsement Policy bezeichnet wird. Im Allgemeinen werden Blockchain-Einträge gebilligt („endorsed“), bevor sie in der Datenbank festgeschrieben werden, während nicht gebilligte Einträge unberücksichtigt bleiben. Eine typische Endorsement Policy erlaubt es ausführbarem Smart-Contract-Code, Endorser für einen Eintrag in Form einer Gruppe von Peer-Knoten zu spezifizieren, die für ein Endorsement notwendig sind. Wenn ein Client den Eintrag an die in der Endorsement Policy spezifizierten Peers sendet, wird der Eintrag ausgeführt, um den Eintrag zu validieren. Nach Validierung treten die Einträge in eine Ordnungsphase ein, in der ein Konsensprotokoll verwendet wird, um eine geordnete Abfolge von in Blöcke gruppierten gebilligten Einträgen zu erzeugen.
Knoten sind die Kommunikationsentitäten des Blockchain-Systems. Ein „Knoten“ kann eine logische Funktion in dem Sinne durchführen, dass mehrere Knoten unterschiedlicher Typen auf dem gleichen physischen Server ausgeführt werden können. Knoten sind in vertrauenswürdige Domänen gruppiert und sind logischen Entitäten zugeordnet, von denen sie auf unterschiedliche Weise gesteuert werden. Knoten können unterschiedliche Typen beinhalten, wie etwa einen Client- oder Einreicher-Client-Knoten, der einen Eintragsaufruf bei einem Endorser (z.B. Peer) einreicht und Eintragsvorschläge an einen Ordnungsdienst (z.B. Ordnerknoten) überträgt. Ein anderer Typ von Knoten ist ein Peer-Knoten, welcher durch einen Client eingereichte Einträge empfangen, die Einträge festschreiben und einen Zustand sowie eine Kopie des Transaktionsregisters von Blockchain-Einträgen vorhalten kann. Peers können auch die Rolle eines Endorser innehaben, obzwar dies kein Erfordernis ist. Ein Ordnungsdienst-Knoten bzw. Orderer ist ein Knoten, der den Kommunikationsdienst für alle Knoten betreibt und eine Zustellgarantie implementiert, wie etwa eine Übertragung an jeden der Peer-Knoten in dem System, wenn er Einträge festschreibt und einen World State bzw. Weltzustand der Blockchain modifiziert, was ein anderer Name für den anfänglichen Blockchain-Eintrag ist, der normalerweise Steuerungs- und Einrichtungsinformationen beinhaltet.
Ein Transaktionsregister ist ein sequenzierter, manipulationssicherer Datensatz aller Zustandsübergänge einer Blockchain. Zustandsübergänge können aus Aufrufen von ausführbarem Smart-Contract-Code (d.h. Einträgen), welche von teilnehmenden Parteien (z.B. Client-Knoten, Ordnerknoten, Endorser-Knoten, Peer-Knoten, etc.) eingereicht werden, resultieren. Ein Eintrag kann dazu führen, dass eine Gruppe von Asset-Schlüssel-/Wert-Paaren in dem Transaktionsregister als ein oder mehrere Operanden festgeschrieben werden, wie etwa Erstellen, Aktualisieren und Löschen, und dergleichen. Das Transaktionsregister beinhaltet eine Blockchain (auch als eine Kette bezeichnet), welche zum Speichern eines unveränderlichen, sequenziellen Datensatzes in Blöcken verwendet wird. Das Transaktionsregister beinhaltet auch eine Zustandsdatenbank, welche einen aktuellen Zustand der Blockchain vorhält. Es gibt typischerweise ein Transaktionsregister je Kanal. Jeder Peer-Knoten hält eine Kopie des Transaktionsregisters für jeden Kanal vor, von dem er ein Mitglied ist.
Eine Kette ist ein Eintragsprotokoll, das aus Hash-verknüpften Blöcken aufgebaut ist, und jeder Block enthält eine Abfolge von N Einträgen, wobei N größer oder gleich eins ist. Der Blockkopf beinhaltet ein Hash der Einträge des Blocks sowie ein Hash des Kopfs des vorherigen Blocks. Auf diese Weise können alle Einträge in das Transaktionsregister sequenziert und miteinander kryptographisch verknüpft werden. Demgemäß ist es nicht möglich, die Transaktionsregister-Daten zu manipulieren, ohne die Hash-Verknüpfungen zu lösen. Ein Hash eines zuletzt hinzugefügten Blockchain-Blocks stellt jeden Eintrag in der Kette dar, der ihm vorausgeht, womit sichergestellt werden kann, dass sich alle Peer-Knoten in einem konsistenten und vertrauenswürdigen Zustand befinden. Die Kette kann in einem Peer-Knoten-Dateisystem (d.h. lokaler, angeschlossener Speicher, Cloud, etc.) gespeichert sein, das die Nur-Hinzufüge-Beschaffenheit der Blockchain-Arbeitsweise effizient unterstützt.
Der aktuelle Zustand des unveränderlichen Transaktionsregisters stellt die neuesten Werte für alle Schlüssel dar, die in dem Ketteneintragsprotokoll beinhaltet sind. Da der aktuelle Zustand die neuesten, einem Kanal bekannten Schlüsselwerte darstellt, wird er mitunter als ein World State bzw. Weltzustand bezeichnet. Aufrufe von ausführbarem Smart-Contract-Code führen Einträge gegen die aktuellen Zustandsdaten des Transaktionsregisters aus. Um diese Interaktionen mit ausführbarem Smart-Contract-Code effizient werden zu lassen, können die neuesten Werte der Schlüssel in einer Zustandsdatenbank gespeichert werden. Die Zustandsdatenbank kann einfach eine indizierte Sicht in das Eintragsprotokoll der Kette sein und kann daher jederzeit aus der Kette regeneriert werden. Die Zustandsdatenbank kann beim Starten von Peer-Knoten und vor der Annahme von Einträgen automatisch wiedererlangt (oder erforderlichenfalls generiert) werden.
Eine Blockchain ist dahingehend von einer herkömmlichen Datenbank verschieden, dass die Blockchain nicht ein zentraler Speicher, sondern vielmehr ein dezentralisierter, unveränderlicher und sicherer Speicher ist, in dem sich Knoten an Veränderungen an Datensätzen in dem Speicher beteiligen müssen. Einige inhärent mit Blockchain verbundene Merkmale, die bei der Umsetzung der Blockchain hilfreich sind, umfassen ein unveränderliches Transaktionsregister, Smart Contracts, Sicherheit, Privatsphäre, Dezentralisierung, Konsens, Endorsement, Zugänglichkeit und dergleichen, ohne jedoch hierauf beschränkt zu sein.
Beispielhafte Ausführungsformen sehen eine Möglichkeit vor, um Fahrzeugsensorinformationen durch eine berechtigungserteilende Entität und somit auf eine „dezentralisierte“ Weise, wie etwa über eine Blockchain-Mitgliedschaftsgruppe, zu kontrollieren. Jede interessierte Partei (d.h. Fahrer, Unternehmen, Agentur, etc.) möchte womöglich die Offenlegung von privaten Informationen beschränken, und daher können die Blockchain und deren Unveränderlichkeit die Offenlegung beschränken und Berechtigungen für jedes einzelne Nutzerfahrzeugprofil verwalten. Ein Smart Contract kann verwendet werden, um Vergütung, Berechtigungsbestimmung und -vergabe für Entitäten bereitzustellen, welche Zugang zu solchen Fahrzeugsensordaten (oder Fahrzeugsensorinformationen) begehren. Auch können, falls ein Betrug festgestellt wird, die notwendigen Informationen zwischen den Entitäten basierend auf einem mit der Blockchain verbundenen „Konsens“-Ansatz geteilt werden. Ein solcher Ansatz wäre in einer herkömmlichen zentralisierten Datenbank nicht umsetzbar. Auch hat jedes Unternehmen sein eigenes unabhängiges Informationssystem, so dass praktisch nicht davon auszugehen ist, dass dieser Blockchain-basierte Ansatz auf einem zentralisierten System implementierbar wäre, da der Konsensmechanismus der Blockchain zum Teilen von Informationen genutzt wird, wenn eine Berechtigung erforderlich ist.
1A veranschaulicht ein Netzwerkdiagramm eines Fahrzeugsensordaten-Sammelsystems gemäß beispielhaften Ausführungsformen. Unter Bezugnahme auf 1A beinhaltet das Netzwerk 100 ein oder mehrere Fahrzeuge, welche Sensoren zum Sammeln von Sensordaten beinhalten. In diesem Beispiel ist ein Fahrzeug 108 mit verschiedenen Sensoren 106 veranschaulicht, welche während der Herstellung oder im Rahmen einer Nachrüstung installiert werden können. Die Sensoren 106 können fahrzeugbezogene Daten sowie umgebungs- und straßenbezogene Daten erfassen, zu denen eine Mehrzahl von unterschiedlichen Sensordatensätzen gehören können, welche von einer Mehrzahl von unterschiedlichen Sensortypen und einer oder mehreren Rechenvorrichtungen gesammelt werden. Die Sensordaten werden auf einen Sensordatenserver 110 hochgeladen oder von diesem abgerufen, welcher die Sensordaten 112 verarbeiten kann und Fahrzeugdatenempfängerprofile (VDR-Profile) 114 zum Kombinieren mit den Sensordaten zu analytischen oder Verteilungszwecken identifizieren kann. In einer Ausführungsform kann ein Empfänger eine beliebige Vorrichtung beinhalten, die einen Prozessor und einen Speicher aufweist, wie etwa einen Client, einen Server, einen PC, einen Laptop, ein Mobiltelefon, eine Smart Watch, etc. In einer anderen Ausführungsform kann der Empfänger einen oder mehrere Nutzer beinhalten, die einer Vorrichtung zugeordnet sein können, welche einen Prozessor und einen Speicher beinhaltet.
Die Sensoren 106 können an einem beliebigen Teil des Fahrzeugs 108 angebracht werden und können sich an der Außenseite und/oder der Innenseite des Fahrzeugs 108 befinden. Die Sensoren können mit einer zentralen Steuerung des Fahrzeugs fest verdrahtet sein oder können über Kommunikationsprotokolle wie etwa BLUETOOTH, IEEE-Standards, RFID, NFC und/oder andere Protokolle und Konfigurationen mit einer zentralen Steuerung des Fahrzeugrechners in drahtloser Verbindung stehen. Die Daten können von der zentralen Recheneinheit des Computers wie etwa einem bordeigenen Rechner, einem Smartphone eines Nutzers, einem kompatiblen Mobilgerät, etc. übertragen werden. Die Daten können über ein zellulares Kommunikationsnetzwerk über eine SIM-Karte oder ein anderes in dem Fahrzeug installiertes Modul gesendet werden. Die erfassten Inhalte können eine oder mehrere aus einer innerhalb des Fahrzeugs durchgeführten Aktion, einer außerhalb des Fahrzeugs durchgeführten Aktion und einer durch das Fahrzeug durchgeführten Aktion beinhalten, wie etwa Radiosenderwahl, Audioaufnahmen, Verwendung von Mobilgeräten innerhalb des Fahrzeugs, innerhalb des Fahrzeugs geführte Telefonate, Browser-Verlauf mindestens einer der Rechenvorrichtungen, über mindestens eine Rechenvorrichtung innerhalb des Fahrzeugs getätigte Käufe, Bewegung des Fahrzeugs, Navigation des Fahrzeugs, ein Zusammenstoß des Fahrzeugs, Geschwindigkeit des Verkehrsmittels, Beschleunigung des Fahrzeugs, eine mit dem Verkehrsmittel verbundene Diagnose, einschließlich Batterieladestand, Benzinstand, Ölstand, Temperatur des Fahrzeugs, Standort des Fahrzeugs, erfasster Verkehr nahe dem Fahrzeug, Informationen zu anderen Fahrzeugen, etc.
Die Typen von Sensoren 106 beinhalten einen oder mehrere aus Bewegungssensoren, Sonarsensoren, Lidar-Sensoren, Beschleunigungssensoren, Berührungssensoren, Näherungssensoren, Temperatursensoren, Geschwindigkeitssensoren, Schallsensoren, Infrarotsensoren, Kollisionssensoren, Füllstandsensoren, Reifendrucksensoren, Standortbestimmungssensoren, Ultraschallsensoren, Kamerasensoren, Aktivitätssensoren, chemischen Sensoren, Fluidsensoren, Drucksensoren, optischen Sensoren und biometrischen Sensoren.
In dem Bestreben, für Halter autonomer Fahrzeuge und/oder fahrergelenkter Fahrzeuge einen Anreiz zu schaffen, die von den Sensoren ihrer Fahrzeuge gesammelten Daten zu teilen, können einige VDRs bereit sein, jenen Haltern und/oder Betreibern Anreize zu bieten, die zum Teilen der Daten berechtigt sind und bereit sind, ihre Einwilligung zum Teilen solcher Fahrzeugsensordaten zu erteilen. Die geteilten Daten können sich auf einen Datentyp oder mehrere Datentypen, eine einmalige Nutzung, Mehrfachnutzung und/oder Dauernutzung beziehen. Wenn ein Fahrzeug Sensordaten von dem/den Sensor(en) 106 oder über Computervorrichtungen eines Nutzers und die bordeigene Rechenvorrichtung 102 und 104 sammelt, können die Daten in Rohform gesammelt und verteilt werden oder können vor der Verteilung nach Sensortyp und/oder Datentyp gesammelt und geordnet werden. Im Sinne dieses Beispiels können die Sensordaten 112 nach Maßgabe der Vorrichtung, welche die Sensordaten erzeugt hat, geordnet werden. Auch können die Computerselektionen als Sensordaten gelten, wenn es sich bei dem Inhalt der Daten tatsächlich um nutzerseitige Aktionen, wie etwa Infotainment-Auswahl, handelt, die nicht explizit von einem „Sensor“ stammen müssen, jedoch mit den Sensordaten 112 aufgezeichnet und an den Sensor-Server 110 übermittelt werden können. Die Führungsentität, die für das Verwalten des Sensordaten-Servers 110 zuständig ist, kann der Fahrzeughalter und/oder -betreiber oder ein Dritter sein, der die Sensordaten und die VDR-Profilkonten 114 verwaltet. Bei Betrieb können die VDR-Profile 114 bestimmte Sensordaten ausweisen, für deren Empfang jene VDRs registriert sind. Die Sensordaten können einen Sensor anhand seines Typs, seiner Kennung, seines Herstellers, etc. ausweisen. Ein anderes Beispiel kann ein Token-Austauschsystem zum Empfangen von Sensordaten und Bereitstellen eines Guthabens für solche Daten beinhalten. Die konkret eingesetzten Token könnten einer bestimmten Blockchain zu eigen sein oder in Form einer Kryptowährung vorliegen. Auch andere Arten von Guthaben oder digitalen Werten könnten dem Fahrzeughalter (und/oder -betreiber) im Austausch für die geteilten Fahrzeugsensordaten zur Verfügung gestellt werden. In einem Beispiel kann ein Fahrzeughalter wählen, den empfangenen Wert einer Entität zuzuleiten. Wenn sich Datensätze von Sensorwerten anhäufen, können die Daten kategorisiert werden, wie etwa Verkehrsdaten (d.h. Sensoren, welche Verkehr und Verkehrsmuster identifizieren), Fahrbahndaten (d.h. Sensoren, welche Straßenverhältnisse identifizieren), Standortdaten (d.h. Sensoren, welche Fahrzeugstandorte und Navigationsrouten identifizieren), private Nutzungsdaten (d.h. Sensoren, welche Nutzeraktivitäten und -selektionen identifizieren), etc. Ein Fahrzeughalter und/oder -betreiber könnte jeden Block seiner Fahrzeugsensordaten für einen festgelegten Betrag einer Kryptowährung oder anderer Arten von Werten anbieten. In anderen Ausführungsformen kann ein Fahrzeuginsasse, der eine Vorrichtung steuert, die zum Kommunizieren mit dem Sensordaten-Server imstande ist, eine ähnliche Funktion durchführen und hierfür einen Wert erhalten. In weiteren Ausführungsformen kann das Verkehrsmittel selbst den Wert gänzlich (oder teilweise) erhalten.
Die Daten können in einer Blockchain gespeichert werden, die in dem Fahrzeug 108, auf dem Server 110 und/oder in einem Cloud-Netzwerk vorhanden ist. Die Blockchain kann auch die Verwaltung der Werte erleichtern, welche, sei es auf herkömmliche Weise oder über Tokens oder andere Entlohnungsarten, im Gegenzug für Datenzugang bereitgestellt werden. In einem Beispiel gibt das Fahrzeug 108 seine Sensordaten 112 über ein Drahtloskommunikationsnetzwerk (z.B. Mobilfunknetz) an die Cloud ab. Die Daten werden einer Blockchain hinzugefügt, bleiben jedoch unter der Kontrolle des Fahrzeughalters, bis der Fahrzeughalter beschließt, alle oder einen Teil der Daten zu teilen. Die Bedingungen können in einem Smart Contract aufgeführt werden, der von dem gemeinsamen Transaktionsregister zum Wahrnehmen der Verwaltung der Daten, einschließlich Teilen, Vergüten und Verteilen von Daten, verwendet wird.
1B veranschaulicht ein Diagramm eines Fahrzeugsensordaten-Sammelsystems 150 gemäß beispielhaften Ausführungsformen, welches ein gemeinsames Transaktionsregister nutzt. Unter Bezugnahme auf 1B beinhaltet das System 150 ein Fahrzeug 108, das Sensordaten generiert und/oder empfängt und die Sensordaten an einen Sensordaten-Server 110 weiterleitet, der Profile von Fahrzeughaltern und VDRs 120, welche Zugang zu den Daten begehren, vorhält. Die Blockchain 130 ist als eine Mitgliedsdatenplattform vorgesehen, welche die gesammelten, geteilten und an Dritte übertragenen Daten identifiziert und die Fälle solcher Übertragungen über einzelne Blockchain-Transaktionen 132 protokolliert. In anderen Ausführungsformen werden die Daten in der Blockchain abgelegt, nachdem sie identifiziert wurden. Der Inhalt einer Transaktion kann die an einer Transaktion beteiligten Parteien, Bedingungen, Daten, Zeiten, Datentypen, geleistete Vergütung, bestätigte Berechtigungen, Fahrzeuginformationen, einschließlich der Sensortypen und der Sensordatenkategorien, etc. beinhalten. Das gemeinsame Transaktionsregister protokolliert die Fälle von übertragenen Daten in Form von Transaktionen 132 für anschließende Prüfungen und andere interessierte Parteien, welche die Validität einer Transaktion feststellen und die Existenz eines Datenteilungsereignisses prüfen möchten.
1C veranschaulicht ein System 170 gemäß beispielhaften Ausführungsformen, in dem Fahrzeugsensordaten verarbeitet und an interessierte Dritte verteilt werden. Bezugnehmend auf 1C beinhaltet das System 170 den Sensordaten-Server 110, der Daten von den Sensoren 106 empfängt und verarbeitet. Die Sensordaten 112 können basierend auf ihrem Sensortyp danach kategorisiert werden, ob ein Fahrzeugcomputer die Daten gesammelt hat oder eine Nutzervorrichtung die Daten gesammelt hat, wobei es sich bei allen um geeignete Sensoren handelt. In anderen Ausführungsformen können die Sensordaten 112 nicht-fahrzeugbasierte Sensordaten beinhalten, welche unabhängig von oder in Verbindung mit Daten von den fahrzeugbasierten Sensoren 106 gespeichert werden können. Beispielsweise können ortsfeste Sensoren auf einer Seite einer Straße und/oder bewegliche Sensoren von anderen Fahrzeugen Daten abgeben, welche unabhängig von oder in Verbindung mit den Daten von den Sensoren 106 gespeichert werden können. Die Mehrzahl von unterschiedlichen Sensordatensätzen können verschiedenen der registrierten Kategorien zugewiesen werden, und der eine oder die mehreren Fahrzeugdatenempfänger können eine Mehrzahl von unterschiedlichen Fahrzeugdatenempfängern (VDRs von engl. Vehicle Data Recipients) mit entsprechenden unterschiedlichen registrierten Kategorien beinhalten, die ihnen - beispielsweise ihren jeweiligen Datenempfängerprofilen - zugewiesen sind. Beispielsweise kann ein VDR eine Regierungsbehörde 122 beinhalten, die Straßenzustandsinformationen begehrt, welche durch Videosensordaten oder Beschleunigungssensordaten erfasst werden können, um Bewegung auf der Straße festzustellen, etc. Ein anderer VDR kann ein Hersteller 124 sein, der Sensordaten begehrt, welche einen Fahrzeugbetrieb ausweisen, wie etwa Antriebsmaschine, Räder, Bremsen, Beschleunigung, etc. Der Hersteller-VDR 124 kann bestrebt sein, Sensordaten für einen bestimmten Fahrzeugtyp und über bestimmte Fahrzeugsensoren 106 zu identifizieren, die als Teil eines kollektiven Satzes von Sensordaten 112 gesammelt wurden. Ein anderer VDR kann ein Werbungtreibender 126 sein, der bestrebt ist, ein Nutzerprofil des Fahrzeugs zu identifizieren, wie etwa das Alter des Fahrers, von diesem gehörte Radiosender bzw. Radioprogramme, durch den Fahrer vorgenommene Aktivitäten, die verwendete Navigation und durch das Fahrzeug und dessen Betreiber aufgesuchte Orte. Auch andere VDRs 128 können an den Sensordaten interessiert sein, um festzustellen, ob sie bestimmte Werbeanzeigen auswählen, anderen Rückmeldung geben, den Nutzer des Autos kontrollieren sollen, insbesondere in dem Fall, dass das Auto ein autonomes Fahrzeug ist.
Autonome Fahrzeuge können dann behördlich geregelt werden, wenn Sensordaten aus verschiedenen Gründen vorgeschrieben sind, da der Betrieb des Fahrzeugs durch einen Computer und nicht notwendigerweise eine Person gesteuert wird. Infolgedessen kann das Teilen der durch autonome Fahrzeuge zusammengetragenen Sensordaten von verschiedenen Behörden und Dritten verlangt werden, um Sicherheitsvorkehrungen zu gewährleisten. Das Fahrzeug 108 kann ein durch einen menschlichen Fahrer betriebenes Fahrzeug oder ein durch einen Computer und/oder einen Remote Agent bzw. Fernsteuerer betriebenes autonomes Fahrzeug sein. Die Fahrzeugsensordaten können über eine Mehrzahl der Fahrzeugsensoren 106 gesammelt werden. Die Steuerungsvorrichtung (d.h. bordeigener Computer und/oder Nutzer-Smartphone, etc.) kann den Sensortyp, die Sensorkennung und Fälle von Sensordaten, die für jene Parameter empfangen wurden, identifizieren. Das Sammeln von Sensordaten kann einen oder mehrere Sätze von Sensordaten erzeugen. Beispielsweise können die Sensoren S1, S2, S3, ... Sn der Sensoren 106 Sensordatensätze SD1, SD2, SD3, ... SDn erzeugen. Jene Sensordatensätze können mehrere Iterationen von Sensordaten über einen festgelegten Zeitraum (z.B. Millisekunden, Sekunden, Minuten, Stunden, etc.) oder kurze Episoden extremer Messungen wie etwa ausschließlich Fälle von starken Abweichungen von erwarteten Werten beinhalten, um beispielsweise einen Unfall, ein Schlagloch auf der Straße, einen Bremsvorgang, extreme Verhältnisse oder Fahrmanöver, etc. zu identifizieren. Die VDRs können registriert sein, um bestimmte Fahrzeugsensordatensätze in Abhängigkeit von den Interessen der jeweiligen VDRs zu empfangen.
Halter von autonomen/nicht-autonomen Fahrzeugen (oder Insassen der Fahrzeuge) können ihre Profile in einem gemeinsamen Transaktionsregister oder einem anderen Datenverwaltungssystem registrieren, so dass die während der Sensorerfassungsbemühungen gesammelten Informationen geteilt werden können und dem Profil und/oder Fahrzeug des Halters ein auch in dem gemeinsamen Transaktionsregister ausgewiesener, vorbestimmter Wert über einen Smart Contract gutgeschrieben werden kann. Der Smart Contract kann die Parteien der Vereinbarung, Berechtigungen zum Teilen von Daten, von den VDR(s) begehrte Arten von Daten, eine Vergütung für die Daten und andere Parameter ausweisen.
In einem Beispiel kann ein Dritter, der Zugang zu den Fahrzeugsensordaten begehrt, ein Autohersteller sein. In einem anderen Beispiel könnten die zusammengetragenen Sensordaten Verkehrsaufkommen-/Verkehrsmuster-Informationen beinhalten, wie etwa eine Anzahl von Autos, die eine bestimmte Kreuzung passieren, Fahrzeuggeschwindigkeiten auf bestimmten Fahrbahnen, etc., welche aus einem Fahrzeugbestand zusammengetragen und zu Sensordatensätzen zusammengefasst wurden; derartige Daten werden womöglich von bestimmten Gemeinden gewünscht. Auch können andere Arten von privaten Daten gegen eine beliebige Art von Vorteil/Guthaben ausgetauscht werden. Beispielsweise kann das Fahrzeug für das Teilen von Daten mit einem Hersteller Anspruch auf ein (monetäres oder nicht-monetäres) Guthaben haben, das über den Smart Contract ausgewiesen und in dem gemeinsamen Transaktionsregister aufgezeichnet wird. Das Guthaben kann von dem Hersteller angeboten werden und kann ein Service-Update beinhalten. Beispielsweise kann ein autonomes Fahrzeug einen kostenlosen Ölwechsel erhalten und kann für den Service zu dem Vertragshändler navigieren. Bei der Ankunft des Fahrzeugs wird das Guthaben aus einer Transaktion in dem gemeinsamen Transaktionsregister identifiziert; wenn der Service in Anspruch genommen wird, kann eine andere Transaktion geschrieben werden, um den im Eigentum des Fahrzeugprofils stehenden Wert einzulösen. Auf diese Weise erhält das Fahrzeug das Guthaben und nicht der Halter und/oder Insasse. In anderen Ausführungsformen kann das Guthaben zwischen einem oder mehreren Fahrzeugen, Haltern und/oder Insassen aufgeteilt werden.
2A veranschaulicht eine Blockchain-Architekturkonfiguration 200 gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 2A kann die Blockchain-Architektur 200 bestimmte Blockchain-Elemente, zum Beispiel eine Gruppe von Blockchain-Mitgliedsknoten 202-206 als Teil einer berechtigungspflichtigen Blockchain-Gruppe 210 beinhalten. Die berechtigungspflichtige Blockchain ist nicht allen Parteien zugänglich, sondern nur jenen Mitgliedern mit Zugangsberechtigung zu den Blockchain-Daten. Die Blockchain-Knoten nehmen an einer Reihe von Aktivitäten teil, wie etwa dem Hinzufügen von Blockchain-Einträgen und einem Validierungsprozess (Konsens). Einer oder mehrere der Blockchain-Knoten können Einträge basierend auf einer Endorsement Policy billigen und können einen Ordnungsdienst für alle Blockchain-Knoten bereitstellen. Ein Blockchain-Knoten kann eine Blockchain-Aktion (wie etwa eine Authentifizierung) initiieren und versuchen, in ein in der Blockchain gespeichertes, unveränderliches Transaktionsregister der Blockchain zu schreiben, von dem eine Kopie auch in der zugrundeliegenden physischen Infrastruktur gespeichert sein kann.
Die Blockchain-Transaktionen 220 werden in einem Speicher eines oder mehrerer Computer gespeichert, wenn die Transaktionen empfangen und durch das von den Mitgliedsknoten vorgegebene Konsensmodell genehmigt werden. Genehmigte Transaktionen 226 werden in aktuellen Blöcken der Blockchain gespeichert und über eine Festschreibeprozedur, welche das Durchführen eines Hash der Dateninhalte der Transaktionen in einem aktuellen Block und das Bezugnehmen auf einen vorherigen Hash eines vorherigen Blocks beinhaltet, in der Blockchain festgeschrieben. Smart Contracts 230, welche ein Teil der Blockchain sind oder über die Blockchain zugänglich sind, sind ausgelegt, um die Bedingungen von Transaktionsvereinbarungen und Aktionen, welche in dem ausführbaren Smart-Contract-Anwendungscode 232 beinhaltet sind, zu definieren. Die Fahrzeugsensordaten können auf Fahrzeugdatenteilungsvereinbarungen basiert werden, welche Berechtigungen zum Teilen von Fahrzeugsensordaten, zum Empfang der Daten registrierte Parteien und Arten von zu teilenden Sensordaten, etc., 234, beinhalten. In anderen Ausführungsformen kann eine berechtigungsfreie Blockchain-Konfiguration mit ähnlichen Ergebnissen verwendet werden (d.h. in einer Ausführungsform Bereitstellung eines Wertes für ein Verkehrsmittel).
2B veranschaulicht eine Konfiguration eines gemeinsamen Transaktionsregisters gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 2B beinhaltet das Blockchain-Logikbeispiel 250 eine Blockchain-Anwendungsschnittstelle 252 als eine API, Plugin-Anwendung oder Software, welche sich für eine bestimmte Transaktion mit der Rechenvorrichtung und Ausführungsplattform verbindet. Die Blockchain-Konfiguration 250 kann eine oder mehrere Anwendungen beinhalten, die mit Programmierschnittstellen (APIs, von engl. Application Programming Interfaces) verknüpft sind, um auf gespeicherten Programm-/Anwendungscode (z.B. ausführbaren Smart-Contract-Code, Smart Contracts, etc.), welcher gemäß einer von Teilnehmern gewünschten Konfiguration erzeugt werden kann, zuzugreifen und diesen auszuführen, und die ihren eigenen Zustand aufrechterhalten, ihre eigenen Vermögenswerte steuern und externe Informationen empfangen können. Diese können als ein Eintrag genutzt und durch Anhängen an das verteilte Transaktionsregister auf allen Blockchain-Knoten installiert werden.
Der Smart-Contract-Anwendungscode 254 stellt eine Grundlage für Blockchain-Transaktionen bereit, indem er einen Anwendungscode bildet, der bei Ausführung bewirkt, dass die Bestimmungen und Bedingungen der Transaktion wirksam werden. Bei seiner Ausführung bewirkt der Smart Contract 230, dass bestimmte genehmigte Transaktionen 226 generiert werden, die dann an die Blockchain-Plattform 262 weitergeleitet werden. Die Plattform beinhaltet einen Sicherheits-/Autorisierungsabschnitt 268, Rechenvorrichtungen, welche die Transaktionsverwaltung 266 ausführen, und einen Speicherabschnitt 264 als einen Speicher, der Transaktionen und Smart Contracts in der Blockchain speichert.
Die Blockchain-Plattform kann verschiedene Schichten von Blockchain-Daten, Dienste (z.B. kryptographische Vertrauensdienste, virtuelle Ausführungsumgebung, etc.) und zugrundeliegende physische Computerinfrastruktur beinhalten, die verwendbar ist, um neue Einträge zu empfangen und zu speichern und Prüfern, die auf Dateneinträge zugreifen möchten, Zugang zu ermöglichen. Die Blockchain kann eine Schnittstelle verfügbar machen, die Zugang zu der virtuellen Ausführungsumgebung ermöglicht, welche zum Verarbeiten des Programmcodes und Inanspruchnehmen der physischen Infrastruktur notwendig ist. Kryptographische Vertrauensdienste können zum Überprüfen von Einträgen wie etwa Vermögenswertaustausch-Einträgen und zum Geheimhalten von privaten Informationen verwendet werden.
Die Blockchain-Architektur-Konfiguration von 2A und 2B kann - über eine oder mehrere verfügbar gemachte Schnittstellen - Programm-/Anwendungscode und - durch die Blockchain-Plattform - bereitgestellte Dienste verarbeiten und ausführen. Als ein nicht einschränkendes Beispiel können Smart Contracts geschaffen werden, um Erinnerungen bzw. Mahnungen, Aktualisierungen, Zahlungen und/oder andere Benachrichtigungen, die den Änderungen, Aktualisierungen unterliegen, etc. auszuführen. Die Smart Contracts selbst können verwendet werden, um Vorschriften, die mit Autorisierungs- und Zugangserfordernissen und der Verwendung des Transaktionsregisters zusammenhängen, auszuweisen. Beispielsweise können die Informationen einen Antrag auf einen neuen Eintrag beinhalten, der von einer oder mehreren in der Blockchain-Schicht beinhalteten Verarbeitungsentitäten (z.B. Prozessoren, virtuellen Maschinen, etc.) verarbeitet werden kann. Das Ergebnis kann eine Entscheidung beinhalten, den Antrag basierend auf den in dem Smart Contract beinhalteten Kriterien und/oder einem Konsens der Peers abzulehnen oder zu genehmigen. Die physische Infrastruktur kann genutzt werden, um beliebige der hierin beschriebenen Daten oder Informationen abzurufen.
In ausführbarem Smart-Contract-Code kann über eine Anwendung und Programmiersprache ein Smart Contract geschaffen und in einen Block in der Blockchain eingeschrieben werden. Der Smart Contract kann ausführbaren Code beinhalten, der bei einer Blockchain (z.B. einem verteilten Netzwerk von Blockchain-Peers) registriert, gespeichert und/oder repliziert wird. Ein Eintrag ist eine Ausführung des Smart-Contract-Codes, die als Reaktion auf Bedingungen im Zusammenhang mit der Erfüllung des Smart Contract erfolgen kann. Die Ausführung des Smart Contract kann (eine) vertrauenswürdige Änderung(en) eines Zustands eines digitalen Blockchain-Transaktionsregisters auslösen. Die durch die Ausführung des Smart Contract bewirkte(n) Änderung(en) des Blockchain-Transaktionsregisters kann/können über das gesamte verteilte Netzwerk von Blockchain-Peers hinweg durch ein oder mehrere Konsensprotokolle automatisch repliziert werden.
Der Smart Contract kann Daten im Format von Schlüssel-Wert-Paaren in die Blockchain einschreiben. Ferner kann der Smart-Contract-Code die in einer Blockchain gespeicherten Werte lesen und sie in Anwendungsoperationen verwenden. Der Smart-Contract-Code kann die Ausgabe verschiedener Logikoperationen in die Blockchain einschreiben. Der Code kann verwendet werden, um eine temporäre Datenstruktur in einer virtuellen Maschine oder anderen Rechenplattform zu schaffen. In die Blockchain eingeschriebene Daten können öffentlich sein und/oder verschlüsselt und als privat geführt werden. Die durch den Smart Contract verwendeten/generierten temporären Daten werden von der belieferten Ausführungsumgebung in einem Speicher gehalten, dann gelöscht, sobald die für die Blockchain benötigten Daten identifiziert wurden.
Ausführbarer Smart-Contract-Code kann die Codeauslegung eines Smart Contract mit zusätzlichen Merkmalen beinhalten. Wie hierin beschrieben, kann der ausführbare Smart-Contract-Code ein Programmcode sein, der in einem Rechennetzwerk eingesetzt wird, wo er während eines Konsensprozesses ausgeführt und von Kettenvalidierern validiert wird. Der ausführbare Smart-Contract-Code empfängt ein Hash und gewinnt aus der Blockchain ein Hash, das mit der durch Verwenden eines zuvor gespeicherten Merkmalextrahierers geschaffenen Datenvorlage zusammenhängt. Falls die Hashes der Hash-Kennung und das aus den gespeicherten Kennungsvorlagendaten geschaffene Hash übereinstimmen, sendet der ausführbare Smart-Contract-Code einen Autorisierungsschlüssel an den angeforderten Dienst. Der ausführbare Smart-Contract-Code kann Daten, die mit den kryptographischen Details zusammenhängen, in die Blockchain einschreiben.
3 veranschaulicht ein System-Datentransfer-Diagramm einer Konfiguration eines Fahrzeugsensordatensammel- und -verifizierungssystems gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 3 sieht das System 300 ein Fahrzeug 310 vor, welches einem Sensor-Server 320 Sensordaten anbietet. Die Daten können über eine drahtgebundene und/oder drahtlose Verbindung wie etwa eine Anbindung an ein Drahtlosnetzwerk gesendet werden, wie etwa eine mobile Vorrichtung, ein in dem Fahrzeug installiertes zellulares Rechenmodell, ein WIFI- oder Bluetooth-Modul, welches einen Transfer in Gang setzt, wenn es verbunden und/oder nahe einem Netzwerk ist, etc. Die Sensordaten werden an den Server 320 gesendet, 312, und das Fahrzeugprofil wird identifiziert, 314, Smart-Contract-Informationen können von einer Blockchain 330 bereitgestellt werden, 316, um beispielsweise die Fahrzeugsensordaten-Kategorisierung, VDR-Identifizierung und das Teilen von Daten einzuleiten. Die Smart-Contract-Bedingungen 318 können identifiziert und ausgeführt werden, um Sensordaten bestimmten Sensorkategorien zuzuweisen, 322. Die Kategorien werden mit VDR-Profilen abgeglichen, um die interessierenden Sensordaten zu identifizieren, 324. Die relevanten und angeforderten Fahrzeugsensordaten werden dann an die entsprechenden Profile weitergeleitet, 326. Die Bedingungen des Smart Contract und zugehörige Informationen werden in einer Blockchain-Transaktion aktualisiert, 328, um die Aktionen und Ergebnisse des Datenteilungsereignisses auszuweisen.
4A veranschaulicht ein Flussdiagramm eines Fahrzeugsensordaten-Sammelprozesses gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 4A sieht der Prozess 400 einen oder mehrere vor aus der Gruppe bestehend aus Empfangen von aus einem Fahrzeug gesendeten Fahrzeugdaten, wobei die Fahrzeugdaten Sensordaten von einem oder mehreren Sensoren und/oder einer oder mehreren in dem Fahrzeug arbeitenden Rechenvorrichtungen beinhalten, 412, Identifizieren eines mit dem Fahrzeug zusammenhängenden Fahrzeugprofils, 414, Bestimmen, ob Fahrzeugdaten-Teilungsberechtigungen in dem Fahrzeugprofil gespeichert sind, 416, als Antwort auf die Identifikation von Fahrzeugdaten-Teilungsberechtigungen, welche angeben, dass die Fahrzeugdaten geteilt werden dürfen, Zuweisen der Fahrzeugdaten zu einer oder mehreren registrierten Kategorien basierend auf einem beim Sensordatensammeln verwendeten Typ von Sensor und/oder erfasstem Inhalt, der mit den Sensordaten verbunden ist, 418, Identifizieren eines oder mehrerer Fahrzeugdatenempfänger, die zum Empfangen der Fahrzeugdaten registriert sind, basierend auf der einen oder den mehreren identifizierten registrierten Kategorien, die den Fahrzeugdaten zugewiesen sind, 422, Weiterleiten der Fahrzeugdaten an den einen oder die mehreren identifizierten Fahrzeugdatenempfänger, 424, und Zuweisen eines Wertes an das Fahrzeugprofil, 426.
Eine Konfiguration zum Erlauben einer Sensordatenverwaltung kann eine oder mehrere Rechenvorrichtungen und ein Fahrzeug mit einem oder mehreren Sensoren beinhalten. Ein Server kann auch ausgelegt sein, um eine oder mehrere aus der folgenden Gruppe in unterschiedlicher Reihenfolge durchzuführen: Empfangen von aus dem Fahrzeug gesendeten Fahrzeugdaten, wobei die Fahrzeugdaten Sensordaten von dem einen oder den mehreren Sensoren und/oder einer oder mehreren in dem Fahrzeug arbeitenden Rechenvorrichtungen umfassen, Identifizieren eines mit dem Fahrzeug zusammenhängenden Fahrzeugprofils, Bestimmen, ob Fahrzeugdaten-Teilungsberechtigungen in dem Fahrzeugprofil gespeichert sind, als Antwort auf die Identifikation von Fahrzeugdaten-Teilungsberechtigungen, welche angeben, dass die Fahrzeugdaten geteilt werden dürfen, Zuweisen der Fahrzeugdaten zu einer oder mehreren registrierten Kategorien basierend auf einem beim Sensordatensammeln verwendeten Typ von Sensor und/oder erfasstem Inhalt, der mit den Sensordaten verbunden ist, Identifizieren eines oder mehrerer Fahrzeugdatenempfänger, die zum Empfangen der Fahrzeugdaten registriert sind, basierend auf der einen oder den mehreren identifizierten registrierten Kategorien, die den Fahrzeugdaten zugewiesen sind, Weiterleiten der Fahrzeugdaten an den einen oder die mehreren identifizierten Fahrzeugdatenempfänger und Zuweisen eines Wertes an das Fahrzeugprofil.
In einer Ausführungsform werden der eine oder die mehreren Fahrzeugdatenempfänger, die zum Empfangen der Fahrzeugdaten registriert sind, basierend auf der einen oder den mehreren registrierten Kategorien identifiziert, die den in entsprechenden Datenempfängerprofilen des einen oder der mehreren Datenempfänger identifizierten Fahrzeugdaten zugewiesen sind. In anderen Ausführungsformen können die Fahrzeugdatenempfänger die Fahrzeugdaten auf einer einmaligen oder einer intermittierenden Basis unabhängig von einer Kategorie und/oder einem Profil empfangen. In einer Ausführungsform umfassen die Fahrzeugdaten eine Mehrzahl von unterschiedlichen Sensordatensätzen, die von einer Mehrzahl von unterschiedlichen Sensortypen und einer oder mehreren Rechenvorrichtungen gesammelt werden. Die Mehrzahl von unterschiedlichen Sensordatensätzen sind unterschiedlichen der registrierten Kategorien zugewiesen, und der eine oder die mehreren Fahrzeugdatenempfänger beinhalten eine Mehrzahl von unterschiedlichen Fahrzeugdatenempfängern mit entsprechenden unterschiedlichen der registrierten Kategorien, die ihren jeweiligen Datenempfängerprofilen zugewiesen sind. Der erfasste Inhalt basiert auf einer oder mehreren aus einer in dem Verkehrsmittel durchgeführten Aktion, einer außerhalb des Verkehrsmittels durchgeführten Aktion und einer durch das Verkehrsmittel durchgeführten Aktion wie etwa eine Radiosenderwahl, Audioaufnahmen, Verwendung von Mobilgeräten innerhalb des Fahrzeugs, innerhalb des Fahrzeugs geführte Telefonate, eine innerhalb des Fahrzeugs vorgenommene Nutzung mobiler Daten, Browser-Verlauf mindestens einer der Rechenvorrichtungen, über die mindestens eine der Rechenvorrichtungen innerhalb des Fahrzeugs getätigte Einkäufe, innerhalb des Fahrzeugs erstellte Audioaufnahmen, etc. Ein Typ von Sensor, der während des Datensammelns verwendet wird, umfasst einen oder mehrere aus Bewegungssensoren, Sonarsensoren, Lidar-Sensoren, Beschleunigungssensoren, Berührungssensoren, Näherungssensoren, Temperatursensoren, Geschwindigkeitssensoren, Schallsensoren, Infrarotsensoren, Kollisionssensoren, Füllstandsensoren, Reifendrucksensoren, Standortbestimmungssensoren, Ultraschallsensoren, Kamerasensoren, Aktivitätssensoren, chemischen Sensoren, Fluidsensoren, Drucksensoren, optischen Sensoren und biometrischen Sensoren.
In einer Ausführungsform kann ein System ein in einem Speicher gespeichertes verteiltes Transaktionsregister und einen in dem verteilten Transaktionsregister gespeicherten Smart Contract beinhalten, der als Antwort darauf aufgerufen wird, dass die Fahrzeugdaten als zu Fahrzeugdaten-Teilungsberechtigungen gehörend identifiziert werden. Der Smart Contract beinhaltet mindestens einen aus der Gruppe bestehend aus einem Teil der Fahrzeugprofilinformationen, den Datenempfängerprofilen, einem Typ von Fahrzeugdaten, die zu den Datenempfängerprofilen gehören, und dem Wert, der dem Fahrzeugprofil basierend auf den geteilten Fahrzeugdaten zugewiesen wird. Der Aufruf des Smart Contract resultiert in der Durchführung einer Transaktion, die mindestens einen aus der Gruppe bestehend aus Teilen der Fahrzeugdaten mit dem einem oder den mehreren Fahrzeugdatenempfängern, Zuweisen des Wertes zu dem Fahrzeugprofil, Zuweisen eines Datums zu der Transaktion und Protokollieren der Transaktion in dem verteilten Transaktionsregister umfasst.
4B veranschaulicht ein weiteres Flussdiagramm eines Fahrzeugsensordaten-Sammelprozesses gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 4B beinhaltet der Prozess 450 einen oder mehrere aus der Gruppe bestehend aus Übertragen von Sensordaten von mindestens einem Sensor eines Verkehrsmittels zu einem Server, 452, Speichern einer Privatsphäreeinstellung für die gesammelten Sensordaten, wobei die Privatsphäreeinstellung mit einer Anonymität eines dem Verkehrsmittel zugeordneten Nutzers verbunden ist, 454, Durchführen einer Aktion über den Server basierend auf den Sensordaten, 456, und Bereitstellen eines Wertes für das Verkehrsmittel basierend auf einem Ergebnis der Aktion, 458. Dem Verkehrsmittelprofil kann der Wert als Reaktion auf das Teilen der Fahrzeugsensordaten gutgeschrieben werden. In anderen Ausführungsformen kann der Wert (vor dem Teilen der Daten, in Echtzeit oder nahezu in Echtzeit während des Akkumulierens der Daten und/oder nach dem Teilen der Daten) einem Ablageort auf dem Verkehrsmittel und/oder außerhalb des Verkehrsmittels, der jedoch für das Verkehrsmittel zugänglich ist, gutgeschrieben werden. In noch anderen Ausführungsformen kann der Wert auf unterschiedliche Ablageorte, einschließlich Ablageorten auf anderen Verkehrsmitteln, aufgeteilt werden (oder kann vollständig auf ein anderes Verkehrsmittel übertragen werden). Basierend auf dem Anonymitätsgrad des Nutzers, der den Daten zugeordnet ist, welche der Nutzer erzeugt und/oder konsumiert, kann der Wert angepasst (d.h. erhöht oder verringert) werden. Je anonymer die Daten sind, desto niedriger ist der Wert, der für das Verkehrsmittel 108 bereitgestellt wird. Je weniger anonym die Daten sind, desto höher ist der Wert, der für das Verkehrsmittel 108 bereitgestellt wird. In einer Ausführungsform wird eine Mehrzahl von unterschiedlichen Daten von einer Mehrzahl von unterschiedlichen Sensoren gesammelt, wobei die einzelnen Daten anonymer und/oder weniger anonym sein können und sich dynamisch verändern können. Beispielsweise können während einer Fahrt Standortdaten des Verkehrsmittels und/oder einer durch den Nutzer verwendeten Vorrichtung gesammelt und dem Server zur Verfügung gestellt werden. Der Server kann die Standortdaten zusätzlich zu anderen Sensordaten einer Entität zur Verfügung stellen, was zur Bereitstellung eines höheren Wertes für das Verkehrsmittel führt. Während der gleichen Fahrt kann es dem Server in einem anderen Fall (basierend auf der Privatsphäreeinstellung) nicht gestattet sein, die Standortdaten zur Verfügung zu stellen, was zur Bereitstellung eines niedrigeren Wertes für das Verkehrsmittel führt. Daher kann sich der Wert, der für das Verkehrsmittel für einen einzigen Typ von Daten, wie etwa Standort-basierten Daten, bereitgestellt wird, basierend auf der Privatsphäreeinstellung des Nutzers während einer einzigen Fahrt dynamisch verändern. In einer anderen Ausführungsform kann der Betrag des für das Verkehrsmittel bereitgestellten Wertes basierend auf dem Teil der Fahrt, der die Standortdaten beinhaltete, und dem Teil der Fahrt, der die Standortdaten nicht beinhaltete, uneinheitlich sein. Diese uneinheitlichen Daten können dem Insassen, Fahrer, Betreiber und/oder Inhaber des Verkehrsmittels präsentiert werden.
Auch können die gleichen Informationen einen unterschiedlichen Wert besitzen - bei vollem Benzin-/Gastank oder vollständig aufgeladenen Batterien bzw. Akkumulatoren findet für Standortinformationen ein niedriger Wert Anwendung, doch bei leerem Benzin-/Gastank oder leeren Batterien bzw. Akkumulatoren sind einem VDR/Werbungtreibenden, bei dem es sich um eine Tankstelle oder eine Ladestation handelt, Standortinformationen wesentlich mehr wert.
4C veranschaulicht noch ein anderes Flussdiagramm eines Fahrzeugsensordaten-Sammelprozesses gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 4C beinhaltet der Prozess 470 einen oder mehrere aus der Gruppe bestehend aus Übertragen von Sensordaten von mindestens einem Sensor eines Verkehrsmittels zu einem Server, 472, Vergleichen der Sensordaten mit einem oder mehreren vorbestimmten Fahrzeugbetriebsschwellwerten, 474. Beispiele für Schwellwerte können Geschwindigkeitsschwellwerte, Beschleunigungssensorpositionsschwellwerte, Temperaturschwellwerte, Fahrzeugverkehrsschwellwerte, Kollisions- und/oder Aufprallschwellwerte, Witterungsbedingungsschwellwerte, einen Anzahl-von-erfassten-Insassen-Schwellwert, etc. beinhalten. Wenn einer oder mehrere dieser Schwellwerte überschritten werden, kann an dem Fahrzeug eine Veränderung vorgenommen werden, insbesondere dann, wenn das Fahrzeug ein autonomes Fahrzeug ist, das ohne einen Fahrer betrieben wird. Das Verfahren kann auch das Durchführen einer Aktion über den Server basierend auf dem Vergleich der Sensordaten mit dem einen oder den mehreren vorbestimmten Fahrzeugbetriebsschwellwerten, 476, und das Übertragen der Aktion an das Verkehrsmittel zum Verändern eines Betriebsstatus des Verkehrsmittels, 478, wie etwa Verlangsamen des Verkehrsmittels über ein an das Verkehrsmittel gesendetes Signal, Anhalten des Verkehrsmittels, Verändern eines Kurses des Verkehrsmittels, Abstellen des Verkehrsmittels am Straßenrand, etc., beinhalten.
4D veranschaulicht noch ein anderes Flussdiagramm eines Fahrzeugsensordaten-Sammel- und -Verifizierungssystems gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 4D beinhaltet der Prozess 480 einen oder mehrere aus Speichern einer Privatsphäreeinstellung für Daten, die mindestens einem an einem Verkehrsmittel angeordneten Sensor zugeordnet sind, 482. Die Privatsphäreeinstellung kann eine Kennzeichnung zum Erlauben des Teilens der Sensordaten, Nichterlauben des Teilens, des Teilens nur von Teilen der Sensordaten, wie etwa Daten von bestimmten Sensoren im Zusammenhang mit dem Fahrzeugverhalten (z.B. Leistung, Verhältnisse, etc.), oder Daten im Zusammenhang mit Aktionen eines Nutzers, wie etwa Fahrstil, Steuerungsselektionen (z.B. Radiosender, Internetnutzung, etc.), beinhalten. Das Verfahren kann auch das Sammeln von Daten über den mindestens einen Sensor, 484, und das Übertragen der gesammelten Daten von dem Verkehrsmittel an den Server sowie Zuordnen der Privatsphäreeinstellung zu einer Anonymität eines dem Verkehrsmittel und den Daten zugeordneten Nutzers, 486, beinhalten. Die Privatsphäreeinstellung kann zwar ein Teilen festlegen, doch die Nutzeraktionen und/oder das Nutzerprofil als privat oder anonym führen. Das Verfahren kann auch ein Verarbeiten der Daten über den Server zum Vollziehen einer Aktion und ein Bereitstellen eines Wertes für das Verkehrsmittel basierend auf einem Ergebnis der Aktion beinhalten. Die Daten können als ein bestimmter Sensortyp identifiziert werden, der als Sensordatenkategorie gelten kann, oder als Datensatz, der in einem VDR-Profil identifizierbar ist. Diese identifizierbaren Sensordatensätze können eine gewisse Anzahl von Sensorablesungen über einen bestimmten Zeitraum erfordern, bevor sie eine Datensatzanforderung erfüllen, ferner kann die Kategorie, die den verwendeten Sensor oder gesammelte Sensoraktionen ausweist, auch in den VDR-Selektionen von (einem) VDR-Profil(en) identifizierbar sein.
4E veranschaulicht noch ein anderes Flussdiagramm eines Fahrzeugsensordaten-Sammel- und -Verifizierungssystems gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 4D beinhaltet der Prozess 495 einen oder mehrere aus der Gruppe bestehend aus Zuweisen von Sensordaten von einem Verkehrsmittel zu einer oder mehreren Kategorien basierend auf Sensordaten-Teilungsberechtigungen, die in einem Profil gespeichert sind, das einem Verkehrsmittel 496 zugeordnet ist. Die Sensordaten werden dann basierend auf der einen oder den mehreren Kategorien an einen oder mehrere Empfänger gesendet, 497. Schließlich wird durch den einen oder die mehreren Empfänger basierend auf den Sensordaten ein Wert für das Verkehrsmittel mittels eines Smart Contract bereitgestellt, der sich auf die an den einen oder die mehreren Empfänger gesendeten Sensordaten, den für das Verkehrsmittel bereitgestellten Wert, ein den gesendeten Sensordaten zugeordnetes Datum und ein dem bereitgestellten Wert zugeordnetes Datum bezieht, 498.
5A veranschaulicht eine beispielhafte Blockchain-Fahrzeug-Konfiguration 500 zum Verwalten von Blockchain-Transaktionen, die mit einem Fahrzeug verbunden sind, gemäß beispielhaften Ausführungsformen. Bezugnehmend auf 5A kann ein bestimmtes Verkehrsmittel/Fahrzeug 108, während es Transaktionen tätigt, wie etwa Dienstleistungstransaktionen (z.B. Fahrzeugservice, Händlertransaktionen, Lieferung/Abholung, Transportdienstleistungen, etc.), gemäß (einer) Dienstleistungstransaktion(en) Werte 510 empfangen und oder Werte 512 abgeben/übertragen. Das Transaktionsmodul 520 kann Informationen, wie etwa Parteien, Guthaben, Dienstbeschreibungen, Datum, Uhrzeit, Standort, Ergebnisse, Benachrichtigungen, unerwartete Ereignisse, etc. aufzeichnen. Diese Transaktionen in dem Transaktionsmodul 520 können in eine Blockchain 530 repliziert werden, die von einem Remote-Server und/oder Remote-Blockchain-Peers, von denen das Fahrzeug selbst ein Blockchain-Element und/oder Blockchain-Peer sein kann, verwaltet wird. In anderen Ausführungsformen befindet sich die Blockchain 530 in dem Fahrzeug 108.
5B veranschaulicht eine beispielhafte Blockchain-Fahrzeug-Konfiguration 540 zum Verwalten von Blockchain-Transaktionen zwischen einem Service-Center und einem Fahrzeug gemäß beispielhaften Ausführungsformen. In diesem Beispiel kann das Fahrzeug 108 selbst einen Service-Center 542 (z.B. Autohändler, örtliche Service-Station, Auslieferabholzentrum, etc.) aufgesucht haben, da das Fahrzeug einen Service benötigt und/oder an einem bestimmten Ort halten muss. Das Service-Center 542 kann das Fahrzeug für einen Servicetermin um eine bestimmte Uhrzeit, mit einer bestimmten Maßnahme, wie etwa Ölwechsel, Batterieaufladung oder -wechsel, Reifentausch oder -wechsel und einem beliebigen anderen verkehrsmittelbezogenen Dienst, registrieren. Die geleisteten Dienste 544 können basierend auf einem Smart Contract durchgeführt werden, der von der Blockchain 530 heruntergeladen wird oder auf den über diese zugegriffen wird und für den eine Berechtigung zum Durchführen solcher Dienste für eine bestimmte Gegenleistung identifiziert wird. Die Dienste werden in dem Transaktionsprotokoll des Transaktionsmoduls 520 protokolliert, die Guthaben 512 werden an das Service-Center 542 übertragen und die Blockchain kann Transaktionen protokollieren, so dass alle Informationen bezüglich des kürzlich erfolgten Dienstes repräsentiert sind. In anderen Ausführungsformen befindet sich die Blockchain 530 in dem Fahrzeug 108 und/oder dem Service-Center 542.
5C veranschaulicht eine beispielhafte Blockchain-Fahrzeug-Konfiguration zum Verwalten von zwischen verschiedenen Fahrzeugen durchgeführten Blockchain-Transaktionen gemäß beispielhaften Ausführungsformen. Das Fahrzeug 108 kann mit einem anderen Fahrzeug 508 in Kontakt treten, um verschiedene Aktionen durchzuführen, wie etwa Teilen, Übertragen, Erlangen von Serviceterminen, etc., wenn das Fahrzeug einen Status erreicht hat, in dem die Dienste mit einem anderen Fahrzeug geteilt werden müssen. Beispielsweise kann das Fahrzeug 508 für einen Batteriewechsel fällig sein und/oder kann ein Problem mit einem Reifen haben und sich auf dem Weg zum Abholen eines auszuliefernden Pakets befinden. Das Fahrzeug 508 kann ein anderes Fahrzeug 108 benachrichtigen, das sich in seinem Netzwerk befindet und für seinen Blockchain-Mitgliedsdienst arbeitet. Das Fahrzeug 108 kann dann über eine Drahtloskommunikationsanforderung zum Durchführen der Abholung des Pakets die Informationen von dem Fahrzeug 508 und/oder von einem Server (nicht gezeigt) empfangen. Die Transaktionen werden in den Transaktionsmodulen 552 und 520 beider Fahrzeuge protokolliert. Die Guthaben werden von dem Fahrzeug 508 auf das Fahrzeug 108 übertragen, und der Datensatz des übertragenen Dienstes wird unter der Annahme, dass die Blockchains voneinander verschieden sind, in der Blockchain 530/540 protokolliert oder wird in der von allen Mitgliedern verwendeten gleichen Blockchain protokolliert.
In einer Ausführungsform ist das Verkehrsmittel konfiguriert, um ohne Überwachung und/oder Genehmigung eines Nutzers oder Administrators zu bezahlen. Auch möglich ist eine Zahlung an das Verkehrsmittel sowie an (einen) Nutzer in dem Verkehrsmittel für das Teilen von Informationen von einer oder mehreren Vorrichtungen (Beispiel: Mobiltelefon, Smart-Watch, Aktivitäts-Tracker, etc.), die in einem bzw. nahe dem Verkehrsmittel betrieben werden. Diese „Überlagerung“ von Informationen kann an den Server gesendet und auf eine stetige und/oder dynamische Art und Weise monetarisiert werden.
6 veranschaulicht einen Blockchain-Block 600 gemäß beispielhaften Ausführungsformen, der einem verteilten Transaktionsregister hinzugefügt werden kann, sowie Inhalte einer Block-Struktur 660. Bezugnehmend auf 6 können Clients (nicht gezeigt) Einträge bei Blockchain-Knoten einreichen, um eine Aktivität auf der Blockchain durchzuführen. Als ein Beispiel können Clients Anwendungen sein, die im Auftrag eines Antragstellers, wie etwa einer Vorrichtung, Person oder Entität, handeln, um Einträge für die Blockchain vorzuschlagen. Die Mehrzahl von Blockchain-Peers (z.B. Blockchain-Knoten) können einen Zustand des Blockchain-Netzwerks und eine Kopie des verteilten Transaktionsregisters vorhalten. Unterschiedliche Arten von Blockchain-Knoten/-Peers können in dem Blockchain-Netzwerk vorhanden sein, einschließlich Endorsing Peers, welche von Clients vorgeschlagene Einträge simulieren und billigen, und Committing Peers, welche Endorsements verifizieren, Einträge validieren und Einträge in das verteilte Transaktionsregister festschreiben. In diesem Beispiel können die Blockchain-Knoten die Rolle eines Endorser-Knotens, Committer-Knotens oder beide erfüllen.
Das vorliegende System beinhaltet eine Blockchain, welche unveränderliche, sequenzierte Datensätze in Blöcken speichert, und eine Zustandsdatenbank (aktueller World State), die einen aktuellen Zustand der Blockchain vorhält. Es kann ein verteiltes Transaktionsregister je Kanal geben, und jeder Peer bewahrt seine eigene Kopie des verteilten Transaktionsregisters für jeden Kanal, von dem er ein Mitglied ist. Die vorliegende Blockchain ist ein Eintragsprotokoll, das als Hash-verknüpfte Blöcke strukturiert ist, wobei jeder Block eine Abfolge von N Einträgen enthält. Blöcke können verschiedene Komponenten beinhalten, wie etwa die in 6 gezeigten. Das Verknüpfen der Blöcke kann durch Hinzufügen eines Hash des Kopfs eines vorherigen Blocks innerhalb eines Blockkopfs eines aktuellen Blocks erzeugt werden. Auf diese Weise werden alle Einträge in der Blockchain sequenziert und kryptographisch miteinander verknüpft, und damit wird eine Manipulation von Blockchain-Daten ohne Lösen der Hash-Verknüpfungen verhindert. Ferner stellt aufgrund der Verknüpfungen der neueste Block in der Blockchain jeden Eintrag dar, der ihm vorausgeht. Die vorliegende Blockchain kann in einem Peer-Dateisystem (lokaler oder angeschlossener Speicher) gespeichert werden, das die Arbeitsweise einer Nur-Hinzufüge-Blockchain unterstützt.
Der aktuelle Zustand der Blockchain und des verteilten Transaktionsregisters kann in der Zustandsdatenbank gespeichert werden. Hier stellen die aktuellen Zustandsdaten die neuesten Werte für alle Schlüssel dar, die jemals in das Ketteneintragsprotokoll der Blockchain aufgenommen wurden. Aufrufe von ausführbarem Smart-Contract-Code führen Einträge gegen den aktuellen Zustand in der Zustandsdatenbank aus. Um diese Interaktionen von ausführbarem Smart-Contract-Code extrem effizient werden zu lassen, sind die neuesten Werte aller Schlüssel in der Zustandsdatenbank gespeichert. Die Zustandsdatenbank kann eine indizierte Sicht in das Eintragsprotokoll der Blockchain beinhalten und kann daher jederzeit aus der Kette regeneriert werden. Die Zustandsdatenbank kann bei einem Peer-Start automatisch wiedererlangt (oder erforderlichenfalls generiert) werden, bevor Einträge angenommen werden.
Endorsing Nodes bzw. Knoten empfangen Einträge von Clients und billigen den Eintrag basierend auf simulierten Ergebnissen. Endorsing Nodes enthalten Smart Contracts, welche die Eintragsvorschläge simulieren. Wenn ein Endorsing Node einen Eintrag billigt, erzeugt der Endorsing Node ein Eintrags-Endorsement, das eine signierte Antwort von dem Endorsing Node an die Client-Anwendung ist, welche das Endorsement des simulierten Eintrags angibt. Das Verfahren des Billigens eines Eintrags hängt von einer Endorsement Policy ab, die in ausführbarem Smart-Contract-Code spezifiziert sein kann. Ein Beispiel für eine Endorsement-Policy ist: „die Mehrheit der Endorsing Peers muss den Eintrag billigen“. Unterschiedliche Kanäle können unterschiedliche Endorsement Policies besitzen. Gebilligte Einträge werden durch die Client-Anwendung an einen Ordnungsdienst weitergeleitet.
Der Ordnungsdienst nimmt gebilligte Einträge an, ordnet sie in einen Block und stellt die Blöcke den Committing Peers zu. Beispielsweise kann der Ordnungsdienst bei Erreichen eines Schwellwertes von Einträgen, Ablaufen eines Zeitgebers oder einer anderen Bedingung einen neuen Block beginnen. In diesem Beispiel ist ein Blockchain-Knoten ein Committing Peer, der einen neuen Datenblock 660 zum Speichern in der Blockchain empfangen hat. Der Ordnungsdienst kann aus einer Gruppe von Orderers bestehen. Der Ordnungsdienst verarbeitet keine Einträge und Smart Contracts und führt nicht das gemeinsame Transaktionsregister. Vielmehr kann der Ordnungsdienst die gebilligten Einträge annehmen und gibt die Reihenfolge an, in der diese Einträge in dem verteilten Transaktionsregister festgeschrieben werden. Die Architektur des Blockchain-Netzwerks kann derart gestaltet sein, dass die konkrete Implementierung des „Ordnens“ (z.B. Solo, Kafka, BFT, etc.) zu einer Plug-in-fähigen Komponente wird.
Einträge werden in einer konsistenten Reihenfolge in das verteilte Transaktionsregister eingeschrieben. Die Reihenfolge von Einträgen wird so festgelegt, dass sichergestellt wird, dass die Aktualisierungen der Zustandsdatenbank gelten, wenn sie in das Netzwerk festgeschrieben werden. Im Gegensatz zu einem Kryptowährungs-Blockchain-System (z.B. Bitcoin, etc.), in dem das Ordnen durch Lösen eines kryptographischen Puzzles bzw. Mining geschieht, können in diesem Beispiel die Parteien des verteilten Transaktionsregisters den Ordnungsmechanismus auswählen, der am besten zu jenem Netzwerk passt.
Bezugnehmend auf 6 kann ein Block 660 (auch als ein Datenblock bezeichnet), der in der Blockchain und/oder dem verteilten Transaktionsregister gespeichert ist, mehrere Datensegmente beinhalten wie etwa einen Blockkopf 662, transaktionsspezifische Daten 672 und Block-Metadaten 680. Es sollte verstanden werden, dass die verschiedenen dargestellten Blöcke und deren Inhalt, wie etwa Block 660 und dessen Inhalt, lediglich dem Zweck eines Beispiels dienen und nicht dazu gedacht sind, den Umfang der beispielhaften Ausführungsformen zu beschränken. In einigen Fällen können sowohl der Blockkopf 662 als auch die Block-Metadaten 680 kleiner sein als die transaktionsspezifischen Daten 672, welche Eintragsdaten speichern, jedoch ist dies kein Erfordernis. Der Block 660 kann Transaktionsinformationen von N Einträgen (z.B. 100, 500, 1000, 2000, 3000, etc.) innerhalb der Blockdaten 670 speichern. Der Block 660 kann auch einen Verweis auf einen vorherigen Block (z.B. in der Blockchain) innerhalb des Blockkopfs 662 beinhalten. Insbesondere kann der Blockkopf 662 einen Hash des Kopfs eines vorherigen Blocks beinhalten. Der Blockkopf 662 kann auch eine einzigartige Blocknummer, einen Hash der Blockdaten 670 des aktuellen Blocks 660 und dergleichen beinhalten. Die Blocknummer des Blocks 660 kann einzigartig sein und in einer inkrementellen/sequentiellen Reihenfolge von null ausgehend zugewiesen werden. Der erste Block in der Blockchain kann als ein Genesis-Block bezeichnet werden, welcher Informationen über die Blockchain, deren Mitglieder, die darin gespeicherten Daten, etc. beinhaltet.
Die Blockdaten 670 können Eintragsinformationen jedes Eintrags, der innerhalb des Blocks aufgezeichnet wird, speichern. Beispielsweise können die Eintragsdaten einen oder mehrere aus der Gruppe bestehend aus einem Typ des Eintrags, einer Version, einem Zeitstempel, einer Kanal-ID des verteilten Transaktionsregisters, einer Eintrags-ID, einem Zeitraum, einer Nutzdatensichtbarkeit, einem Pfad eines ausführbaren Smart-Contract-Codes (tx bereitstellen), einem Namen eines ausführbaren Smart-Contract-Codes, einer Version eines ausführbaren Smart-Contract-Codes, einer Eingabe (ausführbarer Smart-Contract Code und Funktionen), einer Client(Urheber)-Identifikation, wie etwa ein öffentlicher Schlüssel und Zertifikat, einer Signatur des Client, Identitäten der Endorser, Endorser-Signaturen, einem Vorschlags-Hash, ausführbaren Smart-Contract-Code-Ereignissen, Antwortstatus, Namensraum, einem gelesenen Satz (Aufstellung von Schlüssel und Version, welche durch den Eintrag gelesen wurden, etc.), einem geschriebenen Satz (Aufstellung von Schlüssel und Wert, etc.), eines Anfangsschlüssels, eines Endschlüssels, einer Aufstellung von Schlüsseln, einer Hashbaum-Abfragenzusammenfassung und dergleichen beinhalten. Die Eintragsdaten können für jeden der N Einträge gespeichert werden.
In einigen Ausführungsformen können die Blockdaten 670 auch transaktionsspezifische Daten 672 speichern, welche der Hash-verknüpften Kette von Blöcken in der Blockchain zusätzliche Informationen hinzufügen. Demgemäß können die Daten 672 in einem unveränderlichen Protokoll von Blöcken in dem verteilten Transaktionsregister gespeichert sein. Einige der Vorteile des Speicherns derartiger Daten 672 finden sich in den verschiedenen hierin offenbarten und dargestellten Ausführungsformen wieder. Die Blockmetadaten 680 können mehrere Metadatenfelder (z.B. als ein Byte-Array, etc.) speichern. Metadatenfelder können eine Signatur bei Blockerstellung, einen Verweis auf einen letzten Konfigurationsblock, einen Eintragsfilter, der gültige und ungültige Einträge innerhalb des Blocks identifiziert, einen letzten persistenten Offset eines Ordnungsdienstes, der den Block geordnet hat, und dergleichen beinhalten. Die Signatur, der letzte Konfigurationsblock und die Orderer-Metadaten können durch den Ordnungsdienst hinzugefügt werden. Indes kann ein Committer des Blocks (wie etwa ein Blockchain-Knoten) Validitäts-/Invaliditätsinformationen basierend auf einer Endorsement Policy, Verifizierung von gelesenen/geschriebenen Sätzen und dergleichen hinzufügen. Der Eintragsfilter kann ein Byte-Array einer Größe gleich der Anzahl von Einträgen in den Blockdaten 670 und einen Validierungscode, der identifiziert, ob ein Eintrag gültig/ungültig war, beinhalten.
Die obigen Ausführungsformen sind in Hardware, in einem durch einen Prozessor ausgeführten Computerprogramm, in Firmware oder in einer Kombination der Vorstehenden implementierbar. Ein Computerprogramm kann auf einem computerlesbaren Medium, wie etwa einem Speichermedium, realisiert sein. Beispielsweise kann sich ein Computerprogramm in einem Direktzugriffsspeicher („RAM“), Flash-Speicher, Nur-Lese-Speicher („ROM“), löschbaren, programmierbaren Nur-Lese-Speicher („EPROM“), elektrisch löschbaren, programmierbaren Nur-Lese-Speicher („EEPROM“), Registern, einer Festplatte, einem Wechseldatenträger, einem Kompaktplatten-Nur-Lese-Speicher („CD-ROM“) oder irgendeiner anderen in der Technik bekannten Form eines Speichermediums befinden.
Ein beispielhaftes Speichermedium kann mit dem Prozessor derart gekoppelt sein, dass der Prozessor Informationen aus dem Speichermedium lesen und Informationen in dieses schreiben kann. Alternativ kann das Speichermedium mit dem Prozessor integriert sein. Der Prozessor und das Speichermedium können sich in einer anwendungsspezifischen integrierten Schaltung („ASIC“) befinden. Alternativ können der Prozessor und das Speichermedium als diskrete Komponenten vorhanden sein. Beispielsweise veranschaulicht 7 eine beispielhafte Computersystemarchitektur 700, welche irgendeine der oben beschriebenen Komponenten repräsentieren oder darin integriert sein kann, etc.
7 ist nicht dazu vorgesehen, irgendeine Beschränkung in Bezug auf den Verwendungs- oder Funktionalitätsumfang von hierin beschriebenen Ausführungsformen der Anmeldung zu suggerieren. Ungeachtet dessen kann der Rechenknoten 800 irgendeine der oben aufgeführten Funktionalitäten implementieren und/oder durchführen.
Im Rechenknoten 700 ist ein Computersystem/Server 702 vorhanden, der mit zahlreichen anderen Universal- oder Spezial-Rechensystemumgebungen oder -konfigurationen betreibbar ist. Beispiele für weithin bekannte Rechensysteme, -umgebungen und/oder -konfigurationen, die sich zur Verwendung mit dem Computersystem/Server 702 eignen mögen, beinhalten Personalcomputersysteme, Server-Computersysteme, Thin Clients, Thick Clients, in der Hand gehaltene oder Laptop-Geräte, Multiprozessorsysteme, mikroprozessorbasierte Systeme, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Großrechnersysteme und verteilte Cloud-Rechenumgebungen, welche beliebige der obigen Systeme oder Vorrichtungen beinhalten, und dergleichen, sind jedoch nicht auf diese beschränkt.
Das Computersystem/der Server 702 kann im allgemeinen Zusammenhang von auf einem Computersystem ausführbaren Anweisungen, wie etwa Programmmodulen, die durch ein Computersystem ausgeführt werden, beschrieben werden. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Logiken, Datenstrukturen und so fort beinhalten, welche bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Das Computersystem/der Server 702 kann in verteilten Cloud-Rechenumgebungen angewendet werden, in denen Aufgaben von entfernten Verarbeitungsvorrichtungen durchgeführt werden, welche durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Cloud-Rechenumgebung können Programmmodule sowohl in lokalen als auch in entfernten Computersystem-Speichermedien angeordnet sein, welche Speichervorrichtungen beinhalten.
Wie in 7 gezeigt, ist das Computersystem/der Server 702 in dem Cloud-Rechenknoten 700 in Form einer Universalrechenvorrichtung dargestellt. Die Komponenten des Computersystems/Servers 702 können einen oder mehrere Prozessoren oder Verarbeitungseinheiten 704, einen Systemspeicher 706 und einen Bus, der verschiedene Systemkomponenten einschließlich des Systemspeichers 706 an den Prozessor 704 koppelt, beinhalten, sind jedoch nicht hierauf beschränkt.
Der Bus repräsentiert eine oder mehrere beliebige verschiedene Arten von Busstrukturen, die einen Speicherbus oder eine Speichersteuervorrichtung, einen Peripheriebus, einen Accelerated Graphics Port und einen Prozessor oder einen lokalen Bus, der eine beliebige einer Vielfalt an Busarchitekturen nutzt, beinhalten. Derartige Architekturen beinhalten beispielhaft und nicht einschränkend einen Industry-Standard-Architecture-Bus (ISA-Bus), einen Micro-Channel-Architecture-Bus (MCA-Bus), einen Enhanced-ISA-Bus (EISA-Bus), einen lokalen Video-Electronics-Standards-Association-Bus (VESA-Bus) und einen Peripheral-Component-Interconnects-Bus (PCI-Bus).
Das Computersystem/der Server 702 beinhaltet typischerweise eine Vielzahl an von einem Computersystem lesbaren Medien. Solche Medien können beliebige verfügbare Medien sein, auf die das Computersystem/der Server 702 zugreifen kann, und beinhalten sowohl flüchtige als auch nichtflüchtige Medien, entfernbare und nicht entfernbare Medien. Der Systemspeicher 706 implementiert in einer Ausführungsform die Flussdiagramme der anderen Figuren. Der Systemspeicher 706 kann vom Computersystem lesbare Medien in Form eines flüchtigen Speichers, wie etwa einen Direktzugriffsspeicher (RAM) 710 und/oder einen Cachespeicher 712, beinhalten. Das Computersystem/der Server 702 kann ferner andere entfernbare/nicht entfernbare, flüchtige/nichtflüchtige Computersystem-Speichermedien beinhalten. Rein beispielhaft kann der Speicher 706 für das Lesen und Beschreiben eines nicht entfernbaren, nichtflüchtigen magnetischen Mediums (nicht gezeigt und typischerweise als „Festplatte“ bezeichnet) vorgesehen sein. Obzwar nicht gezeigt, können ein Magnetplattenlaufwerk zum Lesen und Beschreiben einer entfernbaren, nichtflüchtigen Magnetplatte (z.B. einer „Diskette“) und ein optisches Laufwerk zum Lesen oder Beschreiben einer entfernbaren, nichtflüchtigen optischen Platte wie etwa einer CD-ROM, DVD-ROM oder anderer optischer Medien vorgesehen werden. In solchen Fällen können diese jeweils durch eine oder mehrere Datenmedienschnittstellen an den Bus angeschlossen werden. Wie nachfolgend weiter dargestellt und beschrieben wird, kann der Speicher 706 mindestens ein Programmprodukt mit einem Satz (z.B. mindestens einem) von Programmmodulen beinhalten, die konfiguriert sind, um die Funktionen verschiedener Ausführungsformen der Anmeldung durchzuführen.
Ein Programm/Dienstprogramm, das einen Satz (mindestens einen) von Programmmodulen aufweist, kann, zum Beispiel und nicht einschränkend, in dem Speicher 706 sowie einem Betriebssystem, einem oder mehreren Anwendungsprogrammen, anderen Programmmodulen und Programmdaten gespeichert werden. Jedes von dem Betriebssystem, dem einen oder den mehreren Anwendungsprogrammen, anderen Programmmodulen und Programmdaten oder einer Kombination davon kann eine Implementierung einer Netzwerkumgebung beinhalten. Programmmodule führen generell die Funktionen und/oder Methodologien verschiedener hierin beschriebener Ausführungsformen der Anmeldung durch.
Wie ein Fachmann erkennen wird, können Aspekte der vorliegenden Anmeldung als ein System, Verfahren oder Computerprogrammprodukt ausgeführt werden. Demgemäß können Aspekte der vorliegenden Anmeldung die Form einer reinen Hardware-Ausführung, einer reinen Software-Ausführung (einschließlich Firmware, residenter Software, Microcode, etc.) oder einer Ausführung annehmen, die Software- und Hardware-Aspekte kombiniert, welche alle hierin generell als eine „Schaltung“, ein „Modul“ oder „System“ bezeichnet werden können. Ferner können Aspekte der vorliegenden Anmeldung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien mit einem darauf verkörperten computerlesbaren Programmcode ausgeführt ist.
Das Computersystem/der Server 702 kann über einen E/A-Adapter 720 auch mit einer oder mehreren externen Vorrichtungen kommunizieren, wie etwa einer Tastatur, einem Zeigegerät, einer Anzeigevorrichtung, etc.; einer oder mehreren Vorrichtungen, die es einem Nutzer ermöglichen, mit dem Computersystem/Server 702 zu interagieren; und/oder beliebigen Vorrichtungen (z.B. Netzwerkkarte, Modem, etc.), die es dem Computersystem/Server 702 ermöglichen, mit einer oder mehreren anderen Rechenvorrichtungen zu kommunizieren. Eine solche Kommunikation kann über E/A-Schnittstellen des Adapters 720 erfolgen. Noch dazu kann das Computersystem/der Server 702 über einen Netzwerkadapter mit einem oder mehreren Netzen wie etwa einem lokalen Netz (LAN von engl. Local Area Network), einem allgemeinen Weitverkehrsnetz (WAN von engl. Wide Area Network) und/oder einem öffentlichen Netz (z.B. dem Internet) kommunizieren. Wie dargestellt, kommuniziert der Adapter 720 über einen Bus mit den anderen Komponenten des Computersystems/Servers 702. Es sollte verstanden werden, dass, obwohl nicht gezeigt, andere Hardware- und/oder Softwarekomponenten in Verbindung mit dem Computersystem/Server 702 verwendet werden könnten. Beispiele beinhalten, sind jedoch nicht beschränkt auf: Mikrocode, Gerätetreiber, redundante Verarbeitungseinheiten, externe Festplattenlaufwerk-Anordnungen, RAID-Systeme, Bandlaufwerke und Systeme für Datenarchivierung und -speicherung, etc.
Obzwar eine beispielhafte Ausführungsform mindestens eines Systems, Verfahrens und nichttransitorischen computerlesbaren Mediums in den begleitenden Zeichnungen veranschaulicht ist und in der vorstehenden detaillierten Beschreibung beschrieben wurde, versteht sich, dass die Anmeldung nicht auf die offenbarten Ausführungsformen beschränkt ist, sondern zahlreiche Umordnungen, Modifikationen und Ersetzungen wie durch die folgenden Ansprüche aufgeführt und definiert möglich sind. Beispielsweise können die Fähigkeiten des Systems der verschiedenen Figuren durch ein(e) oder mehrere der hierin beschriebenen Module oder Komponenten oder in einer verteilten Architektur ausgeführt werden und können einen Sender, Empfänger oder ein Paar aus beiden umfassen. Beispielsweise kann die durch die einzelnen Module ausgeübte Funktionalität gänzlich oder zum Teil durch eines oder mehrere dieser Module ausgeübt werden. Ferner kann die hierin beschriebene Funktionalität zu unterschiedlichen Zeiten und in Bezug auf verschiedene, zu den Modulen oder Komponenten interne oder externe Ereignisse ausgeführt werden. Auch können die zwischen verschiedenen Modulen versendeten Informationen zwischen den Modulen über mindestens eines aus: einem Datennetz, dem Internet, einem Sprachnetz, einem Internetprotokollnetz, einer drahtlosen Vorrichtung, einer drahtgebundenen Vorrichtung und/oder über eine Mehrzahl von Protokollen versendet werden. Auch können die durch beliebige der Module gesendeten oder empfangenen Nachrichten unmittelbar und/oder über eines oder mehrere der anderen Module gesendet oder empfangen werden.
Ein Fachmann wird erkennen, dass ein „System“ als ein Personal Computer, ein Server, eine Konsole, ein persönlicher digitaler Assistent (PDA), ein Mobiltelefon, eine Tablet-Rechenvorrichtung, ein Smartphone oder irgendeine andere geeignete Rechenvorrichtung oder Kombination von Vorrichtungen ausgeführt werden könnte. Die Darstellung der oben beschriebenen Funktionen als von einem „System“ ausgeführt ist nicht dazu vorgesehen, den Umfang der vorliegenden Anmeldung auf irgendeine Weise zu beschränken, sondern soll ein Beispiel für viele Ausführungsformen liefern. In der Tat sind hierin offenbarte Verfahren, Systeme und Vorrichtungen in mit der Computertechnologie übereinstimmenden lokalisierten und verteilten Formen implementierbar.
Es sei darauf hingewiesen, dass einige der in dieser Schrift beschriebenen Systemmerkmale als Module präsentiert wurden, um ihre Implementierungsunabhängigkeit stärker zu betonen. Beispielsweise kann ein Modul als eine Hardwareschaltung implementiert werden, die benutzerdefinierte höchstintegrierte (VLSI) Schaltungen oder Gatteranordnungen, Standardhalbleiter wie etwa Logikchips, Transistoren oder andere diskrete Komponenten aufweist. Ein Modul ist auch in programmierbaren Hardwarevorrichtungen wie etwa feldprogrammierbaren Gatteranordnungen, programmierbarer Feldlogik, programmierbaren Logikvorrichtungen, Graphikverarbeitungseinheiten oder dergleichen implementierbar.
Ein Modul ist auch zumindest teilweise in Software zur Ausführung durch verschiedene Arten von Prozessoren implementierbar. Eine identifizierte Einheit eines ausführbaren Codes kann beispielsweise einen oder mehrere physikalische oder logische Blöcke von Computeranweisungen umfassen, welche beispielsweise als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Dateien eines identifizierten Moduls nicht physikalisch zusammen angeordnet sein, sondern können disparate Anweisungen umfassen, die an unterschiedlichen Orten gespeichert sind und die, wenn sie logisch zusammengefügt werden, das Modul umfassen und den angegebenen Zweck für das Modul erreichen. Ferner können Module auf einem computerlesbaren Medium gespeichert sein, welches beispielsweise ein Festplattenlaufwerk, Flash-Gerät, Direktzugriffsspeicher (RAM), Band oder irgendein anderes solches Medium, das zum Speichern von Daten verwendet wird, sein kann.
Tatsächlich könnte ein ausführbares Codemodul eine einzelne Anweisung oder viele Anweisungen sein und könnte sogar über mehrere unterschiedliche Codesegmente, zwischen unterschiedlichen Programmen und über mehrere Speichervorrichtungen hinweg verteilt sein. Analog können betriebliche Daten hierin innerhalb von Modulen identifiziert und dargestellt werden und können auf irgendeine geeignete Form realisiert und innerhalb irgendeiner geeigneten Art von Datenstruktur organisiert sein. Die betrieblichen Daten können als ein einzelner Datensatz gesammelt werden oder können über unterschiedliche Orte, darunter über unterschiedliche Speichervorrichtungen, verteilt werden, und können zumindest teilweise lediglich als elektronische Signale auf einem System oder Netz vorliegen.
Es versteht sich ohne Weiteres, dass die Komponenten der Anmeldung, wie sie in den Figuren hierin allgemein beschrieben und veranschaulicht werden, in einer Vielzahl von unterschiedlichen Konfigurationen angeordnet und gestaltet sein können. Somit ist die detaillierte Beschreibung der Ausführungsformen nicht dazu gedacht, den beanspruchten Umfang der Anmeldung zu beschränken, sondern ist lediglich repräsentativ für ausgewählte Ausführungsformen der Anmeldung.
Ein einschlägiger Fachmann wird ohne Weiteres verstehen, dass das Vorstehende mit Schritten in einer unterschiedlichen Reihenfolge und/oder mit Hardwareelementen in anderen Konfigurationen als den offenbarten anwendbar ist. Obwohl die Anmeldung basierend auf diesen bevorzugten Ausführungsformen beschrieben wurde, versteht es sich daher für Fachleute, dass bestimmte Modifikationen, Variationen und alternative Bauweisen offensichtlich sind.
Während bevorzugte Ausführungsformen der vorliegenden Anmeldung beschrieben wurden, sollte verstanden werden, dass die beschriebenen Ausführungsformen lediglich veranschaulichend sind und der Umfang der Anmeldung nur durch die angehängten Ansprüche zu definieren ist, wenn ein breites Spektrum an Äquivalenten und Modifikationen (z.B. Protokollen, Hardwaregeräten, Softwareplattformen, etc.) derselben berücksichtigt wird.

Claims

System, das aufweist: einen Server, der ausgelegt ist zum: Bereitstellen eines Wertes für ein Verkehrsmittel durch einen oder mehrere Empfänger basierend auf Sensordaten mittels eines Smart Contracts, der sich auf die von dem Verkehrsmittel an den einen oder die mehreren Empfänger gesendeten Sensordaten, den für das Verkehrsmittel bereitgestellten Wert, ein den gesendeten Sensordaten zugeordnetes Datum und ein dem bereitgestellten Wert zugeordnetes Datum bezieht.
System nach Anspruch 1, wobei der Server ausgelegt ist, um Sensordaten von dem Verkehrsmittel einer oder mehreren Kategorien basierend auf Sensordaten-Teilungsberechtigungen, die in einem Profil gespeichert sind, das dem Verkehrsmittel zugeordnet ist, zuzuweisen und die Sensordaten an den einen oder die mehreren Empfänger basierend auf der einen oder den mehreren Kategorien zu senden, wobei der eine oder die mehreren Empfänger, welche die Sensordaten empfangen, basierend auf der einen oder den mehreren Kategorien identifiziert werden, die in entsprechenden Empfängerprofilen des einen oder der mehreren Empfänger identifiziert sind.
System nach Anspruch 2, wobei die Sensordaten eine Mehrzahl von unterschiedlichen Sensordatensätzen umfassen, die von einer Mehrzahl von unterschiedlichen Sensortypen und der einen oder den mehreren dem Verkehrsmittel zugeordneten Rechenvorrichtungen gesammelt sind.
System nach Anspruch 3, wobei die Mehrzahl von unterschiedlichen Sensordatensätzen unterschiedlichen der einen oder mehreren Kategorien zugewiesen sind, und wobei der eine oder die mehreren Empfänger eine Mehrzahl von unterschiedlichen Empfängern mit entsprechenden unterschiedlichen der ihren jeweiligen Empfängerprofilen zugewiesenen Kategorien umfassen.
System nach Anspruch 1, wobei erfasster Inhalt der Sensordaten einen oder mehrere aus einer Radiosenderwahl, Audioaufnahmen, Verwendung von Mobilgeräten innerhalb des Verkehrsmittels, innerhalb des Verkehrsmittels geführten Telefonaten, Browser-Verlauf mindestens einer der Rechenvorrichtungen, über die mindestens eine der Rechenvorrichtungen innerhalb des Verkehrsmittels getätigten Einkäufen, Bewegung des Verkehrsmittels, Kollision des Verkehrsmittels, Beschleunigung des Verkehrsmittels, Temperatur des Verkehrsmittels, Standort des Verkehrsmittels und erfasstem Verkehr nahe dem Verkehrsmittel umfasst.
System nach Anspruch 1, wobei ein im Zusammenhang mit den Sensordaten verwendeter Sensortyp Bewegungssensoren, Sonarsensoren, Beschleunigungssensoren, Temperatursensoren, Geschwindigkeitssensoren, Schallsensoren, Kollisionssensoren, Reifendrucksensoren, Standortbestimmungssensoren, Kamerasensoren, Aktivitätssensoren und biometrische Sensoren umfasst.
System nach Anspruch 1, ferner aufweisend: ein in einem Speicher gespeichertes verteiltes Transaktionsregister; und wobei der in dem verteilten Transaktionsregister gespeicherte Smart Contract als Antwort darauf aufgerufen wird, dass die Sensordaten als zu den Sensordaten-Teilungsberechtigungen gehörend identifiziert werden, wobei der Smart Contract mindestens einen Teil des Verkehrsmittelprofils, die Empfängerprofile, einen Typ von Sensordaten, welche Empfängerprofilen zugeordnet sind, und den Wert, welcher dem Verkehrsmittel basierend auf den geteilten Sensordaten zugeordnet ist, umfasst.
System nach Anspruch 1, wobei der eine oder die mehreren Empfänger, die zum Empfangen der Sensordaten registriert sind, basierend auf der einen oder den mehreren Kategorien identifiziert werden, die in entsprechenden Empfängerprofilen des einen oder der mehreren Empfänger identifiziert sind.
Verfahren, das umfasst: Bereitstellen eines Wertes für ein Verkehrsmittel durch einen oder mehrere Empfänger basierend auf Sensordaten mittels eines Smart Contracts, der sich auf die von dem Verkehrsmittel an den einen oder die mehreren Empfänger gesendeten Sensordaten, den für das Verkehrsmittel bereitgestellten Wert, ein den gesendeten Sensordaten zugeordnetes Datum und ein dem bereitgestellten Wert zugeordnetes Datum bezieht.
Verfahren nach Anspruch 9, umfassend das Zuweisen der Sensordaten von dem Verkehrsmittel zu einer oder mehreren Kategorien basierend auf Sensordaten-Teilungsberechtigungen, die in einem Profil gespeichert sind, das dem Verkehrsmittel zugeordnet ist, und das Senden der Sensordaten an den einen oder die mehreren Empfänger basierend auf der einen oder den mehreren Kategorien, wobei der eine oder die mehreren Empfänger, welche die Sensordaten empfangen, basierend auf der einen oder den mehreren Kategorien identifiziert werden, die in entsprechenden Empfängerprofilen des einen oder der mehreren Empfänger identifiziert sind.
Verfahren nach Anspruch 10, wobei die Sensordaten eine Mehrzahl von unterschiedlichen Sensordatensätzen umfassen, die von einer Mehrzahl von unterschiedlichen Sensortypen und der einen oder den mehreren dem Verkehrsmittel zugeordneten Rechenvorrichtungen gesammelt sind.
Verfahren nach Anspruch 11, wobei die Mehrzahl von unterschiedlichen Sensordaten unterschiedlichen der einen oder mehreren Kategorien zugewiesen sind, und wobei der eine oder die mehreren Empfänger eine Mehrzahl von unterschiedlichen Empfängern mit entsprechenden unterschiedlichen der ihren jeweiligen Empfängerprofilen zugewiesenen Kategorien umfassen.
Verfahren nach Anspruch 12, wobei erfasster Inhalt der Sensordaten einen oder mehrere aus einer Radiosenderwahl, Audioaufnahmen, Verwendung von Mobilgeräten innerhalb des Verkehrsmittels, innerhalb des Verkehrsmittels geführten Telefonaten, Browser-Verlauf mindestens einer der Rechenvorrichtungen, über die mindestens eine der Rechenvorrichtungen innerhalb des Verkehrsmittels getätigten Einkäufen, Bewegung des Verkehrsmittels, Kollision des Verkehrsmittels, Beschleunigung des Verkehrsmittels, Temperatur des Verkehrsmittels, Standort des Verkehrsmittels und erfasstem Verkehr nahe dem Verkehrsmittel umfasst.
Verfahren nach Anspruch 9, wobei ein im Zusammenhang mit den Sensordaten verwendeter Sensortyp Bewegungssensoren, Sonarsensoren, Beschleunigungssensoren, Temperatursensoren, Geschwindigkeitssensoren, Schallsensoren, Kollisionssensoren, Reifendrucksensoren, Standortbestimmungssensoren, Kamerasensoren, Aktivitätssensoren und biometrische Sensoren umfasst.
Verfahren nach Anspruch 9, ferner umfassend: Speichern eines Smart Contracts in einem verteilten Transaktionsregister; und Aufrufen des Smart Contracts als Antwort darauf, dass die Sensordaten als zu den Sensordaten-Teilungsberechtigungen gehörend identifiziert werden, wobei der Smart Contract mindestens einen Teil des Verkehrsmittelprofils, die Empfängerprofile, einen Typ von Sensordaten, welche Empfängerprofilen zugeordnet sind, und den Wert, welcher dem Verkehrsmittel basierend auf den geteilten Sensordaten zugeordnet ist, umfasst.