EP3811563A1 - 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

Info

Publication number
EP3811563A1
EP3811563A1 EP19729451.5A EP19729451A EP3811563A1 EP 3811563 A1 EP3811563 A1 EP 3811563A1 EP 19729451 A EP19729451 A EP 19729451A EP 3811563 A1 EP3811563 A1 EP 3811563A1
Authority
EP
European Patent Office
Prior art keywords
transaction database
guarantees
assumptions
systems
security contract
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
EP19729451.5A
Other languages
English (en)
French (fr)
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
Publication of EP3811563A1 publication Critical patent/EP3811563A1/de
Pending legal-status Critical Current

Links

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]

Definitions

  • the present invention relates to a method for agreeing a
  • the present invention also relates to a corresponding device, a corresponding computer program and a corresponding one
  • any protocol in computer networks is referred to as one
  • a computer system that is connected to a blockchain is disclosed, for example, in US 9,794,074 B2.
  • the computer system receives
  • Match data for a match between a first data transaction associated with a first identifier and a second data transaction associated with a second identifier is generated based on the data stored in the blockchain. At least one further blockchain transaction is generated, which divides the match into two different transactions: one between the first identifier and an intermediary and the second between the intermediary. These are recorded in the blockchain via the other blockchain transactions.
  • the invention provides a method for agreeing a cooperation between a first system and a second system, a corresponding device, a corresponding computer program and a corresponding storage medium according to the independent claims.
  • the method according to the invention is based on the knowledge that more and more safety-critical systems have to work together in operation. These systems are sometimes developed by various manufacturers. Therefore, they have to cooperate with other systems, their behavior and
  • the proposed approach also takes into account the fact that there is generally a risk of system failure. If a system fails, it can violate its guarantees and if it works with other systems at the time of the failure, it breaks itss
  • Claim the basic idea specified.
  • the participating systems repeatedly send an environment model to the transaction database after the cooperation has been started, and the latter adds the environment models to the block chain. In the event of an error, this data cannot be denied and help to reconstruct the situation. If one of the participating systems fails, this will make it easier for the manufacturer to prove that a security contract not only existed, but also that another system has violated it.
  • the participating systems repeatedly send a scatter value (hash) of the environment model to the transaction database after the cooperation has been started, and the latter only adds these scatter values to the block chain.
  • the hash of the environment model is much smaller in size than the entire model and can therefore be sent to the transaction database much faster.
  • the manufacturer can demonstrate that the in the
  • the systems establish a reciprocal transaction channel, via which they exchange information and signed messages after receiving the block with the security contract. This concept reduces the amount of communication with the transaction database, thereby
  • the block chain of the transaction database is distributed over numerous terminal devices and that on
  • EoT enables participating systems to pay or be paid for the services purchased in this way, if they themselves provide a service for other systems - for example in the case of a vehicle in front that helps the vehicle behind it, the possibility of an overtaking maneuver beyond one in front To estimate the curve.
  • Figure 1 shows a method according to which two systems agree a legally compliant cooperation by means of a block chain.
  • Figure 2 shows a variant of the method in which the transaction database is equipped with computing functions and is thus able to set up the security contract.
  • FIG 3 shows a variant of the method in which the systems one
  • FIG. 4 schematically shows a control device according to the invention.
  • Figure 1 shows the time axes of two systems (1 1, 12) from different manufacturers of a distributed transaction database (13).
  • the systems (1 1, 12) communicate with the distributed one via an Internet connection
  • each data record (18, 19) can contain the identifier (ID) of the "opposite side" (12 or 11).
  • This ID should be unique in the distributed transaction database (13) and is comparable to the so-called wallet ID of a cryptocurrency.
  • each system (11, 12) can check (22, 23) whether the each other party (12 or 11) has created a matching data record (19 or 18). If not
  • Monitoring component determines a violation (25) of the security contract, it ends the cooperation (26) and tries to put the system (11) in a safe state. This may not be possible in individual cases since complex guarantees cannot even be monitored. In any case, both manufacturers have access to the security contract, which they both
  • a first variant of the method (10) addresses the problem that, if the participating systems (11, 12) fail, their manufacturers do
  • the security contract contains a clause according to which both systems (11, 12) periodically send a representation of their system status including their environment model (camera image, position on the map, etc.) as defined in the security contract distributed transaction database (13) must send.
  • a second variant is similar to the first, but each system (11, 12) creates a cryptographic hash of its entire environment model and stores the model and the hash in a local database.
  • a third variant (30 - Figure 2) uses the possibility of some distributed
  • a fourth variant (40) shown in FIG. 3 extends the third variant as follows: Blockchains such as “Lightning” and “Raiden” have introduced a concept referred to as a transaction or state channel. On
  • Status channel is a direct communication channel between the
  • the systems (11, 12) exchange information directly via this channel.
  • the receiver system (11, 12) acknowledges the information received (42, 44, 46) with a cryptographically signed message (43, 45) when it agrees to the received message. If both systems (11, 12) want to end the collaboration or one of the
  • a fifth variant of the method (10) therefore provides that the participating systems are equipped with mechanisms, for example to carry out transactions by means of digital wallets in order to store units of a virtual currency as a unit of value for the collaboration.
  • the inclusion of the trustworthiness of a system assessed by previous collaboration partners can restrict the selection of the partner for later collaboration.
  • a virtual crypto wallet can also save the said trustworthiness. This would, for example, allow a product to be used in certain
  • the security contracts can be sent from the systems instead of the blockchain to a central server or a database that the system manufacturers trust.
  • This method can be implemented, for example, in software or hardware or in a mixed form of software and hardware, for example in a control unit (50), as the schematic illustration in FIG. 4 illustrates.

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

Beschreibung
Titel
Verfahren und Vorrichtung zum Vereinbaren einer Zusammenarbeit zwischen einem ersten System und einem zweiten System
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.
Kurze Beschreibung der Zeichnungen
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
Figur 1 ein Verfahren, gemäß dem zwei Systeme mittels einer Blockkette eine rechtssichere Zusammenarbeit vereinbaren.
Figur 2 eine Variante des Verfahrens, bei welcher die T ransaktionsdatenbank mit Rechenfunktionen ausgestattet und so in der Lage ist, den Sicherheitsvertrag aufzusetzen.
Figur 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
T ransaktionsdatenbank kann überprüft werden, welches System im Recht ist und welches die letzte überstimmende Information war. Figur 4 schematisch ein erfindungsgemäßes Steuergerät.
Ausführungsformen der Erfindung
Figur 1 zeigt die Zeitachsen von zwei Systemen (1 1 , 12) von verschiedenen Herstellern einer verteilten T ransaktionsdatenbank (13). Die Systeme (1 1 , 12) kommunizieren über eine Internetverbindung mit der verteilten
T ransaktionsdatenbank (13); die Kommunikation zwischen den Systemen (1 1 ,
12) erfolgt unmittelbar von Fahrzeug zu Fahrzeug ( car to car, C2C) oder ebenfalls über eine Internetverbindung. Zunächst tauschen beide Systeme (1 1 , 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 (1 1 , 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 (1 1 , 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äß Figur 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 Figur 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 Figur 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 - Figur 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 Figur 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 Figur 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 Figur 4 verdeutlicht.

Claims

Ansprüche
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.
EP19729451.5A 2018-06-22 2019-05-22 Verfahren und vorrichtung zum vereinbaren einer zusammenarbeit zwischen einem ersten system und einem zweiten system Pending EP3811563A1 (de)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP3811563A1 true EP3811563A1 (de) 2021-04-28

Family

ID=66810757

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19729451.5A Pending EP3811563A1 (de) 2018-06-22 2019-05-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)

Families Citing this family (9)

* 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
DE102020213245A1 (de) 2020-10-20 2022-04-21 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Erzeugen einer pseudozufälligen Zahlenfolge
US12079783B2 (en) * 2020-10-20 2024-09-03 Ricoh Company, Ltd. Information processing system, document management device, and recording medium
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

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001167152A (ja) * 1999-12-07 2001-06-22 Aiu Insurance Company 業務処理システム、ホストコンピュータ、及び端末装置
US7991680B2 (en) * 2000-03-06 2011-08-02 Wellogix Technology Licensing, Llc Method and process for providing relevant data, comparing proposal alternatives, and reconciling proposals, invoices, and purchase orders with actual costs in a workflow process
US20020059075A1 (en) * 2000-05-01 2002-05-16 Schick Louis A. Method and system for managing a land-based vehicle
AU2001289112A1 (en) * 2000-09-19 2002-04-02 World E-Commerce Exchange A method and system providing a world e-commerce exchange
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 株式会社三井住友銀行 債券照合・債務引受状況管理方法およびシステム
US9645579B2 (en) * 2011-07-06 2017-05-09 Peloton Technology, Inc. Vehicle platooning systems and methods
WO2013006826A2 (en) * 2011-07-06 2013-01-10 Peloton Technology Inc. Systems and methods for semi-autonomous vehicular convoying
DE102012208256A1 (de) * 2012-05-16 2013-11-21 Continental Teves Ag & Co. Ohg Verfahren und System zum autonomen Nachführen eines Folgefahrzeugs auf der Spur eines Leitfahrzeugs
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
CA2996546A1 (en) * 2015-08-26 2017-03-02 Peloton Technology, Inc. Devices, systems and methods for vehicle monitoring and platooning
CN105719185B (zh) * 2016-01-22 2019-02-15 杭州复杂美科技有限公司 区块链的数据对比及共识方法
US9794074B2 (en) 2016-02-04 2017-10-17 Nasdaq Technology Ab Systems and methods for storing and sharing transactional data using distributed computing systems
CN107424073A (zh) * 2017-07-17 2017-12-01 杭州复杂美科技有限公司 一种跨链数字债权交易的方法
CN108011947B (zh) * 2017-11-30 2020-11-24 湖北汽车工业学院 一种车辆协作式编队行驶系统

Also Published As

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

Similar Documents

Publication Publication Date Title
EP3811563A1 (de) Verfahren und vorrichtung zum vereinbaren einer zusammenarbeit zwischen einem ersten system und einem zweiten system
DE112018003781T5 (de) Kontoverwaltungsvorrichtung, kontoverwaltungssystem, und fahrzeuggebundene informationsbereitstellungsvorrichtung
EP3654222B1 (de) Fahrzeug, netzwerkkomponente, verfahren, computerprogramm und vorrichtung zum generieren einer kennung für einen ausrüstungszustand eines fahrzeugs
EP3743844B1 (de) Blockchain-basiertes identitätssystem
DE102019214461A1 (de) Verfahren zum Fernsteuern eines Kraftfahrzeugs
DE102012205593A1 (de) Verfahren zum Betreiben einer Transportmaschine, Diensterbringungsrechner und Transportmaschine
EP3966723B1 (de) Verfahren und anordnung zur bereitstellung von daten einer industriellen automatisierungsanordnung zu einer externen anordnung
WO2020164974A1 (de) Verfahren zur überwachung einer funktionalität eines fahrzeuginformationssystems eines kraftfahrzeugs, sowie elektronische recheneinrichtung, computerprogramm und datenträger
EP3483033A1 (de) Verfahren und onboard-steuereinheit zum steuern und/oder überwachen von komponenten eines schienenfahrzeugs
DE102018202626A1 (de) Verfahren zur rechnergestützten Parametrierung eines technischen Systems
DE102017000167A1 (de) Anonymisierung einer Blockkette
EP3703333B1 (de) Verfahren, vorrichtung und anlage zur verarbeitung wenigstens einer information in einer sicherheitstechnischen anlage
EP3433789B1 (de) Verfahren zum verwalten von gesammelten fahrzeugdaten
DE102017217057A1 (de) Verfahren und Vorrichtung zum Aufbau eines Kommunikationskanals zwischen einer ersten und einer zweiten Einrichtung
DE102017011030A1 (de) Verfahren zur Verkehrssteuerung
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
Böttger et al. Challenges and current solutions for safe and secure connected vehicles
DE102019207349A1 (de) Verfahren zum Verarbeiten von Daten für ein zumindest teilautomatisiertes Führen eines Kraftfahrzeugs
DE102018200807A1 (de) Verfahren und Servervorrichtung zum Bereitstellen eines digitalen Fahrzeugbegleitbuchs für ein Kraftfahrzeug
DE102022000818A1 (de) Verfahren zur Zuweisung eines Fahrzeugs an einen Kunden, sowie Verwaltungssystem
WO2007009838A1 (de) Datenübertragungsverfahren und datenübertragungssystem
EP4273725A1 (de) Verfahren zur ermittlung von kritischen schwachstellenketten
WO2022179837A1 (de) Verfahren, computerprogramm, computerlesbares speichermedium und system zum bereitstellen von zu schützenden informationen eines personenbeförderungsfahrzeuges
EP4250146A1 (de) Interaktion physischer entitäten

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210122

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20240125