DE102018210224A1 - Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System - Google Patents

Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System Download PDF

Info

Publication number
DE102018210224A1
DE102018210224A1 DE102018210224.4A DE102018210224A DE102018210224A1 DE 102018210224 A1 DE102018210224 A1 DE 102018210224A1 DE 102018210224 A DE102018210224 A DE 102018210224A DE 102018210224 A1 DE102018210224 A1 DE 102018210224A1
Authority
DE
Germany
Prior art keywords
transaction database
guarantees
assumptions
security contract
systems
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102018210224.4A
Other languages
English (en)
Inventor
Rakshith Amarnath
Arne Nordmann
Nik Scharmann
Simon Burton
Peter Munk
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102018210224.4A priority Critical patent/DE102018210224A1/de
Priority to PCT/EP2019/063225 priority patent/WO2019242975A1/de
Priority to CN201980041572.5A priority patent/CN112335201A/zh
Priority to EP19729451.5A priority patent/EP3811563A1/de
Priority to US17/056,247 priority patent/US20210216949A1/en
Publication of DE102018210224A1 publication Critical patent/DE102018210224A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Computational Linguistics (AREA)
  • General Engineering & Computer Science (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Technology Law (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Verfahren (10, 30, 40) zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System (11) und einem zweiten System (12),gekennzeichnet durch folgende Merkmale:- Annahmen des ersten Systems (11) bezüglich des zweiten Systems (12) und Garantien des ersten Systems (11) an das zweite System (12) werden vom ersten System (11) gesendet (14),- Annahmen des zweiten Systems (12) bezüglich des ersten Systems (11) und Garantien des zweiten Systems (12) an das erste System (11) werden vom zweiten System (12) gesendet (15),- falls die wechselseitigen Annahmen und Garantien einander entsprechen, wird ein digitaler Sicherheitsvertrag zwischen dem ersten System (11) und dem zweiten System (12) geschlossen und- der Sicherheitsvertrag wird in einer Transaktionsdatenbank (13) dokumentiert.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
  • Stand der Technik
  • Als dezentrales Transaktionssystem oder Transaktionsdatenbank (distributed ledger) wird jegliches Protokoll in Rechnernetzen bezeichnet, das eine Übereinkunft (consensus) hinsichtlich der Abfolge bestimmter Transaktionen herbeiführt, die beispielsweise die Aktualisierung von Daten betreffen. Eine häufige Ausprägung eines solchen Systems bedient sich einer Blockkette (blockchain).
  • Ein Computersystem, das mit einer Blockchain verbunden ist, wird etwa in US 9,794,074 B2 offenbart. Das Computersystem empfängt Übereinstimmungsdaten für eine Übereinstimmung zwischen einer ersten Datentransaktion, die einer ersten Kennung zugeordnet ist, und einer zweiten Datentransaktion, die einer zweiten Kennung zugeordnet ist. Basierend auf den in der Blockchain gespeicherten Daten wird eine erste Blockchain-Transaktion erzeugt. Es wird mindestens eine weitere Blockchain-Transaktion erzeugt, die die Übereinstimmung in zwei verschiedene Transaktionen aufteilt: eine zwischen der ersten Kennung und einem Vermittler und das zweite zwischen dem Vermittler.
  • Diese werden über die weiteren Blockchain-Transaktionen in der Blockchain erfasst.
  • Offenbarung der Erfindung
  • Die Erfindung stellt ein Verfahren zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
  • Das erfindungsgemäße Verfahren fußt auf der Erkenntnis, dass immer mehr sicherheitskritische Systeme im Betrieb zusammenarbeiten müssen. Diese Systeme werden mitunter von verschiedenen Herstellern entwickelt. Daher müssen sie mit anderen Systemen kooperieren, deren Verhalten und Eigenschaften zum Zeitpunkt ihres Entwurfes unbekannt sind. Beispiele für solche Systeme sind heterogene Fahrzeuge, die sich z. B. zur Verkehrsberuhigung oder -regelung oder für Notdienste miteinander austauschen, hochautomatisierte Lastwagen, die eine Kolonne bilden und automatisch einem führenden Lastwagen mit einem menschlichen Fahrer folgen, bedingt automatisierte Lastwagen, die eine Kolonne bilden und automatisch einem führenden hochautomatisierten Lastwagen folgen, Schneepflüge, die automatisch einem seitlich versetzten, von einem Menschen gelenkten Pflug auf einem Flugfeld oder einer Skipiste folgen, Autos, die mit einem Lotsensystem auf einem Parkplatz kooperieren, Landwirtschaftsroboter, die gleich einem Schwarm ein Feld düngen oder abernten, oder Herstellungsroboter, die sich auf einer Fahrfläche bewegen und mit anderen Robotern oder sogar Menschen zusammenarbeiten, um eine gemeinsame Aufgabe zu erfüllen.
  • Aufgrund der möglichen Gefährdungen sind an die Betriebssicherheit dieser „Systeme von Systemen“ hohe Anforderungen zu stellen. Um solch dynamische Konfigurationen unter Berücksichtigung der Sicherheitsanforderungen zu bewältigen, wurden in der Literatur sogenannte Sicherheitsverträge (safety contracts) vorgeschlagen. Zum Zeitpunkt seines Entwurfes wird nach diesem Ansatz für jedes System eine Reihe von (formell beschriebenen) Annahmen und Garantien definiert. Die Garantien jedes Systems unter den gegebenen Annahmen können mit bekannten Sicherheitsanalysetechniken ebenfalls im Rahmen des Entwurfes analysiert werden. Zur Laufzeit tauschen potenziell kooperierende Systeme ihre Annahmen und Garantien untereinander aus. Jedes System entscheidet dann, ob die Garantien des anderen Systems seinen Annahmen entsprechen. Wenn sie übereinstimmen, wird ein Sicherheitsvertrag geschlossen, was bedeutet, dass, solange die Annahmen jedes Systems erfüllt sind, auch die eigenen Garantien erfüllt werden. Die Annahmen und Garantien können auch Parameter enthalten, um mehr Flexibilität zu ermöglichen.
  • Betrachtet seien zum Beispiel zwei hochautomatisierte Lastwagen, die eine Kolonne bilden sollen. Dabei sei angenommen, die Fahrzeuge würden von verschiedenen Herstellern stammen, aber das Sicherheitsvertragsformat und das Austauschprotokoll seien zur Entwurfszeit vereinbart worden. Die Annahme eines Lastwagens könnte darin bestehen, dass er innerhalb einer vorgegebenen Zeitspanne X informiert wird, wenn der Lastwagen, dem er folgt, bremst. Eine Garantie indes könnte darin bestehen, dass der Lastwagen, die ihrerseits ihm folgen, innerhalb einer vorgegebenen Zeitspanne Y informiert, wenn er selbst bremst. Offensichtlich können die Sicherheitsverträge nur dann geschlossen und daher die Kolonne nur dann gebildet werden, wenn Y < X ist, was beide Lastwagen prüfen müssen.
  • Der vorgeschlagene Ansatz trägt ferner dem Umstand Rechnung, dass im Allgemeinen das Risiko eines Systemausfalls besteht. Wenn ein System ausfällt, kann es gegen seine Garantien verstoßen und wenn es zum Zeitpunkt des Ausfalls mit anderen Systemen zusammenarbeitet, bricht es seinen Sicherheitsvertrag. Obwohl der Sicherheitsvertrag einen technischen Ursprung hat, können solche Situationen rechtliche Probleme verursachen oder eine Klärung möglicher Versicherungsansprüche erfordern, insbesondere da kein Mensch an der Schließung des Sicherheitsvertrags beteiligt war und wenn verschiedene Hersteller beteiligt sind.
  • Das grundlegende Merkmal eines erfindungsgemäßen Ansatzes besteht hierbei darin, dass jedes System, das erfolgreich einen Sicherheitsvertrag mit einem anderen System geschlossen hat, einen Datensatz erstellt, der diese Informationen enthält, und diese an die Transaktionsdatenbank übermittelt.
  • Wenn das andere System versagt und den Sicherheitsvertrag verletzt, indem es die abgegebenen Garantien bricht, kann es das Zustandekommen des Vertrages nicht bestreiten. Auf diese Weise wird Rechtssicherheit für den Hersteller erreicht. Hersteller müssen nicht einer einzigen Einheit vertrauen, die die Sicherheitsverträge speichert, doch sie müssen dem vorgeschlagenen Protokoll zustimmen und es umsetzen.
  • Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass die beteiligten Systeme nach dem Aufnehmen der Zusammenarbeit jeweils wiederholt ein Umgebungsmodell an die Transaktionsdatenbank senden und letztere die Umgebungsmodelle der Blockkette hinzufügt. Im Falle eines Fehlers können diese Daten nicht abgestritten werden und helfen, die Situation zu rekonstruieren. Falls eines der teilnehmenden Systeme versagt, wird seinem Hersteller auf diese Weise der Nachweis erleichtert, dass ein Sicherheitsvertrag nicht nur bestand, sondern auch, dass ein anderes System dagegen verstoßen hat.
  • Gemäß einem weiteren Aspekt kann vorgesehen sein, dass die beteiligten Systeme nach dem Aufnehmen der Zusammenarbeit jeweils wiederholt einen Streuwert (hash) des Umgebungsmodells an die Transaktionsdatenbank senden und letztere lediglich diese Streuwerte der Blockkette hinzufügt. Der Hash des Umgebungsmodells hat eine erheblich geringere Größe als das gesamte Modell und kann daher viel schneller an die Transaktionsdatenbank gesendet werden. Bei einem Unfall kann der Hersteller nachweisen, dass die in der Systemdatenbank aufgezeichnete Umgebung nicht verändert wurde.
  • Gemäß einem weiteren Aspekt kann vorgesehen sein, dass die Systeme einen wechselseitigen Transaktionskanal etablieren, über welchen sie nach dem Empfangen des Blockes mit dem Sicherheitsvertrag Informationen und unterschriebene Mitteilungen austauschen. Dieses Konzept reduziert den Umfang der Kommunikation mit der Transaktionsdatenbank, wodurch typischerweise Transaktionsgebühren (in einer Kryptowährung) reduziert werden. Außerdem kann im Fehlerfall automatisch erkannt werden, welches System den Sicherheitsvertrag tatsächlich verletzt hat, und es kann automatisch eine Geldstrafe (in einer Kryptowährung) mit einer Kaution verrechnet werden, die beide Systeme bei der Erstellung des digitalen Vertrages aufbringen mussten. Die besagte Ausführungsform verbessert auch die Rechtssicherheit bei einem Unfall, da die zuletzt vereinbarten Informationen und deren Zeitstempel bekannt und in der Transaktionsdatenbank gespeichert sind.
  • Gemäß einem weiteren Aspekt kann vorgesehen sein, dass die Blockkette der Transaktionsdatenbank auf zahlreiche Endgeräte verteilt ist und die am Sicherheitsvertrag beteiligten Systeme eine digitale Geldbörse verwalten, aus welcher sie die Endgeräte für das Hinzufügen von Blöcken vergüten. Mit einer solchen Geldbörse werden Zahlungen an die „Schürfer“ (miners) möglich, bei denen die teilnehmenden Systeme ihnen einen Betrag zahlen könnten, der umgekehrt proportional zu der Zeit ist, die benötigt wird, um die für die Rechtssicherheit relevanten Informationen zu verifizieren und der Blockkette hinzuzufügen. Ferner wird eine echte „Wirtschaft der Dinge“ (economy of things, EoT) ermöglicht, wenn teilnehmende Systeme auf diese Weise für die bezogene Leistung zahlen oder dafür bezahlt werden, wenn sie selbst einen Dienst für andere Systeme erbringen - etwa im Falle eines vorausfahrenden Fahrzeuges, das dem nachfolgenden Fahrzeug hilft, die Möglichkeit eines Überholmanövers jenseits einer vorausliegenden Kurve einzuschätzen.
  • Figurenliste
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
    • 1 ein Verfahren, gemäß dem zwei Systeme mittels einer Blockkette eine rechtssichere Zusammenarbeit vereinbaren.
    • 2 eine Variante des Verfahrens, bei welcher die Transaktionsdatenbank mit Rechenfunktionen ausgestattet und so in der Lage ist, den Sicherheitsvertrag aufzusetzen.
    • 3 eine Variante des Verfahrens, bei welcher die Systeme einen intelligenten Kanal einrichten, um Informationen auszutauschen. Ein System sendet hierbei Informationen, die vom anderen System als fehlerhaft angesehen werden. Dank der Rechenfunktion des digitalen Vertrages in der Transaktionsdatenbank kann überprüft werden, welches System im Recht ist und welches die letzte überstimmende Information war.
    • 4 schematisch ein erfindungsgemäßes Steuergerät.
  • Ausführungsformen der Erfindung
  • 1 zeigt die Zeitachsen von zwei Systemen (11, 12) von verschiedenen Herstellern einer verteilten Transaktionsdatenbank (13). Die Systeme (11, 12) kommunizieren über eine Internetverbindung mit der verteilten Transaktionsdatenbank (13); die Kommunikation zwischen den Systemen (11, 12) erfolgt unmittelbar von Fahrzeug zu Fahrzeug (car to car, C2C) oder ebenfalls über eine Internetverbindung. Zunächst tauschen beide Systeme (11, 12) ihre Annahmen und Garantien (14, 15) aus, und jedes System prüft (16, 17), ob sie übereinstimmen, d. h. ob ein Sicherheitsvertrag unterzeichnet werden kann. Wenn dies der Fall ist, sendet jedes System (11, 12) einen Datensatz (18, 19) an die Transaktionsdatenbank (13). Der jeweilige Datensatz (18, 19) kann die grundlegende Information, dass ein Sicherheitsvertrag geschlossen wurde, sowie die Eigenschaften oder die Gesamtheit der vereinbarten Annahmen und Garantien enthalten. Da beide Systeme (11, 12) einen Datensatz (18, 19) erstellen, kann jeder Datensatz (18, 19) die Kennung (identifier, ID) der „Gegenseite“ (12 bzw. 11) enthalten.
  • Diese ID sollte in der verteilten Transaktionsdatenbank (13) eindeutig sein und ist der sogenannten Wallet-ID einer Kryptowährung vergleichbar.
  • Für die Zeitspanne, die bis zur Aufnahme des Datensatzes (18, 19) in die verteilte Transaktionsdatenbank (13) benötigt wird, bieten sich zwei mögliche Verfahrensweisen an: Entweder nehmen die Systeme (11, 12) die Zusammenarbeit auf und verzichten auf abschließende Rechtssicherheit, bis der Datensatz (18, 19) der Blockkette hinzugefügt wird, oder warten, bis der Datensatz (18, 19) hinzugefügt wurde, bevor sie mit der Zusammenarbeit beginnen (23). In der Ausführungsform gemäß 1 warten beide Systeme (11, 12), bis sie eine Bestätigung von der Transaktionsdatenbank (13) darüber erhalten, dass der Block erfolgreich hinzugefügt wurde.
  • Sobald die Datensätze (18, 19) in der Transaktionsdatenbank (13) abgelegt und die neuen Blöcke (21) von beiden Systemen (11, 12) empfangen wurden, kann jedes System (11, 12) prüfen (22, 23), ob die jeweils andere Partei (12 bzw. 11) einen übereinstimmenden Datensatz (19 bzw. 18) erstellt hat. Wenn kein Datensatz hinzugefügt wurde, ist die ID des Gegenübers falsch; wenn zwar ein Datensatz hinzugefügt wurde, dessen ID jedoch nicht übereinstimmt, ist ein Fehler oder Angriff wahrscheinlich und die Zusammenarbeit wird aufgegeben. In 1 stimmen die Datensätze (18, 19) beider Systeme (11, 12) überein und letztere nehmen die Zusammenarbeit auf (23).
  • Betrachtet sei nun der Fall, dass ein System (11, 12) ausfällt und seine Garantie bzw. den Sicherheitsvertrag verletzt, wie im Falle des zweiten, abbildungsgemäß rechten Systems (12) in 1 dargestellt. Wenn möglich, überwacht das erste System (11) die vom zweiten System (12) empfangenen Daten und prüft, ob dieses die vereinbarten Garantien erfüllt. Wenn die entsprechende Überwachungskomponente eine Verletzung (25) des Sicherheitsvertrags feststellt, beendet sie die Zusammenarbeit (26) und versucht, das System (11) in einen sicheren Zustand zu versetzen. Dies mag im Einzelfall nicht möglich sein, da komplexe Garantien gar nicht erst überwacht werden können. In jedem Fall haben beide Hersteller Zugang zu dem Sicherheitsvertrag, den beide Systeme (11, 12) geschlossen haben, und keiner der beiden kann den Vertragsschluss daher bestreiten. Daher hat jeder Hersteller im Falle einer Garantieverletzung oder eines Unfalls nachzuweisen, dass sein System (11, 12) diesen Sicherheitsvertrag erfüllt hat. Man beachte, dass dieses Vorgehen im Wesentlichen dem üblichen Verfahren nach einem Unfall zwischen herkömmlichen Fahrzeugen entspricht, wobei die Straßenverkehrsordnung dem Sicherheitsvertrag entspricht.
  • Eine erste Variante des Verfahrens (10) nimmt sich des Problems an, dass, falls die teilnehmenden Systeme (11, 12) versagen, deren Hersteller zwar nachweisen können, dass ein Sicherheitsvertrag bestand, aber nicht beweisen können, dass das jeweils andere System (12, 11) gegen diesen verstoßen hat. Eine Möglichkeit, diesen Nachweis zu erleichtern, besteht darin, dass der Sicherheitsvertrag eine Klausel enthält, wonach beide Systeme (11, 12) eine Darstellung ihres Systemzustandes einschließlich ihres Umgebungsmodells (Kamerabild, Position in der Karte etc.) wie im Sicherheitsvertrag definiert periodisch an die verteilte Transaktionsdatenbank (13) senden müssen.
  • Eine zweite Variante ähnelt der ersten, wobei jedoch jedes System (11, 12) einen kryptografischen Hash seines gesamten Umgebungsmodells erstellt und das Modell und den Hash in einer lokalen Datenbank speichert.
  • Eine dritte Variante (30 - 2) nutzt die Möglichkeit einiger verteilter Transaktionsdatenbanken, in einem Datensatz enthaltene ausführbare Anweisungen auf mehreren Endgeräten verteilt zu berechnen. Ein bekanntes Beispiel für eine für eine solche Transaktionsdatenbank ist die Kryptowährung „Ethereum“, welche entsprechende Funktionen für digitale Verträge erfüllt. Daher ist es auch möglich, dass beide Systeme (11, 12) ihre Annahmen und Garantien an eine verteilte Transaktionsdatenbank (13) mit Berechnungsfähigkeit senden, wie in 2 gezeigt. Die verteilte Transaktionsdatenbank (13) bewertet die Annahmen und Garantien und speichert im Erfolgsfall den Sicherheitsvertrag (31). Die Systeme (11, 12) beginnen mit der Zusammenarbeit (23), sobald sie jeweils den Block mit ihrem Sicherheitsvertrag (32) erhalten haben.
  • Eine in 3 dargestellte vierte Variante (40) erweitert die dritte Variante wie folgt: Blockchains wie „Lightning“ und „Raiden“ haben ein als Transaktions- oder Zustandskanal (state Channel) bezeichnetes Konzept eingeführt. Ein Zustandskanal ist ein direkter Kommunikationskanal zwischen den Systemen (11, 12) und ein digitaler Vertrag in der Blockchain, der von diesen Systemen (11, 12) geschlossen wird. Die Systeme (11, 12) tauschen über diesen Kanal Informationen direkt aus. Das Empfängersystem (11, 12) quittiert die jeweils empfangene Information (42, 44, 46) mit einer kryptografisch signierten Mitteilung (43, 45), wenn es der empfangenen Nachricht zustimmt. Falls beide Systeme (11, 12) die Zusammenarbeit beenden wollen oder eines der Systeme (11, 12) feststellt, dass die empfangene Information (hier: 46) den Sicherheitsvertrag verletzt, z. B. die Bremskraft eines entsprechend ausgerüsteten Fahrzeuges den im Sicherheitsvertrag definierten Maximalwert übersteigt, kann es im digitalen Vertrag in der Blockchain eine Abrechnungsfunktion ausführen (47). Beide Systeme (11, 12) müssen dann den digitalen Vertrag vom letzten einvernehmlichen Zustand gewissermaßen „überzeugen“, indem sie ihre Zustimmungsmitteilungen absenden.
  • Den Schwerpunkt der bisher erläuterten Ausführungsformen stellt die Rechtssicherheit für die zusammenarbeitenden Systeme (11, 12) aufgrund der Manipulationssicherheit der Blockchain dar. Da jedoch Rechenleistung aufgewendet wird, um Blöcke zu pflegen und zu aktualisieren, ist auch eine Belohnung für den hierzu erbrachten Arbeitsnachweis (proof of work, PoW) wünschenswert. Daher sieht eine fünfte Variante des Verfahrens (10) vor, dass die teilnehmenden Systeme mit Mechanismen ausgestattet sind, um zum Beispiel mittels digitaler Geldbörsen Transaktionen durchzuführen, um Einheiten einer virtuellen Währung als Werteinheit für die Zusammenarbeit zu speichern.
  • Gemäß einer sechsten Variante kann die Einbeziehung der von früheren Kollaborationspartnern bewerteten Vertrauenswürdigkeit eines Systems die Auswahl des Partners für eine spätere Zusammenarbeit einschränken. Im Hinblick auf einen solchen Anwendungsfall kann eine virtuelle Krypto-Wallet auch die besagte Vertrauenswürdigkeit speichern. Dies würde beispielsweise ermöglichen, dass ein Produkt für die Verwendung in bestimmten Interaktionsszenarien zertifiziert (und ihm dadurch eine Vertrauenswürdigkeit zugewiesen) wird, wodurch die Zusammenarbeit auf Produkte beschränkt wird, die grundsätzlich kompatibel sein sollten. Das Vertrauen, das dem anderen System entgegengebracht wird, kann sich im Laufe der Zeit abhängig von der Quantität und Qualität seiner Zusammenarbeit erhöhen. Die resultierende Bewertung kommt nicht nur den an der Blockkette beteiligten Endgeräten, sondern auch Zertifizierungsstellen und anderen Treuhändern zugute.
  • Gemäß einer siebten Variante schließlich können die Sicherheitsverträge von den Systemen anstelle der Blockchain an einen zentralen Server oder eine Datenbank gesendet werden, dem bzw. der die Hersteller der Systeme vertrauen.
  • Dieses Verfahren kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät (50) implementiert sein, wie die schematische Darstellung der 4 verdeutlicht.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 9794074 B2 [0003]

Claims (10)

  1. Verfahren (10, 30, 40) zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System (11) und einem zweiten System (12), gekennzeichnet durch folgende Merkmale: - Annahmen des ersten Systems (11) bezüglich des zweiten Systems (12) und Garantien des ersten Systems (11) an das zweite System (12) werden vom ersten System (11) gesendet (14), - Annahmen des zweiten Systems (12) bezüglich des ersten Systems (11) und Garantien des zweiten Systems (12) an das erste System (11) werden vom zweiten System (12) gesendet (15), - falls die wechselseitigen Annahmen und Garantien einander entsprechen, wird ein digitaler Sicherheitsvertrag zwischen dem ersten System (11) und dem zweiten System (12) geschlossen und - der Sicherheitsvertrag wird in einer Transaktionsdatenbank (13) dokumentiert.
  2. Verfahren (10, 30, 40) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - die Annahmen des ersten Systems (11) bezüglich des zweiten Systems (12) und Garantien des ersten Systems (11) an das zweite System (12) werden vom zweiten System (12) empfangen, - die Annahmen des zweiten Systems (12) bezüglich des ersten Systems (11) und Garantien des zweiten Systems (12) an das erste System (11) werden vom ersten System (11) empfangen, - das erste System (11) prüft (16), ob die Garantien des zweiten Systems (12) den Annahmen des ersten Systems (11) entsprechen und sendet gegebenenfalls einen ersten Eintrag (18) mit dem Sicherheitsvertrag und einer Kennung des zweiten Systems (12) an die Transaktionsdatenbank (13), - das zweite System (12) prüft (17), ob die Garantien des ersten Systems (11) den Annahmen des zweiten Systems (12) entsprechen und sendet gegebenenfalls einen zweiten Eintrag (19) mit dem Sicherheitsvertrag und einer Kennung des ersten Systems (11) an die Transaktionsdatenbank (13), - die Transaktionsdatenbank (13) fügt die Einträge einer Blockkette hinzu (20), - die Transaktionsdatenbank (13) sendet die hinzugefügten Einträge der Blockkette (21) an das erste System (11) und das zweite System (12), - das erste System (11) prüft (22) den zweiten Eintrag, - das zweite System (12) prüft (23) den ersten Eintrag, - wenn die Einträge übereinstimmen, nehmen das erste System (11) und das zweite System (12) die Zusammenarbeit auf (24) und - wenn eines der Systeme (11, 12) eine Verletzung (25) des Sicherheitsvertrages durch das andere System (12, 11) feststellt, beendet es die Zusammenarbeit (26).
  3. Verfahren (10, 30, 40) nach Anspruch 2, gekennzeichnet durch folgendes Merkmal: - das erste System (11) und das zweite System (12) senden nach dem Aufnehmen der Zusammenarbeit (24) jeweils wiederholt ein Umgebungsmodell an die Transaktionsdatenbank (13) und - die Transaktionsdatenbank (13) fügt der Blockkette die Umgebungsmodelle hinzu.
  4. Verfahren (10, 30, 40) nach Anspruch 2, gekennzeichnet durch folgende Merkmale: - das erste System (11) und das zweite System (12) senden nach dem Aufnehmen der Zusammenarbeit (24) jeweils wiederholt einen Streuwert eines Umgebungsmodells an die Transaktionsdatenbank (13) und - die Transaktionsdatenbank (13) fügt der Blockkette die Streuwerte hinzu.
  5. Verfahren (10, 30, 40) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - die Annahmen des ersten Systems (11) bezüglich des zweiten Systems (12), Garantien des ersten Systems (11) an das zweite System (12), Annahmen des zweiten Systems (12) bezüglich des ersten Systems (11) und Garantien des zweiten Systems (12) an das erste System (11) werden von der Transaktionsdatenbank (13) empfangen (14, 15), - die Transaktionsdatenbank (13) prüft, ob die Garantien des zweiten Systems (12) den Annahmen des ersten Systems (11) und die Garantien des ersten Systems (11) den Annahmen des zweiten Systems (12) entsprechen, setzt gegebenenfalls den Sicherheitsvertrag auf (31) und fügt der Blockkette einen entsprechenden Block hinzu, - die Transaktionsdatenbank (13) sendet den Block mit dem Sicherheitsvertrag (32) an das erste System (11) und das zweite System (12) und - wenn sie den Block empfangen, nehmen das erste System (11) und das zweite System (12) die Zusammenarbeit auf (23).
  6. Verfahren (10, 30, 40) nach Anspruch 5, gekennzeichnet durch folgende Merkmale: - das erste System (11) und das zweite System (12) etablieren einen wechselseitigen Transaktionskanal, - nach dem Empfangen des Blockes mit dem Sicherheitsvertrag (41) tauschen die Systeme (11, 12) Informationen (42, 44, 46) und unterschriebene Mitteilungen (43, 45) über den Transaktionskanal aus, - wenn eines der Systeme (11, 12) eine den Sicherheitsvertrag verletzende Information (46) empfängt, ersucht es die Transaktionsdatenbank (13) um eine Schlichtung (47), - die Transaktionsdatenbank (13) setzt das andere System (12, 11) von der Schlichtung in Kenntnis (48), fordert von diesem die vermeintlich den Sicherheitsvertrag verletzende Information (46) an, und prüft diese Information (49) anhand des Sicherheitsvertrags.
  7. Verfahren (10, 30, 40) nach einem der Ansprüche 2 bis 6, gekennzeichnet durch folgende Merkmale: - die Blockkette ist auf zahlreiche Endgeräte verteilt, - die Systeme (11, 12) verwalten eine digitale Geldbörse und - die Endgeräte werden aus der Geldbörse für das Hinzufügen der Blöcke vergütet.
  8. Computerprogramm, welches eingerichtet ist, das Verfahren (10, 30, 40) nach einem der Ansprüche 1 bis 7 auszuführen.
  9. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 8 gespeichert ist.
  10. Vorrichtung, die eingerichtet ist, das Verfahren (10, 30, 40) nach einem der Ansprüche 1 bis 7 auszuführen.
DE102018210224.4A 2018-06-22 2018-06-22 Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System Pending DE102018210224A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102018210224.4A DE102018210224A1 (de) 2018-06-22 2018-06-22 Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System
PCT/EP2019/063225 WO2019242975A1 (de) 2018-06-22 2019-05-22 Verfahren und vorrichtung zum vereinbaren einer zusammenarbeit zwischen einem ersten system und einem zweiten system
CN201980041572.5A CN112335201A (zh) 2018-06-22 2019-05-22 用于在第一系统和第二系统之间约定协作的方法和设备
EP19729451.5A EP3811563A1 (de) 2018-06-22 2019-05-22 Verfahren und vorrichtung zum vereinbaren einer zusammenarbeit zwischen einem ersten system und einem zweiten system
US17/056,247 US20210216949A1 (en) 2018-06-22 2019-05-22 Method and device for agreeing to a collaboration between a first system and a second system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018210224.4A DE102018210224A1 (de) 2018-06-22 2018-06-22 Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System

Publications (1)

Publication Number Publication Date
DE102018210224A1 true DE102018210224A1 (de) 2019-12-24

Family

ID=66810757

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018210224.4A Pending DE102018210224A1 (de) 2018-06-22 2018-06-22 Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System

Country Status (5)

Country Link
US (1) US20210216949A1 (de)
EP (1) EP3811563A1 (de)
CN (1) CN112335201A (de)
DE (1) DE102018210224A1 (de)
WO (1) WO2019242975A1 (de)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020205528A1 (de) 2020-04-30 2021-11-04 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Abwickeln einer Transaktion
DE102020205529A1 (de) 2020-04-30 2021-11-04 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge
DE102020207563A1 (de) 2020-06-18 2021-12-23 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Erteilen einer Gutschrift über einen Zahlungskanal
DE102020210000A1 (de) 2020-08-06 2022-02-10 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Bestätigen eines Rechtsgeschäftes
DE102020211936A1 (de) 2020-09-23 2022-03-24 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Betreiben einer verteilten Anwendung
DE102020212330A1 (de) 2020-09-30 2022-03-31 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Betreiben einer dezentralen Anwendung durch Teilnehmer einer Blockkette
DE102020213240A1 (de) 2020-10-20 2022-04-21 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Abwickeln einer Transaktion zwischen mehreren Partitionen einer Blockkette
DE102020213245A1 (de) 2020-10-20 2022-04-21 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Erzeugen einer pseudozufälligen Zahlenfolge

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9794074B2 (en) 2016-02-04 2017-10-17 Nasdaq Technology Ab Systems and methods for storing and sharing transactional data using distributed computing systems

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1247235A4 (de) * 2000-03-06 2008-12-31 Wellogix Inc VERFAHREN UND PROZESS ZUR LIEFERUNG VON RELEVANTEN DATEN, ZUM VERGLEICHEN VON ALTERNATIVEN VORSCHLäGEN UND ZUR ABSTIMMUNG VON VORSCHLäGEN, RECHNUNGEN UND KAUFAUFTRäGEN MIT AKTUELLEN KOSTEN IN EINEM ARBEITSABLAUFPROZESS
US20020165726A1 (en) * 2001-05-07 2002-11-07 Grundfest Joseph A. System and method for facilitating creation and management of contractual relationships and corresponding contracts
US7644019B2 (en) * 2003-04-21 2010-01-05 Buysafe, Inc. Safe transaction guaranty
JP4663374B2 (ja) * 2005-03-31 2011-04-06 株式会社三井住友銀行 債券照合・債務引受状況管理方法およびシステム
KR20140002343A (ko) * 2012-06-29 2014-01-08 김인철 개인간 거래, 대출, 금전, 물품대금, 공사대금, 보증금, 채무금, 어음, 차용증, 개인간 서면 각서, 민사, 형사, 내용증명, 합의서등의 증명 서비스 및 그 방법
US11200564B2 (en) * 2015-03-31 2021-12-14 Nasdaq, Inc. Systems and methods of blockchain transaction recordation
CN105719185B (zh) * 2016-01-22 2019-02-15 杭州复杂美科技有限公司 区块链的数据对比及共识方法
CN107424073A (zh) * 2017-07-17 2017-12-01 杭州复杂美科技有限公司 一种跨链数字债权交易的方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9794074B2 (en) 2016-02-04 2017-10-17 Nasdaq Technology Ab Systems and methods for storing and sharing transactional data using distributed computing systems

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020205528A1 (de) 2020-04-30 2021-11-04 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Abwickeln einer Transaktion
DE102020205529A1 (de) 2020-04-30 2021-11-04 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge
DE102020207563A1 (de) 2020-06-18 2021-12-23 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Erteilen einer Gutschrift über einen Zahlungskanal
DE102020210000A1 (de) 2020-08-06 2022-02-10 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Bestätigen eines Rechtsgeschäftes
DE102020211936A1 (de) 2020-09-23 2022-03-24 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Betreiben einer verteilten Anwendung
DE102020212330A1 (de) 2020-09-30 2022-03-31 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Betreiben einer dezentralen Anwendung durch Teilnehmer einer Blockkette
US11928104B2 (en) 2020-09-30 2024-03-12 Robert Bosch Gmbh Method and device for operating a decentralized application by users of a blockchain
DE102020213240A1 (de) 2020-10-20 2022-04-21 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Abwickeln einer Transaktion zwischen mehreren Partitionen einer Blockkette
DE102020213245A1 (de) 2020-10-20 2022-04-21 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Erzeugen einer pseudozufälligen Zahlenfolge
US11875345B2 (en) 2020-10-20 2024-01-16 Robert Bosch Gmbh Method and device for conducting a transaction between a plurality of partitions of a blockchain

Also Published As

Publication number Publication date
CN112335201A (zh) 2021-02-05
US20210216949A1 (en) 2021-07-15
WO2019242975A1 (de) 2019-12-26
EP3811563A1 (de) 2021-04-28

Similar Documents

Publication Publication Date Title
DE102018210224A1 (de) Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System
DE102020106368A1 (de) Teilen von fahrzeugdaten mit interessierten parteien
DE112018003781T5 (de) Kontoverwaltungsvorrichtung, kontoverwaltungssystem, und fahrzeuggebundene informationsbereitstellungsvorrichtung
Wedeniwski Mobilitätsrevolution in der Automobilindustrie
DE112013005761B4 (de) System und Verfahren zum Verwenden eines Autoradios zum Steuern der Lieferung von Premiuminhalt an ein Smartphone
DE102008021030A1 (de) Verfahren zum Betreiben eines Fahrzeugs sowie entsprechende Vorrichtung und entsprechendes Fahrzeug
EP3654222B1 (de) Fahrzeug, netzwerkkomponente, verfahren, computerprogramm und vorrichtung zum generieren einer kennung für einen ausrüstungszustand eines fahrzeugs
DE102018212238A1 (de) Kontosystem, anbieter-endgerät, benutzer-endgerät, und knoten
EP3743844B1 (de) Blockchain-basiertes identitätssystem
WO2020164974A1 (de) Verfahren zur überwachung einer funktionalität eines fahrzeuginformationssystems eines kraftfahrzeugs, sowie elektronische recheneinrichtung, computerprogramm und datenträger
EP3966723B1 (de) Verfahren und anordnung zur bereitstellung von daten einer industriellen automatisierungsanordnung zu einer externen anordnung
DE102017000167A1 (de) Anonymisierung einer Blockkette
EP3433789B1 (de) Verfahren zum verwalten von gesammelten fahrzeugdaten
DE102019112654A1 (de) Verfahren und system für distributed-ledger-technologie-kommunikationen für fahrzeuge
EP4144003B1 (de) Verfahren zum erzeugen einer softwarekomponente für eine elektronische recheneinrichtung eines kraftfahrzeugs, computerprogrammprodukt, computerlesbares speichermedium sowie kraftfahrzeugexternes aktualisierungssystem
DE102018216036A1 (de) Verfahren zum Ausführen einer Applikation in einem Fahrzeug, Fahrzeugsystem, Computerprogramm und Datenträgersignal
DE102017011030A1 (de) Verfahren zur Verkehrssteuerung
DE102018200807A1 (de) Verfahren und Servervorrichtung zum Bereitstellen eines digitalen Fahrzeugbegleitbuchs für ein Kraftfahrzeug
EP3225043B1 (de) Verfahren und vorrichtung zur kontrolle zumindest eines datenabrufs von einem steuergerät eines fahrzeugs sowie verfahren und vorrichtung zum abrufen von daten von einem steuergerät eines fahrzeugs
DE102019219667B3 (de) Computerprogrammprodukt für ein Peer-to-Peer Computernetzwerk
DE102013020550A1 (de) Verfahren und Einrichtung zur Datenkommunikation in Fahrzeugen, insbesondere in Kraftfahrzeugen
EP3703333B1 (de) Verfahren, vorrichtung und anlage zur verarbeitung wenigstens einer information in einer sicherheitstechnischen anlage
DE102017217057A1 (de) Verfahren und Vorrichtung zum Aufbau eines Kommunikationskanals zwischen einer ersten und einer zweiten Einrichtung
DE102022000818A1 (de) Verfahren zur Zuweisung eines Fahrzeugs an einen Kunden, sowie Verwaltungssystem
DE102019207349A1 (de) Verfahren zum Verarbeiten von Daten für ein zumindest teilautomatisiertes Führen eines Kraftfahrzeugs