DE112020005794T5 - Dynamische rechtevergabe und durchsetzung für transportprozess - Google Patents

Dynamische rechtevergabe und durchsetzung für transportprozess Download PDF

Info

Publication number
DE112020005794T5
DE112020005794T5 DE112020005794.1T DE112020005794T DE112020005794T5 DE 112020005794 T5 DE112020005794 T5 DE 112020005794T5 DE 112020005794 T DE112020005794 T DE 112020005794T DE 112020005794 T5 DE112020005794 T5 DE 112020005794T5
Authority
DE
Germany
Prior art keywords
blockchain
data
read
party
transport process
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
DE112020005794.1T
Other languages
English (en)
Inventor
Ana Claudia Biazetti
Craig Andrew Lanzen
Dillon Dierker Lees
Aaron LIEBER
Nis David Nørmark Jespersen
Thiego Rodrigues
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.)
Gtd Solution Inc
International Business Machines Corp
GTD Solution Inc
Original Assignee
Gtd Solution Inc
International Business Machines Corp
GTD Solution Inc
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 Gtd Solution Inc, International Business Machines Corp, GTD Solution Inc filed Critical Gtd Solution Inc
Publication of DE112020005794T5 publication Critical patent/DE112020005794T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2308Concurrency control
    • G06F16/2315Optimistic concurrency control
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083Shipping
    • G06Q10/0835Relationships between shipper or supplier and carriers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083Shipping
    • G06Q10/0838Historical data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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/3239Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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 involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3297Cryptographic 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 involving time stamps, e.g. generation of time stamps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Development Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

Ein beispielhafter Vorgang kann eines oder mehrere von dem Empfangen von Transportdaten eines Transportprozesses mit mehreren Parteien, dem Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten, dem dynamischen Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen, und dem Speichern einer Kennung des Transportprozesses mit mehreren Parteien und dem dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain einschließen.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Anmeldung betrifft im Allgemeinen das Ablegen von Daten in einer Blockchain und genauer gesagt in einem System, das die Berechtigungen von Parteien in einem Transportprozess mit mehreren Parteien basierend auf Rollen dynamisch bestimmt und den Zugriff auf Transportdaten basierend auf den Berechtigungen verwaltet.
  • HINTERGRUND
  • Eine zentrale Datenbank speichert und pflegt Daten in einer einzelnen Datenbank (z. B. einem Datenbankserver) an einem einzigen Standort. Dieser Standort ist häufig ein zentraler Computer, beispielsweise eine Bürozentraleinheit (CPU), eine Server-CPU oder ein Großrechner. Informationen, die in einer zentralen Datenbank abgelegt sind, sind typischerweise von mehreren verschiedenen Stellen aus zugänglich. Mehrere Benutzer oder Client-Arbeitsstationen können gleichzeitig an der zentralen Datenbank beispielsweise basierend auf einer Client/Server-Konfiguration arbeiten. Eine zentrale Datenbank ist auf Grund ihres einzelnen Standorts, insbesondere zu Sicherheitszwecken, einfach zu verwalten, zu pflegen und zu kontrollieren. In einer zentralen Datenbank wird die Datenredundanz minimiert, weil ein gegebener Datensatz nur einen primären Eintrag aufweist.
  • Eine zentrale Datenbank leidet jedoch unter erheblichen Nachteilen. Beispielsweise weist eine zentrale Datenbank eine einzelne Schwachstelle auf, falls es keine Fehlertoleranzüberlegungen gibt. Falls es daher zu einem Materialausfall (beispielsweise zu einem Hardware-, Firmware- und/oder Software-Ausfall) kommt, sind alle Daten in der Datenbank verloren und die Arbeit aller Benutzer wird unterbrochen. Zudem sind zentrale Datenbanken höchst abhängig von der Netzwerkkonnektivität. Dadurch erhöht sich, je langsamer die Verbindung ist, die für jeden Datenbankzugriff benötigte Zeit. Ein anderer Nachteil ist das Vorkommen von Engpässen, wenn eine zentrale Datenbank auf Grund eines einzelnen Standorts ein hohes Verkehrsaufkommen erfährt. Außerdem stellt eine zentrale Datenbank einen begrenzten Zugriff auf Daten bereit, weil nur eine Kopie der Daten von der Datenbank gepflegt wird.
  • Neuerdings interessieren sich Organisationen für eine Blockchain als Mittel zum sicheren Speichern von Daten, die nicht durch eine zentrale Entität eingeschränkt sind und die von mehreren Stellen aus zugängig sind. In einem Blockchain-Netzwerk sind Peers für das gemeinsame Verwalten und Speichern von Daten in der Blockchain verantwortlich. Die Blockchain kann in einem Hauptbuch abgelegt sein, das unter den Blockchain-Peers verteilt/kopiert wird. Eine Blockchain stellt neue Mechanismen zur Sicherung der Interaktionen von nicht vertrauenswürdigen Parteien durch die Verwendung einer dezentralen Architektur bereit.
  • Dabei trägt das Versand-/Transport-Ökosystem enorm zur globalen Wirtschaft bei. Beispielsweise seit der Umstellung auf Container ist die Transportindustrie in einem erstaunlichen Maß gewachsen und umfasst Schiffe/Lastschiffe, Lastwagen, Züge, Flugzeuge und beliebige andere Mittel zum Bewegen von Fracht von einem geografischen Standort zum anderen. Wie die meisten derart großen Dinge hat die Industrie jedoch erhebliche Leistungsschwächen und Komplexitäten entwickelt. Beispielsweise können Kommunikationen zwischen den Parteien schwierig sein, da viele Parteien nicht direkt miteinander zu tun haben. Zudem haben die Parteien unterschiedliche Prioritäten bei den meisten Transaktionen, was zu gegensätzlichen Zielen/Ansichten führt. Der Transportprozess unterliegt auch Betrug und Zeit-/ Ressourcenverschwendung, insbesondere da man als Nachweis immer noch auf papierbasierte Dokumente zurückgreift. Benötigt wird somit eine Lösung, die diese Nachteile und Einschränkungen behebt.
  • KURZDARSTELLUNG
  • Ein Ausführungsbeispiel stellt ein Gerät bereit, das eines oder mehrere von einer Netzwerkschnittstelle, die konfiguriert ist, um Transportdaten eines Transportprozesses mit mehreren Parteien zu empfangen, und einem Prozessor, der für eines oder mehrere konfiguriert ist von Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten, von dynamischem Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen, und von Speichern einer Kennung des Transportprozesses mit mehreren Parteien und der dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain, umfasst.
  • Ein anderes Ausführungsbeispiel stellt ein Verfahren bereit, das eines oder mehrere von Empfangen von Transportdaten eines Transportprozesses mit mehreren Parteien, von Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten, von dynamischem Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen, und von Speichern einer Kennung des Transportprozesses mit mehreren Parteien und der dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain einschließt.
  • Ein weiteres Ausführungsbeispiel stellt ein nicht vorübergehendes computerlesbares Medium bereit, das Anweisungen umfasst, die bewirken, wenn sie von einem Prozessor gelesen werden, dass der Prozessor eines oder mehrere ausführt von Empfangen von Transportdaten eines Transportprozesses mit mehreren Parteien, von Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten, von dynamischem Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen, und von Speichern einer Kennung des Transportprozesses mit mehreren Parteien und der dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain.
  • Aus Sicht eines ersten Aspekts stellt die vorliegende Erfindung ein Gerät bereit, das umfasst: eine Netzwerkschnittstelle, die konfiguriert ist, um Transportdaten eines Transportprozesses mit mehreren Parteien zu empfangen; und einen Prozessor, der konfiguriert ist, um Dokumente und Ereignisse, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten zu identifizieren, um Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen dynamisch zu bestimmen, und um eine Kennung des Transportprozesses mit mehreren Parteien und die dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain abzulegen.
  • Bevorzugt stellt die vorliegende Erfindung ein Gerät bereit, bei dem der Prozessor konfiguriert ist, um Berechtigungen zum Lesen und Schreiben von Daten in der Blockchain für eine Vielzahl von Parteien, die zu dem Transportprozess mit mehreren Parteien gehören, basierend auf vordefinierten Rollen, die den Parteien durch den Kettencode der Blockchain zugeordnet sind, abzuleiten.
  • Bevorzugt stellt die vorliegende Erfindung ein Gerät bereit, bei dem der Prozessor ferner konfiguriert ist, um eine Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, zu empfangen und die Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, zu gewähren.
  • Bevorzugt stellt die vorliegende Erfindung ein Gerät bereit, bei dem der Prozessor ferner konfiguriert ist, um eine Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, zu empfangen und die Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, zu verweigern.
  • Bevorzugt stellt die vorliegende Erfindung ein Gerät bereit, bei dem der Prozessor die Lese- und Schreib-Berechtigungen basierend auf einem Ursprung, einem Ziel und einem oder mehreren Zwischenstandorten des Transportprozesses mit mehreren Parteien bestimmt.
  • Bevorzugt stellt die vorliegende Erfindung ein Gerät bereit, bei dem die Netzwerkschnittstelle ferner konfiguriert ist, um eine Aktualisierung von Ereignisdaten des Prozesses mit mehreren Parteien zu empfangen und um die Aktualisierung von Ereignisdaten und Lese- und Schreib-Berechtigungen für die Aktualisierung von Ereignisdaten in einem Block in der Blockchain abzulegen.
  • Bevorzugt stellt die vorliegende Erfindung ein Gerät bereit, bei dem die Aktualisierung von Ereignisdaten eine Änderung an einem zuvor abgelegten Dokument umfasst.
  • Bevorzugt stellt die vorliegende Erfindung ein Gerät bereit, bei dem die Aktualisierung von Ereignisdaten eine Änderung an zuvor bestimmten Lese- und Schreib-Berechtigungen für ein Ereignis und seine Daten umfasst.
  • Aus Sicht einer anderen Perspektive stellt die vorliegende Erfindung ein Verfahren bereit, das umfasst: Empfangen von Transportdaten eines Transportprozesses mit mehreren Parteien; Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten; dynamisches Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen; und Speichern einer Kennung des Transportprozesses mit mehreren Parteien und der dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain.
  • Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, bei dem das dynamische Bestimmen das Ableiten von Berechtigungen zum Lesen und Schreiben von Daten in die Blockchain für eine Vielzahl von Parteien, die zu dem Transportprozess mit mehreren Parteien gehören, basierend auf vordefinierten Rollen, die den Parteien durch den Kettencode der Blockchain zugeordnet sind, umfasst.
  • Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, das ferner das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Gewähren der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, umfasst.
  • Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, das ferner das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Verweigern der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, umfasst.
  • Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, bei dem das dynamische Bestimmen der Lese- und Schreib-Berechtigungen ferner basierend auf einem Ursprung, einem Ziel und einem oder mehreren Zwischenstandorten des Transportprozesses mit mehreren Parteien bestimmt wird.
  • Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, das ferner das Empfangen einer Aktualisierung von Ereignisdaten des Prozesses mit mehreren Parteien, und das Ablegen der Aktualisierung von Ereignisdaten und Lese- und Schreib-Berechtigungen für die Aktualisierung von Ereignisdaten in einem Block in der Blockchain umfasst.
  • Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, bei dem die Aktualisierung von Ereignisdaten eine Änderung an einem zuvor abgelegten Dokument umfasst.
  • Bevorzugt stellt die vorliegende Erfindung ein Verfahren bereit, bei dem die Aktualisierung von Ereignisdaten eine Änderung an zuvor bestimmten Lese- und Schreib-Berechtigungen für ein Ereignis und seine Daten umfasst.
  • Aus Sicht eines anderen Aspekts stellt die vorliegende Erfindung ein nicht vorübergehendes computerlesbares Medium bereit, das Anweisungen umfasst, die bewirken, wenn sie von einem Prozessor gelesen werden, dass der Prozessor ein Verfahren ausführt, umfassend: Empfangen von Transportdaten eines Transportprozesses mit mehreren Parteien; Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten; dynamisches Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen; und Speichern einer Kennung des Transportprozesses mit mehreren Parteien und der dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain.
  • Bevorzugt stellt die vorliegende Erfindung ein nicht vorübergehendes computerlesbares Medium bereit, bei dem das dynamische Bestimmen das Ableiten von Berechtigungen zum Lesen und Schreiben von Daten in die Blockchain für eine Vielzahl von Parteien, die zu dem Transportprozess mit mehreren Parteien gehören, basierend auf vordefinierten Rollen, die den Parteien durch den Kettencode der Blockchain zugeordnet sind, umfasst.
  • Bevorzugt stellt die vorliegende Erfindung ein nicht vorübergehendes computerlesbares Medium bereit, bei dem das Verfahren ferner das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Gewähren der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, umfasst.
  • Bevorzugt stellt die vorliegende Erfindung ein nicht vorübergehendes computerlesbares Medium bereit, bei dem das Verfahren ferner das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Verweigern der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, umfasst.
  • Figurenliste
    • 1 ist ein Diagramm, das ein Handelsökosystem zur Verwaltung des Transports von Fracht und seine dazugehörigen Meilensteine (Ereignisse und Dokumente) gemäß Ausführungsbeispielen abbildet.
    • 2A ist ein Diagramm, das eine Blockchain-Architekturkonfiguration gemäß Ausführungsbeispielen abbildet.
    • 2B ist ein Diagramm, das einen Blockchain-Transaktionsfluss gemäß Ausführungsbeispielen abbildet.
    • 3A ist ein Diagramm, das ein berechtigtes Blockchain-Netzwerk gemäß Ausführungsbeispielen abbildet.
    • 3B ist ein Diagramm, das ein anderes berechtigtes Blockchain-Netzwerk gemäß Ausführungsbeispielen abbildet.
    • 3C ist ein Diagramm, das ein berechtigungsloses Blockchain-Netzwerk gemäß Ausführungsbeispielen abbildet.
    • 4A ist ein Diagramm, das Dienste einer Host-Plattform zum Zuteilen von Berechtigungen und zum Kontrollieren von Zugriff gemäß Ausführungsbeispielen abbildet.
    • 4B ist ein Diagramm, das eine Zuordnung zwischen Teilnehmerarten und Teilnehmerrollen gemäß Ausführungsbeispielen abbildet.
    • 4C ist ein Diagramm, das eine Tabelle, die Zugriffsberechtigungen auf Dokumente basierend auf Rollen speichert, gemäß Ausführungsbeispielen abbildet.
    • 4D ist ein Diagramm, das einen Prozess zum dynamischen Bestimmen von Lese- und Schreib-Berechtigungen für Dokumente und Ereignisse gemäß Ausführungsbeispielen abbildet.
    • 5 ist ein Diagramm, das ein Verfahren zum dynamischen Bestimmen von Lese- und Schreib-Berechtigungen gemäß Ausführungsbeispielen abbildet.
    • 6A ist ein Diagramm, das ein beispielhaftes System, das konfiguriert ist, um einen oder mehrere hier beschriebene Vorgänge auszuführen, gemäß Ausführungsbeispielen abbildet.
    • 6B ist ein Diagramm, das ein anderes beispielhaftes System, das konfiguriert ist, um einen oder mehrere hier beschriebene Vorgänge auszuführen, gemäß Ausführungsbeispielen abbildet.
    • 6C ist ein Diagramm, das ein weiteres beispielhaftes System, das konfiguriert ist, um einen intelligenten Vertrag zu verwenden, gemäß Ausführungsbeispielen abbildet.
    • 6D ist ein Diagramm, das noch ein anderes beispielhaftes System, das konfiguriert ist, um eine Blockchain zu verwenden, gemäß Ausführungsbeispielen abbildet.
    • 7A ist ein Diagramm, das einen Prozess zum Hinzufügen eines neuen Blocks zu einem verteilten Hauptbuch gemäß Ausführungsbeispielen abbildet.
    • 7B ist ein Diagramm, das den Inhalt eines neuen Datenblocks gemäß Ausführungsbeispielen abbildet.
    • 7C ist ein Diagramm, das eine Blockchain für digitalen Inhalt gemäß Ausführungsbeispielen abbildet.
    • 7D ist ein Diagramm, das einen Block, der die Struktur von Blöcken in der Blockchain darstellen kann, gemäß Ausführungsbeispielen abbildet.
    • 8A ist ein Diagramm, das eine beispielhafte Blockchain, die Daten zum maschinellen Lernen (künstliche Intelligenz) speichert, gemäß Ausführungsbeispielen abbildet.
    • 8B ist ein Diagramm, das eine beispielhafte quantensichere Blockchain gemäß Ausführungsbeispielen abbildet.
    • 9 ist ein Diagramm, das ein beispielhaftes System, das ein oder mehrere der Ausführungsbeispiele unterstützt, abbildet.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Es versteht sich ohne Weiteres, dass die Komponenten, wie sie hier allgemein beschrieben und in den Figuren abgebildet sind, in vielen verschiedenen Konfigurationen angeordnet und ausgelegt sein können. Somit ist die folgende ausführliche Beschreibung der Ausführungsformen von mindestens einem von einem Verfahren, einem Gerät, einem nicht vorübergehenden computerlesbaren Medium und System, wie in den beiliegenden Figuren dargestellt, nicht dazu gedacht, den Umfang der beanspruchten Anmeldung einzuschränken, sondern nur ausgewählte Ausführungsformen darzustellen.
  • Die vorliegenden Merkmale, Strukturen oder Kennzeichen, wie sie in der gesamten Beschreibung beschrieben werden, können beliebig in einer oder mehreren Ausführungsformen kombiniert oder getrennt werden. Beispielsweise bezieht sich die Verwendung der Ausdrücke „Ausführungsbeispiele“, „gewisse Ausführungsformen“ oder eine andere ähnliche Ausdrucksweise in der gesamten Beschreibung auf die Tatsache, dass ein bestimmtes Merkmal, eine Struktur oder ein Kennzeichen, das bzw. die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform eingeschlossen sein kann. Somit bezieht sich das Vorkommen der Ausdrücke „Ausführungsbeispiele“, „in einigen Ausführungsformen“, „in anderen Ausführungsformen“ oder eine andere ähnliche Ausdrucksweise in der gesamten Beschreibung nicht unbedingt immer auf die gleiche Gruppe von Ausführungsformen, und die beschriebenen Merkmale, Strukturen oder Kennzeichen können beliebig in einer oder mehreren Ausführungsformen kombiniert oder getrennt werden. Ferner kann in den Diagrammen eine beliebige Verbindung zwischen Elementen eine einseitige und/oder zweiseitige Kommunikation erlauben, selbst wenn die dargestellte Verbindung ein einseitiger oder zweiseitiger Pfeil ist. Ebenso kann eine beliebige Vorrichtung, die in den Zeichnungen dargestellt ist, eine andere Vorrichtung sein. Falls beispielsweise eine mobile Vorrichtung als Informationen sendend gezeigt wird, könnte auch eine drahtgebundene Vorrichtung verwendet werden, um die Informationen zu senden.
  • Obwohl vielleicht zudem der Begriff „Nachricht“ in der Beschreibung der Ausführungsformen verwendet wurde, kann die Anmeldung auf viele Arten von Netzwerken und Daten angewendet werden. Obwohl vielleicht außerdem gewisse Arten von Verbindungen, Nachrichten und Signalgebung bei Ausführungsbeispielen dargestellt sind, ist die Anmeldung nicht auf eine gewisse Art von Verbindung, Nachricht und Signalgebung eingeschränkt.
  • Die Ausführungsbeispiele stellen Verfahren, Systeme, Komponenten, nicht vorübergehende computerlesbare Medien, Vorrichtungen und/oder Netzwerke für das dynamische Bestimmen von Lese- und Schreib-Berechtigungen für Daten eines Transportprozesses mit mehreren Parteien und das Kontrollieren des Zugriffs auf die Daten basierend auf dynamisch bestimmten Berechtigungen über die Blockchain bereit.
  • Bei einer Ausführungsform verwendet die Anmeldung eine dezentrale Datenbank (wie etwa eine Blockchain), die ein verteiltes Ablagesystem ist, das mehrere Knoten einschließt, die miteinander kommunizieren. Die dezentrale Datenbank schließt eine unveränderliche Nur-Anhänge-Datenstruktur ein, die einem verteilten Hauptbuch ähnelt, das Einträge zwischen gegenseitig nicht vertrauenswürdigen Parteien pflegen kann. Die nicht vertrauenswürdigen Parteien werden hier als Peers oder Peer-Knoten bezeichnet. Jeder Peer pflegt eine Kopie der Datenbankeinträge, und kein einzelner Peer kann die Datenbankeinträge ändern, ohne dass ein Konsens zwischen den verteilten Peers erreicht wird. Beispielsweise können die Peers ein Konsensprotokoll ausführen, um Blockchain-Ablagetransaktionen zu validieren, die Ablagetransaktionen zu Blöcken zusammenzufassen und eine Hash-Kette über die Blöcke aufzubauen. Dieser Prozess bildet das Hauptbuch, indem die Ablagetransaktionen je nach Bedarf für Konsistenz geordnet werden. Bei diversen Ausführungsformen kann eine berechtigte und/oder eine berechtigungslose Blockchain verwendet werden. In einer öffentlichen bzw. berechtigungslosen Blockchain kann jedermann ohne spezifische Identität teilnehmen. Öffentliche Blockchains können eine native Kryptowährung bedingen und einen Konsens basierend auf diversen Protokollen, wie etwa Arbeitsnachweis (PoW), verwenden. Andererseits stellt eine berechtigte Blockchain-Datenbank gesicherte Interaktionen in einer Gruppe von Entitäten bereit, die ein gemeinsames Ziel haben, die jedoch einander nicht ganz vertrauen, wie etwa Geschäfte, die Gelder, Güter, Informationen und dergleichen austauschen.
  • Die vorliegende Anmeldung kann eine Blockchain verwenden, die eine willkürliche, programmierbare Logik betreibt, die auf ein dezentrales Ablageschema zugeschnitten ist und als „intelligente Verträge“ oder „Kettencodes“ bezeichnet wird. In manchen Fällen können spezialisierte Kettencodes für Verwaltungsfunktionen und Parameter existieren, die als Systemkettencode bezeichnet werden. Die Anmeldung kann ferner intelligente Verträge, die vertrauenswürdige verteilte Anwendungen sind, die manipulationssichere Eigenschaften der Blockchain-Datenbank nutzen, und eine zugrundeliegende Vereinbarung zwischen den Knoten, die als Indossament oder Indossamentrichtlinie bezeichnet wird, verwenden. Blockchain-Transaktionen, die mit dieser Anwendung verknüpft sind, können „indossiert“ werden, bevor sie in der Blockchain festgeschrieben werden, während Transaktionen, die nicht indossiert sind, ignoriert werden. Eine Indossamentrichtlinie erlaubt es dem Kettencode, Indossanten für eine Transaktion in Form eines Satzes von Peer-Knoten, die für das Indossament notwendig sind, vorzugeben. Wenn ein Client die Transaktion an die Peers sendet, die in der Indossamentrichtlinie vorgegeben sind, wird die Transaktion ausgeführt, um die Transaktion zu validieren. Nach der Validierung treten die Transaktionen in eine Ordnungsphase ein, in der ein Konsensprotokoll verwendet wird, um eine geordnete Sequenz von indossierten Transaktionen, die zu Blöcken zusammengefasst sind, zu ergeben.
  • Diese Anwendung kann Knoten verwenden, welche die Kommunikationsentitäten des Blockchain-Systems sind. Ein „Knoten“ kann in dem Sinne eine logische Funktion ausführen, dass mehrere Knoten unterschiedlicher Art auf dem gleichen räumlichen Server laufen können. Die Knoten sind zu Vertrauensdomänen zusammengefasst und sind mit logischen Entitäten verknüpft, die sie auf unterschiedliche Art und Weise kontrollieren. Die Knoten können verschiedene Arten umfassen, wie etwa einen Client- oder Einreichungs-Client-Knoten, der einen Transaktionsaufruf an einen Indossanten (z. B. einen Peer) einreicht, und Transaktionsvorschläge an einen Ordnungsdienst (z. B. Ordnungsknoten) rundsendet. Ein andersartiger Knoten ist ein Peer-Knoten, der von einem Client eingereichte Transaktionen empfangen, die Transaktionen festschreiben und einen Zustand und eine Kopie des Hauptbuchs der Blockchain-Transaktionen pflegen kann. Die Peers können auch die Rolle eines Indossanten haben, obwohl dies nicht notwendig ist. Ein Ordnungsdienstknoten bzw. eine Ordnungsvorrichtung ist ein Knoten, der den Kommunikationsdienst für alle Knoten ausführt, und der eine Liefergarantie umsetzt, wie etwa eine Rundsendung an jeden der Peer-Knoten in dem System, wenn Transaktionen festgeschrieben werden und ein Weltzustand der Blockchain geändert wird, was ein anderer Name für die anfängliche Blockchain-Transaktion ist, die normalerweise Kontroll- und Einrichtungsinformationen einschließt.
  • Diese Anwendung kann ein Hauptbuch verwenden, das ein sequenzierter, manipulationssicherer Eintrag aller Zustandsübergänge einer Blockchain ist. Die Zustandsübergänge können sich aus Kettencodeaufrufen (d. h. Transaktionen) ergeben, die von teilnehmenden Parteien (z. B. Client-Knoten, Ordnungsknoten, Indossantenknoten, Peer-Knoten usw.) eingereicht werden. Jede teilnehmende Partei (wie etwa ein Peer-Knoten) kann eine Kopie des Hauptbuchs pflegen. Eine Transaktion kann dazu führen, dass ein Satz von Anlagen-Schlüssel/Werte-Paaren in das Hauptbuch als ein oder mehrere Operanden, wie etwa Erstellungen, Aktualisierungen, Löschungen und dergleichen, festgeschrieben wird. Das Hauptbuch schließt eine Blockchain (auch als Kette bezeichnet) ein, die verwendet wird, um einen unveränderlichen, sequenzierten Eintrag in Blöcken abzulegen. Das Hauptbuch schließt auch eine Zustandsdatenbank ein, die einen aktuellen Zustand der Blockchain pflegt.
  • Diese Anwendung kann eine Kette verwenden, die ein Transaktionslogbuch ist, das als Hash-verlinkte Blöcke strukturiert ist, und jeder Block enthält eine Sequenz von N Transaktionen, wobei N gleich oder größer als eins ist. Die Blockkopfzeile umfasst einen Hash der Transaktionen des Blocks sowie einen Hash der Kopfzeile des vorherigen Blocks. Auf diese Art und Weise können alle Transaktionen im Hauptbuch sequenziert und kryptografisch verlinkt werden. Entsprechend ist es nicht möglich, die Hauptbuchdaten zu manipulieren, ohne die Hash-Links zu unterbrechen. Ein Hash eines zuletzt hinzugefügten Blockchain-Blocks stellt jede Transaktion in der Kette dar, die davor vorgekommen ist, wodurch sichergestellt werden kann, dass sich alle Peer-Knoten in einem konsistenten und vertrauenswürdigen Zustand befinden. Die Kette kann in einem Peer-Knotendateisystem (d. h. lokal, angehängte Ablage, Cloud usw.), welche die Nur-Anhänge-Beschaffenheit der Blockchain-Arbeitslast effizient unterstützt, abgelegt werden.
  • Der aktuelle Zustand des unveränderlichen Hauptbuchs stellt die neuesten Werte für alle Schlüssel dar, die in dem Kettentransaktionslogbuch enthalten sind. Da der aktuelle Zustand die neuesten Schlüsselwerte darstellt, die einem Kanal bekannt sind, wird er manchmal als Weltzustand bezeichnet. Die Kettencodeaufrufe führen Transaktionen gegenüber den aktuellen Zustandsdaten des Hauptbuchs aus. Um diese Kettencodeinteraktionen effizient zu gestalten, können die neuesten Werte der Schlüssel in einer Zustandsdatenbank abgelegt werden. Die Zustandsdatenbank kann einfach ein indexierter Blick in das Transaktionslogbuch der Kette sein, und kann daher jederzeit aus der Kette regeneriert werden. Die Zustandsdatenbank kann beim Hochfahren des Peer-Knotens, und bevor die Transaktionen angenommen werden, automatisch wiederhergestellt (oder bei Bedarf generiert) werden.
  • Das globale Handelsökosystem trägt massiv zur Weltwirtschaft bei. Beispielsweise ist die Seeschifffahrt eines der kritischsten Frachthandelsmittel. Seit der Umstellung auf Container in den ’60er Jahren ist das Handelsökosystem in einem erstaunlichen Maß gewachsen, doch wie die meisten großformatigen Dinge hat das Handelsökosystem Leistungsschwächen und Komplexitäten entwickelt. Diese Leistungsschwächen ergeben sich aus dem Versuch, Punkt-zu-Punkt-Verbindungen zwischen allen verschiedenen betreffenden Parteien herzustellen, aus Daten, die in Speicherplätzen festliegen können, aus widersprüchlichen Ansichten über Transaktionen und aus Prozessen, die Betrug und Zeitverlust unterliegen. Wobei schon immer die Belastung durch papierbasierte Prozesse, die Innovation und Geschwindigkeit unterdrücken, zugrundelag.
  • Es gibt zwei vorherrschende Datenarten, die mit der Verwaltung des Welthandels zusammenhängen, wozu Versandmeilensteine (hier als Ereignisse bezeichnet) und Handelsunterlagen gehören. Die Meilensteine können diverse Schritte der Reise eines Containers einschließen, beispielsweise das angenommene Ankunftsdatum, das bestimmt wird, noch bevor der Container losfährt, den Zeitpunkt, zu dem der Container an einer Ursprungsstelle versiegelt wird, eine Lufttemperatur, welcher der Container an diversen Stellen der Reise ausgesetzt wird, und dergleichen. Diese Beispiele sind nur einige der vielen Meilensteine, die für das Versorgungskettenökosystem so kritisch sind, um eine Sendung zu planen und durchzuführen. Ebenso kritisch sind die Dokumente, die eine Sendung offiziell definieren und autorisieren. Die Dokumente schließen Packlisten- und Frachtbrief-Dokumente sowie diverse Dokumente ein, die je nach Region oder Handelsroute variieren. Diese Unterlagen spielen eine zentrale Rolle für die Versorgungskette.
  • Die Seeschifffahrt (sowie andere Transportformen) ist wettbewerbsintensiv und stark reguliert. Es ist unbedingt erforderlich, dass Frachtführer darauf vertrauen, dass die Teilnahme an einer Plattform sie nicht wettbewerblichen oder regeltechnischen Risiken aussetzt. Beispielsweise können Seefrachtführer Schlüsseldokumente (z. B. Frachtbrief, Seefrachtbrief usw.) ausgeben, die von anderen gebraucht werden. Ebenso müssen andere Teilnehmer an dem Netzwerk Dokumente erzeugen und sich sicher sein, dass nur die ordnungsgemäßen Parteien Zugriff darauf erhalten. Beispiele von privaten Informationen schließen (ohne Einschränkung) Sendungsteilnehmer, Dokumente, ausführliche Standortdaten (Adressen) und dergleichen ein. Benötigt wird eine Möglichkeit, Daten mit allen Teilnehmern des Ökosystems zu teilen und dabei vertrauliche oder private und nur für die ordnungsgemäßen Parteien zugängliche oder austauschbare Informationen zu sichern.
  • Die Ausführungsbeispiele stellen ein System bereit, das Teilnehmern (z. B. Organisationen usw.), die zu einem Transportprozess mit mehreren Parteien gehören, dynamisch Berechtigungen zuteilen kann. Das System kann vordefinierte Rollen speichern, die verschiedenen Teilnehmerarten zugeordnet sind. Wenn ein Teilnehmer als Teil des Prozesses identifiziert wird, kann das System eine Rolle für den Teilnehmer für diesen bestimmten Prozess bestimmen und Lese- und Schreib-Berechtigungen für Dokumente und Ereignisdaten des Prozesses basierend auf der bestimmten Rolle dynamisch zuteilen. Die Rolle, die einem Teilnehmer zugeteilt wird, kann basierend auf der Position des Teilnehmers in dem Prozess variieren. Daher kann das System während der Laufzeit eine Rolle für den Teilnehmer basierend auf den bestimmten Einzelheiten des Prozesses dynamisch bestimmen und Lese/Schreib-Berechtigungen entsprechend zuteilen. Außerdem kann das System derartige Berechtigungen für die Blockchain ablegen, so dass sie sicher/unveränderlich abgelegt sind und über verschiedene Standorte/Stellen in dem Netzwerk zugänglich sind. Wenn neue Daten verfügbar werden, können die Berechtigungen in der Blockchain aktualisiert werden, um die geänderten Daten wiederzugeben, und die Berechtigungen können entsprechend aktualisiert/zugeteilt werden. Wenn ein Teilnehmer (oder ein Benutzer desselben) versucht, auf die Daten zuzugreifen, kann die Blockchain Zugriffsberechtigungen durchsetzen, wodurch ein nicht autorisierter Zugriff auf die Daten verhindert wird, während auch ungleiche Parteien einen praktischen Mechanismus zum Visualisieren der Daten erhalten.
  • Das hier beschriebene System unterstützt globale Handelsberechtigungen und den kontrollierten Zugriff auf Daten, Ressourcen und Dokumente auf dynamische und automatisierte Art und Weise, ohne Definitionen von Punkt-zu-Punkt-Zugriff für die mit dem Prozess verbundenen Teilnehmer zu benötigen. Die Ausführungsbeispiele kombinieren die Konzepte von Rollen, die jede Partei bei einer gegebenen Sendung übernehmen kann, mit Dokumentarten und Ereignisarten, die jede Rolle erzeugen oder darauf zugreifen kann. Außerdem kann das System eine Zugriffskontrolle ableiten, die zur Laufzeit für jeden Benutzer, der auf jedes Dokument oder Datenelement zugreift, durchgesetzt werden muss. Um beispielsweise Zugriffsrechte zu bestimmen, die ein gegebener Teilnehmer für Handelsinformationen (einschließlich Meilensteine und Dokumente) hat, kann das System die Zugriffskontrolle aus den Informationen über die Rolle des Teilnehmers bei der gegebenen Sendung bestimmen. Während der Laufzeit setzen diverse Richtliniendienste die Berechtigungen derart durch, dass nur erlaubte Daten von jeder Partei zu sehen sind. Bei einigen Ausführungsformen kann es das System einem Transportdienst ermöglichen, die Berechtigungen für eine gegebene Sendung zu übergehen, kann es dem Hochlader eines Dokuments erlauben, die Berechtigungen basierend auf seinen Vorlieben anzupassen, kann die Zugriffskontrolle für jede Ebene der Sendungshierarchie unterstützen, und dergleichen.
  • Einige der Vorzüge des hier beschriebenen Systems schließendas Bereitstellen des Zugriffs auf die Daten für mehrere Parteien ein, ohne eine Eins-zu-Eins-Verbindung mit jeder der betreffenden Parteien erstellen zu müssen. Somit finden die Parteien viele Vorteile, einschließlich der durchgehenden Sichtbarkeit über Versandkorridore und Echtzeitzugriff auf Informationen, was zu einer bereicherten Hafenzusammenarbeit und verbesserten Terminalplanung führt. Das System stellt auch einen digitalen Buchprüfungspfad von Sendungsereignissen und Dokumenten bereit, was die Kundendienstleistungen und Netzwerkintegrationskosten und falsch deklarierte Fracht reduziert. Das System stellt auch gemeinsam genutzte und digitalisierte Import-/Export-Informationen bereit, was besser informierte Risikobewertungen, weniger Schreibarbeit und eine einfachere Verbindung zu nationalen Plattformen erstellt. Das System stellt auch einen Echtzeitzugriff auf Versorgungskettenereignisse für die Sendung bereit und stellt Binnentransport mit verbesserter Planung und Verwendung von Anlagen, was Engpässe auflöst, bereit. Zudem wird, wenn die gesamte Versorgungskette rationalisiert wurde, die Vorhersehbarkeit erheblich verbessert, was eine einfachere Meldung von Problemen und weniger Inventar ermöglicht. Das System stellt auch die Effizienz von Sendungsverfolgungs-Tools bereit, was eine Verbesserung von Abfertigungsmakler-Tools ermöglicht. Außerdem stellt die Verwendung einer Blockchain eine unveränderliche Informationsquelle für die Handelsfinanz bereit, wodurch Finanzdienstleistungen Zugriff auf Echtzeitdaten erhalten.
  • Wie ferner hier beschrieben, können die Teilnehmer dynamisch Zugriff auf Blockchain-Daten erhalten, wie etwa auf Ereignisdaten (Meilensteine) und Dokumente, die mit einem Transportprozess mit mehreren Parteien verknüpft sind. Wie hier beschrieben, versteht sich der Begriff „Transport“ als sich auf ein beliebiges Verfahren zum Transportieren von Fracht oder Gütern beziehend, wozu See/Schifffahrt, Eisenbahn/Züge, Straßen/Lastwagen, Flug/Flugzeuge und dergleichen gehören.
  • Beispiele von Teilnehmerarten schließen ohne Einschränkung Frachtbesitzer, Agenten, Seefrachtführer, Transportvermittler, Binnentransporter, Terminalbetreiber, Zollbehörden, Finanzdienstleister und dergleichen ein.
  • Beispiele von Rollen, die den Teilnehmerarten gewährt werden können, schließen ohne Einschränkung Käufer, Verkäufer, Exporteur, Importeur, Warenversender, Warenempfänger, Transportdienstkäufer, Transportdienstleister, fremdbeteiligte Ursprungs- oder Ziel-Logistik (3PL), Zollmakler (Export, Import usw.), Hafenterminal (Ursprung, Ziel usw.), Eisenbahnbetreiber, Lastwagenbetreiber, Frachtschiffbetreiber, Zuführer, Umschlagterminals, Hafengemeinschaftsdienste (PCS), Exportbehörden, Importbehörden, Banken (Bank des Verkäufers, Bank des Käufers usw.), Versicherungsdienstanbieter und dergleichen ein.
  • Jede Teilnehmerart kann einer Vielzahl von verschiedenen Rollen zugeordnet werden. Beispielsweise kann ein Frachtbesitzer eine Rolle als Verkäufer, Käufer, Exporteur, Importeur, Warenversender, Warenempfänger, Transportdienstkäufer usw., basierend auf den Aktivitäten des Frachtbesitzers in dem Transportprozess mit mehreren Parteien haben. Wenn der ferner hier beschriebene Richtliniendienst die Einzelheiten eines Transportprozesses mit mehreren Parteien empfängt, kann der Richtliniendienst jedem Teilnehmer basierend auf den Zuordnungen und basierend auf den Aktionen des Teilnehmers in dem Transportprozess eine Rolle oder eine Vielzahl von Rollen zuteilen. Falls beispielsweise der Frachtbesitzer sowohl der ursprüngliche Besitzer, der die Fracht verkauft, als auch ein Frachtführer der Fracht von einem Land zum anderen ist, kann der Frachtbesitzer die Rolle sowohl des Verkäufers, des Exporteurs als auch des Warenversenders übernehmen.
  • Beispiele von Dokumenten, die Teil des Transportprozesses mit mehreren Parteien sein können, schließen ohne Einschränkung Buchungsbestätigung, Rechnung, Versandanweisungen, Frachtbrief, Seefrachtbrief, Hausfrachtbrief, Frachtquittung des Spediteurs, Ankunftsmeldung, Gefahrguterklärung, Buchungsanfrage und dergleichen ein.
  • Beispiele von Ereignissen, die während des Transportprozesses mit mehreren Parteien vorkommen können, schließen ohne Einschränkung ein Administratorereignis, ein geplantes Ursprungsereignis, ein geplantes See-Ereignis, ein geplantes Zielereignis, ein geschätztes Ursprungsereignis, ein geschätztes See-Ereignis, ein geschätztes Zielereignis, ein tatsächliches Ursprungsereignis, ein tatsächliches See-Ereignis, ein tatsächliches Zielereignis und dergleichen ein.
  • Durch das dynamische Kombinieren der Zuordnung eines Teilnehmers zu einer Rolle innerhalb der Transporthierarchie mit mehreren Parteien mit der Geltendmachung von Berechtigungen für die Parteirollen für verschiedene Meilensteinereignisse der Sendung und für verschiedene Handelsdokumente kann das System Berechtigungen zum Zugreifen (Lesen/Schreiben) auf gewisse Daten des Transportprozesses mit mehreren Parteien ableiten und durchsetzen. Als ein nicht einschränkendes Beispiel kann das System bestimmen, dass ein Seefrachtführer ein Frachtbriefdokument einer Sendung hochladen kann, doch ein Binnentransporter (z. B. Lastwagenfahrer) keinen Zugriff auf dieses Dokument haben kann. Das Gesamtsystem besteht aus Dienste, die Berechtigungsinformationen ableiten und sie dann als Teil des Zugriffs auf die Objekte von dem System, einschließlich Meilensteinereignisse und Dokumente, durchzusetzen.
  • 1 bildet ein Handelsökosystem 100 zum Verwalten des Frachttransports gemäß Ausführungsbeispielen ab. Mit Bezug auf 1 kann eine Host-Plattform 130 das hier beschriebene System hosten, und kann eine Anwendungsprogrammierschnittstelle (API) 132, einen oder mehrere Dienste 134 und eine Blockchain 136 einschließen. Die Teilnehmer 110 des Systems können auf die Dienste 134 über eine oder mehrere Anwendungen 120 oder APIs 132 zugreifen, um anfängliche Transportdaten (z. B. betreffende Partei, Routeninformationen, Frachtinformationen usw.) eines Transportprozesses mit mehreren Parteien hochzuladen. Basierend auf diesen Informationen können die Dienste 134 die Rollen jeder der betreffenden Parteien identifizieren und Zugriffsrechte (z. B. zum Lesen und/oder Schreiben von Daten) auf die Dokumente und die Ereignisdaten des Transportprozesses mit mehreren Parteien dynamisch zuteilen. Die dynamisch zugeteilten Zugriffsinformationen sowie eine Kennung des Transportprozesses mit mehreren Parteien, die Ereignisse und Dokumente und die Parteien können in der Blockchain 136 abgelegt werden.
  • Dabei kann die API 132 Datenkommunikationen zwischen den Teilnehmern 110 an dem Transportprozess mit mehreren Parteien und der Host-Plattform 130, den Anwendungen 120 und der Host-Plattform 130 und dergleichen ermöglichen. Frachtbezogene Daten können auch von den Teilnehmern 110 hochgeladen und über einen Integrationsrahmen 112 in ein Format, das für die Plattform 130 geeignet ist, integriert werden. Beispielsweise können Bildgebungsdaten von der Fracht aufgenommen werden (z. B. Einscannen einer Produkt-ID oder einer Container-ID), die dann an die Blockchain 136 zusammen mit Kontextinformationen in der Form einer Textbeschreibung, wie etwa einer Geolokalisierung der Fracht, einem aktuellen Teilnehmer in Besitz der Fracht, einer Kennung eines Transports (Frachtschiff, Lastwagen, Eisenbahn usw.), in Besitz der Fracht, Sensordaten (z. B. Temperatur, Geschwindigkeit, Feuchtigkeit usw.) einer Umgebung, in der sich die Fracht befindet, und dergleichen eingegeben werden. Die Daten können in der Blockchain 136 auf unveränderliche Art und Weise abgelegt sein, so dass die Parteien die Daten später überarbeiten können, falls etwas schief geht. Dies kann ein schnelles Verständnis bereitstellen, warum die Fracht/Sendung die Erwartungen nicht erfüllt hat, usw.
  • Anfänglich können die Teilnehmer 110 als Organisationen in die Lösung eingebunden werden. Jedem Teilnehmer kann ein Teilnehmertyp zugeteilt werden, der einen Satz von spezifischen Rollen definiert, welche die Organisation bei einer Sendung übernehmen kann. Beispielsweise kann eine Teilnehmerart eines Frachtbesitzers die Rollen eines Verkäufers, Käufers, Importeurs, Exporteurs, Warenversenders, Warenempfängers, Transportdienstkäufers usw. haben. Die Dienste 134 können Rollen zuteilen, Lese-/Schreib-Berechtigungen für jede Rolle/Partei in dem Transportprozess mit mehreren Parteien definieren und den Zugriff auf Daten des Transportprozesses mit mehreren Parteien basierend auf den definierten Lese- und Schreib-Berechtigungen kontrollieren. Beispielsweise kann es einer Partei erlaubt sein, die Daten eines gewissen Dokuments oder ein Meilensteinereignis zu lesen, aber nicht erlaubt sein, Daten zu schreiben. Als ein anderes Beispiel kann es einer Partei erlaubt sein, gewisse Dokumente, aber nicht alle Dokumente, die den Transportprozess mit mehreren Parteien betreffen, zu sehen. Die Dienste 134 können Berechtigungen dynamisch zuteilen und anschließend den Zugriff auf die Daten basierend auf den dynamisch zugeteilten Berechtigungen kontrollieren. Die Daten des Transportprozesses mit mehreren Parteien können in der Blockchain 136, einem System außerhalb der Kette und dergleichen abgelegt werden.
  • Beispielsweise können Ereignisse/Meilensteine der Fracht, während sie sich durch den Transportprozess mit mehreren Parteien bewegt, in Verbindung mit der Blockchain 136 abgelegt werden. Die Ereignisdaten können von den Teilnehmern 110 über den Integrationsrahmen 112 hochgeladen werden. Die Ereignisdaten können in der Blockchain 136 abgelegt werden. Als ein anderes Beispiel können die Ereignisdaten außerhalb der Kette mit einem Hash der Ereignisdaten (zu Prüfzwecken), die in der Blockchain 136 abgelegt sind, abgelegt werden. Beispiele von Ereignissen schließen Container-Statusereignisse ein, die sich auf eine PID (räumliche ID) des Containers beziehen, und wo sie sich zu einem gegebenen Zeitpunkt befinden. Beispielsweise kann ein Bild der PID aufgenommen und mit Kontextinformationen auf die Host-Plattform 130 hochgeladen werden. Die Dienste 134 können einen Hash der Ereignisdaten erstellen und ihn in der Blockchain 136 ablegen, während die Ereignisdaten außerhalb der Kette abgelegt werden. Wenn ein Benutzer (z. B. eines Teilnehmers des Transportprozesses mit mehreren Parteien) anschließend versucht, auf die Ereignisdaten zuzugreifen, kann der Zugriff über einen Richtliniendienst kontrolliert werden (der intelligente Verträge umfasst), und der ferner mit Bezug auf 4A bis 4D beschrieben wird. Der Zugriff auf die Ereignisdaten kann auf den Rollen basieren, die einem Teilnehmer während der Laufzeit dynamisch zugeteilt werden.
  • Ebenso können Dokumente, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, in der Blockchain 136 abgelegt werden, oder sie können außerhalb der Kette mit einem Hash des Dokuments, das in der Blockchain 136 abgelegt wird, abgelegt werden. Ähnlich wie bei den Ereignisdaten kann der Zugriff auf die Dokumentendaten durch den Richtliniendienst kontrolliert werden, und der Zugriff auf die Dokumente kann auf den Rollen basieren, die dem Teilnehmer während der Laufzeit dynamisch zugeteilt werden.
  • Jede der Interaktionen mit der Host-Plattform 130 kann authentifiziert werden, und Benutzer und Organisationen (Teilnehmer) können digitalen Identitäten, die über eine CA (Zertifizierungsbehörde) in der Blockchain registriert sind, zugeordnet werden. Außerdem bietet die Verwendung der Blockchain 136 zahlreiche Vorteile für die Lösung. Beispielsweise stellt die Blockchain 136 ein unveränderliches, gemeinsam genutztes, kopiertes Hauptbuch bereit, das Probleme lösen kann, die vorkommen können, wenn mehrere nicht vertrauenswürdige Parteien zusammen Transaktionen abwickeln, wie etwa mangelndes Vertrauen und dergleichen. Die Blockchain 136 stellt auch eine einzelne Version der Wahrheit bereit. Dies kann hilfreich sein, weil Streitigkeiten üblich sind und ihre Behebung kostspielig ist. Außerdem kann die Blockchain 136 verwendet werden, um Authentizität und Inhaberschaft nachzuweisen. Die Blockchain 136 kann verwendet werden, um den Zugriff auf mehrere Schritte von Verwaltungsarbeit (globale Handelsunterlagen, Versorgungskettenfinanz usw.) zu kontrollieren. Die Blockchain 136 stellt auch eine zuverlässige Sichtbarkeit von Ereignissen über mehrere Parteien bereit, wozu Rückrufe, eine Kontrollkettenverfolgung, Herkunft und dergleichen gehören. Die Blockchain 136 kann auch eine Überprüfbarkeit über das unveränderliche Hauptbuch bereitstellen und Betrug/Manipulation verhindern auf Grund der verteilten Beschaffenheit der Blockchain 136 verhindern.
  • 2A bildet eine Blockchain-Architekturkonfiguration 200 gemäß Ausführungsbeispielen ab. Mit Bezug auf 2A kann die Blockchain-Architektur 200 gewisse Blockchain-Elemente, beispielsweise ein Gruppe von Blockchain-Knoten 202, einschließen. Die Blockchain-Knoten 202 können einen oder mehrere Knoten 204 bis 210 einschließen (diese vier Knoten sind rein beispielhaft dargestellt). Diese Knoten nehmen an einer Anzahl von Aktivitäten teil, wie etwa an einem Prozess zum Hinzufügen und Validieren von Blockchain-Transaktionen (Konsens). Einer oder mehrere der Blockchain-Knoten 204 bis 210 kann bzw. können Transaktionen basierend auf einer Indossamentrichtlinie indossieren und kann einen Ordnungsdienst für alle Blockchain-Knoten in der Architektur 200 bereitstellen. Auf jedem der Blockchain-Knoten 204 bis 210 können eine Blockchain-Plattform 212, Anwendungscode 220 (z. B. intelligente Verträge usw.), Anwendungsprogrammierschnittstellen (APIs) 222, Anwendungen 224 und dergleichen installiert sein. Beispielsweise kann ein Blockchain-Knoten eine Blockchain-Transaktion einleiten und versuchen, in ein unveränderliches Blockchain-Hauptbuch zu schreiben, das in der Blockchain-Schicht 216 abgelegt ist, von dem eine Kopie auch in der zugrundeliegenden räumlichen Infrastruktur 214 der Blockchain-Plattform 212 abgelegt sein kann. Die Blockchain-Konfiguration kann Anwendungen 224 einschließen, die mit den APIs 222 verlinkt sind, um auf abgelegten Programm-/Anwendungscode 220 (z. B. Blockchain-Clients, Kettencode, intelligente Verträge usw.), der gemäß einer speziell angepassten Konfiguration erstellt werden kann, welche die Teilnehmer wünschen, zuzugreifen und diesen auszuführen, und kann ihren Zustand bewahren, externe Informationen empfangen und mit den Blockchain-APIs kommunizieren. Dies kann auf allen Blockchain-Knoten 204 bis 210 eingesetzt und installiert werden.
  • Die Blockchain-Basis bzw. -Plattform 212 kann diverse Schichten von Blockchain-Daten, Diensten (z. B. kryptografische Vertrauensdienste, eine virtuelle Ausführungsumgebung usw.) und zugrundeliegende räumliche Computerinfrastruktur einschließen, die verwendet werden können, um neue Transaktionen zu empfangen und abzulegen, und um Buchprüfern Zugriff zu geben, die Zugriff auf Dateneinträge wünschen. Die Blockchain-Schicht 216 kann eine Schnittstelle freilegen, die Zugriff auf die virtuelle Durchführungsumgebung bereitstellt, die notwendig ist, um den Programmcode zu verarbeiten und die räumliche Infrastruktur 214 einzubeziehen. Die kryptografischen Treuhanddienste 218 können verwendet werden, um Transaktionen zu überprüfen, wie etwa Anlagenaustauschtransaktionen, und um Informationen privat zu halten.
  • Die Blockchain-Architekturkonfiguration aus 2A kann den Programm-/ Anwendungscode 220 über eine oder mehrere freigelegte Schnittstellen und von der Blockchain-Plattform 212 bereitgestellte Dienste verarbeiten und ausführen. Der Code 220 kann Blockchain-Anlagen kontrollieren. Beispielsweise kann der Code 220 Daten speichern und übertragen, und kann durch die Knoten 204 bis 210 in der Form eines intelligenten Vertrags und eines verknüpften Kettencodes mit Bedingungen oder anderen Codeelementen, die seiner Ausführung unterliegen, ausgeführt werden. Als ein nicht einschränkendes Beispiel können intelligente Verträge erstellt werden, um Mahnungen, Aktualisierungen und/oder andere Meldungen auszuführen, die den Änderungen, Aktualisierungen usw. unterliegen. Die intelligenten Verträge können selber verwendet werden, um Regeln zu identifizieren, die mit Autorisierungs- und Zugriffsanforderungen und der Verwendung des Hauptbuchs verknüpft sind. Beispielsweise können Lesedaten durch intelligente Verträge in dem Anwendungscode 220 verarbeitet werden, um den angemessenen Zugriff zu bestimmen und nur die sichtbaren Ergebnisse für die anfragende Partei zurückgeben. Auch können Schreibdaten von intelligenten Verträgen in dem Anwendungscode 220 verarbeitet werden, um zu bestimmen, ob der richtige Zugriff auf die spezifische Anlage für diese Partei/Organisation erlaubt ist.
  • Ein intelligenter Vertrag kann in einer Programmiersprache erstellt werden und dann auf einem Kanal für alle Blockchain-Knoten verknüpft/instanziiert/eingesetzt werden. Der intelligente Vertrag kann ausführbaren Code einschließen, der in einem Blockchain-Kanal oder Hauptbuch (z. B. verteiltes Netzwerk von Blockchain-Peers) registriert, abgelegt und/oder kopiert wird. Eine Transaktion wird durch die Anwendung oder den Blockchain-Client eingereicht, was die Ausführung des intelligenten Vertragscodes für Validierungs- oder Konsenszwecke bewirken kann. Die erfolgreiche Ausführung des intelligenten Vertrags kann eine oder mehrere vertrauenswürdige Änderungen an einem Zustand eines digitalen Blockchain-Hauptbuchs auslösen. Die Änderung(en) an dem Blockchain-Hauptbuch, die durch die Ausführung des intelligenten Vertrags bewirkt wird/werden, kann/können automatisch in dem gesamten verteilten Netzwerk von Blockchain-Peers über Intra-Blockchain-Kommunikationsprotokolle kopiert werden.
  • Der intelligente Vertrag kann Daten in die Blockchain im Format von Schlüssel-/ Wert-Paaren schreiben. Außerdem kann der intelligente Vertragscode die Werte lesen, die in einer Blockchain abgelegt sind, und sie bei Anwendungsvorgängen verwenden. Der intelligente Vertragscode kann die Ausgabe von diversen logischen Operationen in die Blockchain schreiben. Daten, die in die Blockchain geschrieben werden, können öffentlich sein und/oder können verschlüsselt und privat gehalten werden kann. Die temporären Daten, die durch den intelligenten Vertrag verwendet/generiert werden, werden durch die zugeführte Ausführungsumgebung im Speicher gehalten, dann gelöscht, sobald die Daten, die für die Blockchain benötigt werden, identifiziert sind.
  • Ein Kettencode kann die Codeauslegung eines intelligenten Vertrags mit zusätzlichen Merkmalen einschließen. Wie hier beschrieben, kann der Kettencode ein Programmcode sein, der in dem Blockchain-Knotennetzwerk eingesetzt wird, wo er durch Kettenvalidierer während eines Konsensprozesses ausgeführt und validiert wird.
  • 2B bildet ein Beispiel eines Blockchain-Transaktionsflusses 250 zwischen den Knoten der Blockchain gemäß einem Ausführungsbeispiel ab. Mit Bezug auf 2B kann der Transaktionsfluss einen Transaktionsvorschlag 291 einschließen, der von einem Anwendungs-Client-Knoten 260 an einen indossierenden Peer-Knoten 281 gesendet wird. Der indossierende Peer 281 kann die Client-Signatur verifizieren und eine Kettencodefunktion ausführen, um die Transaktion einzuleiten. Die Ausführung des Kettencodes in 281 kann eine Berechtigungsprüfung auf die angemessene Lese- und/oder Schreib-Berechtigung für die Partei/Organisation, welche die Transaktion aufgerufen hat, einschließen. Es kann beispielsweise überprüft werden, ob eine Partei autorisiert ist, ein Dokument oder Ereignisdaten zu visualisieren. Die Ausgabe kann die Kettencodeergebnisse, einen Satz von Schlüssel-/Wert-Versionen, die aus dem Kettencode gelesen wurden (Lesesatz), und den Satz von Schlüsseln/Werten, die in den Kettencode geschrieben wurden (Schreibsatz), einschließen. Die Vorschlagsantwort 292 wird zusammen mit einer Indossamentsignatur an den Client 260 zurückgesendet, falls sie genehmigt ist. Der Client 260 fügt die Indossamente in einer Transaktionsnutzlast 293 zusammen und sendet sie an einen Ordnungsdienstknoten 284 rund. Der Ordnungsdienstknoten 284 liefert dann geordnete Transaktionen als Blöcke an alle Peers 281 bis 283 in einem Kanal. Vor dem Festschreiben in der Blockchain kann jeder Peer 281 bis 283 die Transaktion validieren. Beispielsweise können die Peers die Indossamentrichtlinie überprüfen, um sicherzustellen, dass der korrekte Kontingent der vorgegebenen Peers die Ergebnisse unterzeichnet hat und die Signaturen gegenüber der Transaktionsnutzlast 293 authentifiziert hat.
  • Noch einmal mit Bezug auf 2B leitet der Client-Knoten 260 die Transaktion 291 ein, indem er eine Anfrage aufbaut und an den Peer-Knoten 281, der ein Indossant ist, sendet. Der Client 260 kann eine Anwendung einschließen, die ein unterstütztes Software-Entwicklungskit (SDK) nutzt, das eine verfügbare API verwendet, um einen Transaktionsvorschlag zu generieren. Der Vorschlag ist eine Anfrage, eine Kettencodefunktion aufzurufen, so dass die Daten in dem Hauptbuch gelesen und/oder geschrieben werden können (d. h. neue Schlüssel-Werte-Paare für die Anlagen geschrieben werden). Das SDK kann als Shim dienen, um den Transaktionsvorschlag in ein Format mit der angemessenen Architektur (z. B. einen Protokollpuffer über einen Remote Procedure Call (RPC)) zu verpacken, und kann die kryptografischen Referenzen des Clients nehmen, um eine einzigartige Signatur für den Transaktionsvorschlag zu erzeugen.
  • Daraufhin kann der indossierende Peer-Knoten 281 überprüfen, (a) dass der Transaktionsvorschlag richtig gebildet ist, (b) die Transaktion nicht bereits früher eingereicht wurde (Schutz gegen Reply-Angriff), (c) die Signatur gültig ist, und (d) dass der Einreichende (bei dem Beispiel der Client 260) angemessen autorisiert ist, um den vorgeschlagenen Vorgang auf diesem Kanal auszuführen. Der indossierende Peer-Knoten 281 kann die Eingaben des Transaktionsvorschlags als Argumente für die aufgerufene Kettencodefunktion nehmen. Der Kettencode wird dann gegenüber einer aktuellen Zustandsdatenbank ausgeführt, um Transaktionsergebnisse zu erzeugen, die einen Antwortwert, einen Lesesatz und einen Schreibsatz einschließen. Es werden zu diesem Zeitpunkt jedoch keine Aktualisierungen an dem Hauptbuch vorgenommen. Bei 292 wird der Satz von Werten zusammen mit der Signatur des indossierenden Peer-Knotens 281 als Vorschlagsantwort 292 an das SDK des Clients 260 zurückgegeben, das die Nutzlast zur Verwendung durch die Anwendung parst.
  • Daraufhin prüft/verifiziert die Anwendung des Clients 260 die Signaturen der indossierenden Peers und vergleicht die Vorschlagsantworten, um zu bestimmen, ob die Vorschlagsantwort die gleiche ist. Falls der Kettencode nur das Hauptbuch abgefragt hätte, würde die Anwendung die Abfrageantwort prüfen und würde typischerweise die Transaktion nicht an den Ordnungsknotendienst 284 einreichen. Falls die Client-Anwendung versucht, die Transaktion an den Ordnungsknotendienst 284 zur Aktualisierung des Hauptbuchs einzureichen, bestimmt die Anwendung vor dem Einreichen, ob die vorgegebene Indossamentrichtlinie erfüllt wurde, (d. h. ob alle für die Transaktion notwendigen Peer-Knoten die Transaktion indossiert haben). Hierbei kann der Client vielleicht nur eine von mehreren Parteien der Transaktion einschließen. In diesem Fall kann jeder Client seinen eigenen indossierenden Knoten aufweisen, und jeder indossierende Knoten muss die Transaktion indossieren. Die Architektur ist derart, dass sogar, falls eine Anwendung auswählt, keine Antworten zu prüfen oder ansonsten eine nicht indossierte Transaktion weiterleitet, die Indossamentrichtlinie dennoch von den Peers durchgesetzt und in der Festschreibvalidierungsphase aufrechterhalten wird.
  • Nach erfolgreicher Prüfung in Schritt 293 fügt der Client 260 die Indossamente in einer Transaktion zusammen und sendet den Transaktionsvorschlag und die Antwort in einer Transaktionsnachricht an den Ordnungsknoten 284 rund. Die Transaktion kann die Lese-/ Schreib-Sätze, die Signaturen der indossierenden Peers und eine Kanal-ID enthalten. Der Ordnungsknoten 284 muss nicht den gesamten Inhalt einer Transaktion prüfen, um seinen Vorgang auszuführen, vielmehr kann der Ordnungsknoten 284 einfach Transaktionen von allen Kanälen in dem Netzwerk empfangen, sie chronologisch nach Kanälen ordnen und Blöcke von Transaktionen pro Kanal erstellen.
  • Die Blöcke der Transaktion werden von dem Ordnungsknoten 284 an alle Peer-Knoten 281 bis 283 auf dem Kanal geliefert. Die Transaktionen 294 in dem Block werden validiert, um sicherzustellen, dass alle Indossamentrichtlinien erfüllt sind, und um sicherzustellen, dass an dem Hauptbuch-Zustand keine Änderungen für die Variablen des Lesesatzes vorgenommen wurden, seit der Lesesatz durch die Transaktionsausführung generiert wurde. Die Transaktionen in dem Block werden als gültig oder ungültig markiert. Außerdem hängt in Schritt 295 jeder Peer-Knoten 281 bis 283 den Block an die Kette des Kanals, und für jede gültige Transaktion werden die Schreibsätze in der aktuellen Zustandsdatenbank festgeschrieben. Es wird ein Ereignis emittiert, um der Client-Anwendung zu melden, dass die Transaktion (Aufruf) unveränderlich an die Kette angehängt wurde, und um zu melden, ob die Transaktion validiert oder invalidiert wurde.
  • 3A bildet ein Beispiel eines berechtigten Blockchain-Netzwerks 300 ab, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. Bei diesem Beispiel kann ein Blockchain-Benutzer 302 eine Transaktion für die berechtigte Blockchain 304 einleiten. Bei diesem Beispiel kann die Transaktion ein Einsetzen, Aufrufen oder Abfragen sein und kann durch eine Client-seitige Anwendung, die ein SDK nutzt, direkt über eine API usw. ausgegeben werden. Netzwerke können Zugriff auf einen Regulierer 306, wie etwa einen Buchprüfer, geben. Ein Blockchain-Netzwerkbetreiber 308 verwaltet Mitgliedsberechtigungen, wie etwa das Eintragen des Regulierers 306 als „Buchprüfer“ und des Blockchain-Benutzers 302 als „Client“. Ein Buchprüfer könnte darauf eingeschränkt sein, nur das Hauptbuch abzufragen, wohingegen ein Client autorisiert sein könnte, gewisse Arten von Kettencode einzusetzen, aufzurufen und abzufragen.
  • Ein Blockchain-Entwickler 310 kann Kettencode und Client-seitige Anwendungen schreiben. Der Blockchain-Entwickler 310 kann den Kettencode über eine Schnittstelle direkt im Netzwerk einsetzen. Bei diesem Beispiel verbindet sich der Blockchain-Benutzer 302 über einen Peer-Knoten 314 mit der berechtigten Blockchain 304. Bevor er eventuelle Transaktionen abwickelt, ruft der Peer-Knoten 314 die Eintragung und die Transaktionszertifikate des Benutzers von einer Zertifizierungsbehörde 316 ab, die Benutzerrollen und Berechtigungen verwaltet. Die Blockchain-Benutzer müssen über diese digitalen Zertifikate verfügen, um an der berechtigten Blockchain 304 Transaktionen abzuwickeln. Dabei kann es notwendig sein, dass ein Benutzer, der versucht, den Kettencode zu verwenden, seine Referenzen verifiziert.
  • 3B bildet ein weiteres Beispiel eines berechtigten Blockchain-Netzwerks 320 ab, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. Bei diesem Beispiel kann ein Blockchain-Benutzer 322 eine Transaktion in die berechtigte Blockchain 324 einreichen. Bei diesem Beispiel kann die Transaktion ein Einsetzen, Aufrufen oder Abfragen sein und kann über eine Client-seitige Anwendung, die ein SDK nutzt, direkt über eine API usw. ausgegeben werden. Die Netzwerke können Zugriff auf einen Regulierer 326, wie etwa einen Buchprüfer, bereitstellen. Ein Blockchain-Netzwerkbetreiber 328 verwaltet Mitgliedsberechtigungen, wie etwa das Eintragen des Regulierers 326 als „Buchprüfer“ und des Blockchain-Benutzers 322 als „Client“. Ein Buchprüfer könnte darauf eingeschränkt sein, nur das Hauptbuch abzufragen, wohingegen ein Client autorisiert sein könnte, gewisse Arten von Kettencode einzusetzen, aufzurufen und abzufragen.
  • Ein Blockchain-Entwickler 330 schreibt Kettencode und Client-seitige Anwendungen. Der Blockchain-Entwickler 330 kann Kettencode über eine Schnittstelle direkt im Netzwerk einsetzen. Um Referenzen von einer herkömmlichen Datenquelle 332 in den Kettencode einzubeziehen, könnte der Entwickler 330 eine bandexterne Verbindung verwenden, um auf die Daten zuzugreifen. Bei diesem Beispiel verbindet sich der Blockchain-Benutzer 322 über einen Peer-Knoten 334mit dem Netzwerk. Bevor er eventuelle Transaktionen abwickelt, ruft der Peer-Knoten 334 die Eintragung und Transaktionszertifikate des Benutzers von der Zertifizierungsbehörde 336 ab. In manchen Fällen müssen Blockchain-Benutzer über diese digitalen Zertifikate verfügen, um in der berechtigten Blockchain 324 Transaktionen abzuwickeln. Dabei kann es notwendig sein, dass ein Benutzer, der versucht, den Kettencode zu verwenden, seine Referenzen an der herkömmlichen Datenquelle 332 verifizieren muss. Um die Autorisation des Benutzers zu bestätigen, kann der Kettencode eine bandexterne Verbindung zu diesen Daten über eine herkömmliche Verarbeitungsplattform 338 verwenden.
  • Bei einigen Ausführungsformen kann die Blockchain hier eine berechtigungslose Blockchain sein. Im Gegensatz zu berechtigten Blockchains, die zum Beitritt eine Berechtigung benötigen, kann jedermann einer berechtigungslosen Blockchain beitreten. Um beispielsweise einer berechtigungslosen Blockchain beizutreten, kann ein Benutzer eine persönliche Adresse erstellen und beginnen, mit dem Netzwerk zu interagieren, indem er Transaktionen einreicht und somit Einträge zu dem Hauptbuch hinzufügt. Zudem haben alle Parteien die Wahl, einen Knoten in dem System auszuführen und die Mining-Protokolle zu verwenden, um beim Verifizieren der Transaktionen zu helfen.
  • 3C bildet einen Prozess 350 einer Transaktion ab, die von einer berechtigungslosen Blockchain 352 verarbeitet wird, die eine Vielzahl von Knoten 354 einschließt. Ein Sender 356 möchte eine Zahlung oder eine gewisse andere Wertform (z. B. eine Urkunde, medizinische Unterlagen, einen Vertrag, eine Ware, eine Dienstleistung oder eine beliebige andere Anlage, die in einem digitalen Eintrag verkapselt werden kann) an einen Empfänger 358 über die berechtigungslose Blockchain 352 senden. Bei einer Ausführungsform kann jede von der Sendervorrichtung 356 und der Empfängervorrichtung 358 digitale Brieftaschen aufweisen (die mit der Blockchain 352 verknüpft sind), die Benutzerschnittstellenbedienelemente und eine Anzeige von Transaktionsparametern bereitstellen. Daraufhin wird die Transaktion durch die gesamte Blockchain 352 an die Knoten 354 rundgesendet. Je nach den Netzwerkparametern der Blockchain 352 verifizieren 360 die Knoten die Transaktion basierend auf Regeln (die vordefiniert oder dynamisch zugeteilt werden können), die von den Erzeugern der berechtigungslosen Blockchain 352 aufgestellt wurden. Beispielsweise können sie das Verifizieren der Identitäten der betreffenden Parteien usw. einschließen. Die Transaktion kann sofort verifiziert werden, oder sie kann in eine Warteschlange mit anderen Transaktionen gesetzt werden, und die Knoten 354 bestimmen, ob die Transaktionen gültig sind, basierend auf einem Satz von Netzwerkregeln.
  • In der Struktur 362 werden gültige Transaktionen zu einem Block gebildet und mit einer Sperre (Hash) versiegelt. Dieser Prozess kann durch Mining-Knoten unter den Knoten 354 erfolgen. Die Mining-Knoten können zusätzliche Software speziell für das Mining und die Erstellung von Blöcken für die berechtigungslose Blockchain 352 verwenden. Jeder Block kann durch einen Hash (z. B. eine 256-Bitzahl usw.) identifiziert werden, der unter Verwendung eines Algorithmus erstellt wird, auf den sich das Netzwerk geeinigt hat. Jeder Block kann eine Kopfzeile, einen Zeiger oder eine Referenz auf einen Hash einer Kopfzeile eines vorherigen Blocks in der Kette und eine Gruppe von gültigen Transaktionen einschließen. Die Referenz auf den Hash des vorherigen Blocks ist mit der Erstellung der sicheren unabhängigen Kette von Blöcken verknüpft.
  • Bevor Blöcke zu der Blockchain hinzugefügt werden können, müssen die Blöcke validiert werden. Die Validierung für die berechtigungslose Blockchain 352 kann einen Arbeitsnachweis (PoW) einschließen, wobei es sich um eine Lösung eines Rätsels handelt, das aus der Kopfzeile des Blocks abgeleitet wird. Obwohl er in dem Beispiel aus 3C nicht gezeigt ist, ist ein anderer Prozess zum Validieren eines Blocks ein Einsatznachweis. Anders als der Arbeitsnachweis, bei dem der Algorithmus die Miner belohnt, die mathematische Probleme lösen, wird beim Einsatznachweis ein Erzeuger eines neuen Blocks je nach seinem Vermögen, das auch als „Einsatz“ definiert wird, deterministisch gewählt. Dann wird ein ähnlicher Nachweis durch die ausgewählten/gewählten Knoten ausgeführt.
  • Beim Mining 364 versuchen Knoten, den Block zu lösen, indem sie inkrementale Änderungen an einer Variablen vornehmen, bis die Lösung ein netzwerkweites Ziel erfüllt. Dies erstellt den PoW, wodurch korrekte Antworten sichergestellt werden. Mit anderen Worten muss eine mögliche Lösung nachweisen, dass Computerressourcen beim Lösen des Problems verbraucht wurden. Bei einigen Arten von berechtigungslosen Blockchains können die Miner mit einem Wert (z. B. Münzen usw.) für das korrekte Mining eines Blocks belohnt werden.
  • Hierbei macht der PoW-Prozess neben der Verkettung von Blöcken Änderungen der Blockchain extrem schwierig, da ein Angreifer alle nachfolgenden Blöcke ändern muss, damit die Änderungen eines Blocks akzeptiert werden. Außerdem nimmt die Schwierigkeit des Änderns eines Blocks zu, wenn neue Blöcke gemint werden und die Anzahl von nachfolgenden Blöcken zunimmt. Mit der Verteilung 366 wird der erfolgreich validierte Block über die berechtigungslose Blockchain 352 verteilt, und alle Knoten 354 fügen den Block zu einer Mehrheitskette hinzu, bei der es sich um das prüfbare Hauptbuch der berechtigungslosen Blockchain 352 handelt. Außerdem wird der Wert in der Transaktion, die von dem Sender 356 eingereicht wird, in der digitalen Brieftasche der Empfängervorrichtung 358 hinterlegt oder anderweitig darauf übertragen.
  • 4A bildet die Dienste 420 einer Host-Plattform zum Zuteilen von Berechtigungen und Kontrollieren des Zugriffs gemäß Ausführungsbeispielen ab. Bei diesem Beispiel schließen die Dienste 420 einen Berechtigungsdienst 422, einen Zugriffskontrolldienst 424 und einen Rollenbestimmungsdienst 426 ein. Hierbei können der Zugriffskontrolldienst 424 und der Rollenbestimmungsdienst 426 als Richtliniendienste bezeichnet werden. Der Berechtigungsdienst 422 kann mit Vorlagen zum Ableiten der Berechtigungen, die eine Teilnehmerrolle aufweisen kann, eingesät sein. Beispielsweise kann eine Warenversenderrolle bei einer Sendung ein geschäftliches Rechnungsdokument schreiben (hochladen), kann jedoch kein Einfuhranmeldungsdokument lesen. Auf diese Berechtigungen können der Rollenbestimmungsdienst 426 und der Zugriffskontrolldienst 424 zugreifen.
  • Wenn eine neue Sendung durch eine Benutzervorrichtung 406 (z. B. einen Benutzer oder ein System, der bzw. das mit Teilnehmern an einer Sendung verknüpft ist, usw.) erstellt wird, kann die Benutzervorrichtung 406 Sendungsinformationen 436 bereitstellen, die Daten einschließen, die mit einem Transportprozess mit mehreren Parteien verknüpft sind, wozu Einzelheiten, die Teilneher 402 (Kennungen) vorgeben, ein geografischer Ursprung, ein Ziel, Umschlaghäfen, ein Transportplan, Meilensteinereignisse, Handelsdokumente usw. gehören. Daraufhin kann der Rollenbestimmungsdienst 426 die empfangenen Sendungsinformationen 436 analysieren, eine Transportzusammenfassung zusammenstellen und bestimmen, welche Teilnehmer 402 zu dem Transportprozess mit mehreren Parteien und mit welcher Rolle hinzugefügt werden sollen. Eine Kennung der Sendung, eine Kennung der Teilnehmer/Rollen, Zugriffsrechte auf Dokumente und Ereignisse und dergleichen können in der Blockchain als Rollen-/Sendungsdaten 412 abgelegt werden. Hierbei können die Rollen- und Sendungsdaten 412 als eine Transaktion in einem Datenblock in der Hash-verlinkten Kette von Blöcken der Blockchain abgelegt werden.
  • Beispielsweise kann der Rollenbestimmungsdienst 426 die Sendungsinformationen 436, die einen mehrfachen Transportprozess und seine Einzelheiten identifizieren, empfangen. Daraufhin kann der Rollenbestimmungsdienst 426 Terminals/Häfen identifizieren, die den geografischen Standorten in den Sendungsinformationen 436 an den Standorten entsprechen, die als Ursprung, Ziel, Umschlag usw. identifiziert werden. Die Terminals/Häfen können als Terminals zu der Sendung hinzugefügt werden, so dass sie angemessen benachrichtigt werden kann. Als ein anderes Beispiel können Reiseländer aus den Sendungsinformationen 436 identifiziert werden, und der Rollenbestimmungsdienst 426 kann Zollbehörden (Teilnehmer) für die Länder bestimmen, durch welche die Sendung reist, die zu den Ursprungs-/Ziel-Zollämtem hinzugefügt werden können. Als ein anderes Beispiel können ein Verkäufer und ein Käufer aus den Handelsdokumenten identifiziert werden. Der Verkäufer kann als Warenversenderrolle hinzugefügt werden, während der in den Handelsdokumenten identifizierte Käufer als Warenempfängerrolle hinzugefügt werden kann. Außerdem kann der Rollenbestimmungsdienst 426 Benutzer von jeder der identifizierten Teilnehmer/Rollen mit Zugriffsberechtigungen dem System zum Lesen/Schreiben von Ereignissen oder Dokumenten über verschiedene Dienste (z. B. Abfragedienste, Abonnementsdienste, usw.) zuteilen.
  • Während sich der Container, die Fracht, die Palette, die Sendung usw. durch die Kette des Transportprozesses mit mehreren Parteien bewegt, können verschiedene Ereignisse abgelegt werden. Beispielsweise können die Teilnehmer 402 Ereignisdaten auf den Berechtigungsdienst 422 oder andere Dienste hochladen. Die Ereignisdaten können in der Blockchain 410 abgelegt werden, oder sie können gehasht und als gehashte Daten 414 in der Blockchain abgelegt und in eine Ablage 428 außerhalb der Kette geschrieben werden, um die Ablage in der Blockchain 410 zu schonen. Ebenso können Dokumente von den Teilnehmern 402 empfangen und in der Blockchain 410 abgelegt werden, oder ein Hash der Dokumente kann in der Blockchain 410 innerhalb der gehashten Daten 414 abgelegt werden, und das Dokument selber kann in der Ablage 428 außerhalb der Kette abgelegt werden.
  • Wenn dabei eine Benutzervorrichtung 404 auf die Daten/Dokumente des Transportprozesses mit mehreren Parteien zugreift, kann ihr Zugriff durch den Zugriffskontrolldienst 424 kontrolliert werden. Hierbei kann der Zugriffskontrolldienst 424 den Zugriff auf die Daten und die Dokumente basierend auf Lese-/Schreib-Berechtigungen eines entsprechenden Teilnehmers, die von dem Rollenbestimmungsdienst 426 zugeteilt werden, kontrollieren. Daraufhin kann jeder Teilnehmer (und seine Benutzer) an dem System nur auf die Daten zugreifen, auf die er zugreifen darf. Bei einigen Ausführungsformen kann die Logik für den Rollenbestimmungsdienst 426 und den Zugriffskontrolldienst 424 unter Verwendung intelligenter Verträge umgesetzt werden.
  • Durch dynamisches Kombinieren der Organisations- und Parteirolle auf jeder Ebene der Sendungshierarchie mit der Geltendmachung von Berechtigungen für die Parteirollen für verschiedene Meilensteine der Sendung und für verschiedene Handelsdokumente ist das System in der Lage, Berechtigungen für den Zugriff (Lesen/Schreiben) mit Daten auf eine gegebene Sendung abzuleiten und durchzusetzen. Beispielsweise kann der abgeleitete Zugriff bestimmen, dass ein Seefrachtführer ein Frachtbriefdokument für eine Sendung hochladen kann, doch ein Binnentransportdienst (Lastwagenfahrer) keinen Zugriff auf dieses Dokument hat. Das gesamte System besteht aus den Diensten 422, 424 und 426, welche die Berechtigungsinformationen ableiten und sie dann als Teil des Zugriffs auf die Objekte aus dem Handelssystem durchsetzen, wozu Meilensteinereignisse und Dokumente gehören.
  • 4B bildet eine Zuordnung 440 zwischen Teilnehmerarten 442 und Teilnehmerrollen 444 gemäß Ausführungsbeispielen ab. Mit Bezug auf 4B können Organisationen, die zu einem Transportprozess mit mehreren Parteien gehören, einer bestimmten Teilnehmerart 442 zugeteilt werden. Die Beispiele der Teilnehmerarten 442 in 4B sind nicht als erschöpfend anzusehen, und es sind andere Teilnehmerarten möglich. Teilnehmerarten können zugeteilt werden, wenn sich eine Organisation bei dem System registriert. Außerdem kann, wenn ein neues Transportobjekt empfangen wird (das eine neue Sendung/ einen neuen Transport identifiziert), der Rollenbestimmungsdienst 426 jedem identifizierten Teilnehmer in dem Transportobjekt einer oder mehreren Teilnehmerrollen 444 zuteilen. Wie in 4B gezeigt, können die Teilnehmerarten 442 einer Vielzahl von verschiedenen Teilnehmerrollen 444 zugeordnet werden. Außerdem können einige Teilnehmerarten 442 den gleichen Teilnehmerrollen 444 zugeordnet werden. Gemäß diversen Ausführungsformen kann der Rollenbestimmungsdienst 426 bestimmen, welche Teilnehmerrolle 444 jedem Teilnehmer basierend auf Daten, die von dem Rollenbestimmungsdienst 426 aus Handelsdokumenten des Transportprozesses mit mehreren Parteien gelesen werden, Sendungsinformationen, die von dem Kunden bereitgestellt werden, und dergleichen zugeteilt werden soll.
  • 4C bildet eine Tabelle 450 ab, die Zugriffsrechte auf Dokumente 456 basierend auf Rollen gemäß Ausführungsbeispielen ablegt. Mit Bezug auf 4C werden Beispiele von Zugriffsrechten für zwei Arten von Teilnehmern 452 (Seefrachtführer und Binnentransporter) gezeigt. Wie gezeigt, kann jede Teilnehmerart 452 eine Vielzahl von verschiedenen Rollen 454 einschließen, wobei jeder der Rollen individuelle Zugriffsrechte zugeteilt sein können. Folglich können die verschiedenen Rollen 454 verschiedene Zugriffsrechte auf die Dokumente 456 haben. Obwohl dies in 4C nicht gezeigt ist, können die Zugriffsrechte für alle Teilnehmerarten und Rollen durch den Berechtigungsdienst 422 abgelegt und verwaltet werden, und können für den Zugriffskontrolldienst 424 zugänglich sein.
  • 4D bildet einen Prozess 400D des dynamischen Bestimmens von Lese- und Schreib-Berechtigungen für Dokumente und Ereignisse gemäß Ausführungsbeispielen ab. Mit Bezug auf 4D empfängt der Rollenbestimmungsdienst 426 die Sendungsinformationen 436 von einer oder mehreren Parteien der Sendung. Als ein anderes Beispiel können die Sendungsinformationen 436 durch die Plattform aus Ereignissen und Dokumenten, die von mehreren Parteien der Sendung empfangen werden, zusammengestellt werden. Der Rollenbestimmungsdienst 426 kann die Dokumente, die empfangenen Informationen und dergleichen prüfen und eine Vielzahl von Teilnehmern 461 bis 465 identifizieren. Außerdem kann der Rollenbestimmungsdienst 426 Rollen für jeden der Teilnehmer 461 bis 465 dynamisch zuteilen. Basierend auf den dynamisch zugeteilten Rollen kann der Rollenbestimmungsdienst 426 auch Dokumente 471 und Ereignisse 472 identifizieren, auf die ein Teilnehmer Zugriff hat. Die dynamischen Zuteilungen der Teilnehmer 461 bis 465 und ihrer Rollen, Berechtigungen usw. können in der Blockchain 410 als Objektdaten 412 abgelegt werden und durch den Zugriffskontrolldienst 424 verwendet werden, um den Zugriff auf die Daten des Transportprozesses mit mehreren Parteien zu verwalten/kontrollieren.
  • 5 bildet ein Verfahren 500 zum dynamischen Bestimmen von Lese- und Schreib-Berechtigungen gemäß Ausführungsbeispielen ab. Mit Bezug auf 5 kann das Verfahren bei 510 das Empfangen von Transportdaten eines Transportprozesses mit mehreren Parteien einschließen. Beispielsweise können die Transportdaten einen Ursprung, ein Ziel, Sende-/ Transport-Entitäten, vermittelnde Entitäten, Häfen, Zollentitäten, Käufer, Verkäufer und dergleichen identifizieren. Als ein anderes Beispiel können die Transportdaten aus Dokumenten entnommen werden, die bei 510 empfangen werden, wie etwa aus einer Rechnung, einem Frachtbrief, einem Seefrachtbrief und dergleichen.
  • Bei 520 kann das Verfahren das Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten einschließen. Die Dokumente können ein beliebiges Dokument einschließen, das mit den Parteien des Transportprozesses mit mehreren Parteien verknüpft ist. Die Ereignisse (auch als Meilensteine bezeichnet) können containerbasierte Ereignisse einschließen, die vorkommen, wenn sich ein Container von einem Standort zum anderen bewegt.
  • Bei 530 kann das Verfahren das dynamische Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen einschließen. Beispielsweise kann das dynamische Bestimmen das Ableiten von Berechtigungen zum Lesen und Schreiben von Daten in die Blockchain für eine Vielzahl von Parteien, die zu dem Transportprozess mit mehreren Parteien gehören, basierend auf vordefinierten Rollen, die den Parteien durch den Kettencode der Blockchain zugeordnet sind, einschließen. Bei einigen Ausführungsformen kann das dynamische Bestimmen der Lese- und Schreib-Berechtigungen ferner basierend auf einem Ursprung, einem Ziel und einem oder mehreren Zwischenstandorten des Transportprozesses mit mehreren Parteien bestimmt werden. Bei 540 kann das Verfahren ferner das Ablegen einer Kennung des Transportprozesses mit mehreren Parteien und das dynamische Bestimmen von Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain einschließen.
  • Bei einigen Ausführungsformen kann das Verfahren das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Gewähren der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, einschließen. Bei einigen Ausführungsformen kann das Verfahren ferner das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Verweigern der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, einschließen. Bei einigen Ausführungsformen kann das Verfahren ferner das Empfangen einer Aktualisierung von Ereignisdaten des Prozesses mit mehreren Parteien und das Ablegen der Aktualisierung von Ereignisdaten und der Lese- und Schreib-Berechtigungen für die Aktualisierung von Ereignisdaten in einem Block in der Blockchain einschließen. Bei einigen Ausführungsformen kann die Aktualisierung von Ereignisdaten eine Änderung an einem zuvor abgelegten Dokument einschließen. Bei einigen Ausführungsformen kann die Aktualisierung von Ereignisdaten eine Änderung an zuvor bestimmten Lese- und Schreib-Berechtigungen für ein Ereignis und seine Daten einschließen.
  • 6A bildet ein beispielhaftes System 600, das eine räumliche Infrastruktur 610 einschließt, die konfiguriert ist, um diverse Vorgänge auszuführen, gemäß Ausführungsbeispielen ab. Mit Bezug auf 6A schließt die räumliche Infrastruktur 610 ein Modul 612 und ein Modul 614 ein. Das Modul 614 schließt eine Blockchain 620 und einen intelligenten Vertrag 630 (der sich in der Blockchain 620 befinden kann) ein, der beliebige der Betriebsschritte 608 (in Modul 612), die in beliebigen der Ausführungsbeispiele enthalten sind, ausführen kann. Die Schritte/Vorgänge 608 können eine oder mehrere der beschriebenen oder dargestellten Ausführungsformen einschließen und können ausgegebene oder schriftliche Informationen darstellen, die in einen oder mehrere intelligente Verträge 630 und/oder Blockchains 620 geschrieben oder daraus gelesen werden. Die räumliche Infrastruktur 610, das Modul 612 und das Modul 614 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Kommunikationsvorrichtungen einschließen. Ferner können das Modul 612 und das Modul 614 das gleiche Modul sein.
  • 6B bildet ein anderes beispielhaftes System 640, das konfiguriert ist, um diverse Vorgänge auszuführen, gemäß Ausführungsbeispielen ab. Mit Bezug auf 6B schließt das System 640 ein Modul 612 und ein Modul 614 ein. Das Modul 614 schließt eine Blockchain 620 und einen intelligenten Vertrag 630 (der sich in der Blockchain 620 befinden kann) ein, der einen beliebigen der Betriebsschritte 608 (in Modul 612), die in einem beliebigen der Ausführungsbeispiele enthalten sind, ausführen kann. Die Schritte/Vorgänge 608 können eine oder mehrere der beschriebenen oder dargestellten Ausführungsformen einschließen und können ausgegebene oder schriftliche Informationen darstellen, die in einen oder mehrere intelligente Verträge 630 und/oder Blockchains 620 geschrieben oder daraus gelesen werden. In den Beispielen aus 6A und 6B können die räumliche Infrastruktur 610, das Modul 612 und das Modul 614 einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Kommunikationsvorrichtungen einschließen. Ferner können das Modul 612 und das Modul 614 das gleiche Modul sein.
  • 6C bildet gemäß Ausführungsbeispielen ein beispielhaftes System ab, das konfiguriert ist, um eine intelligente Vertragskonfiguration zwischen den Vertragsbeteiligten und einem vermittelnden Server, der konfiguriert ist, um die intelligenten Vertragsbedingungen in der Blockchain durchzusetzen, zu verwenden. Mit Bezug auf 6C kann die Konfiguration 650 eine Kommunikationssitzung, eine Anlagenübertragungssitzung oder einen Prozess oder eine Vorgehensweise einschließen, der bzw. die durch einen intelligenten Vertrag 630 getrieben wird, der ausdrücklich eine oder mehrere Benutzervorrichtungen 652 und/oder 656 identifiziert. Die Ausführung, die Vorgänge und die Ergebnisse der Ausführung des intelligenten Vertrags können von einem Server 654 verwaltet werden. Der Inhalt des intelligenten Vertrags 630 kann digitale Signaturen von einer oder mehreren der Entitäten 652 und 656 benötigen, die an der intelligenten Vertragstransaktion beteiligt sind. Die Ergebnisse der Ausführung des intelligenten Vertrags können als Blockchain-Transaktion in eine Blockchain 620 geschrieben werden. Der intelligente Vertrag 630 befindet sich in der Blockchain 620, die sich auf einem oder mehreren Computern, Servern, Prozessoren, Speichern und/oder drahtlosen Kommunikationsvorrichtungen befinden kann.
  • 6D bildet ein System 660, das eine Blockchain einschließt, gemäß Ausführungsbeispielen ab. Mit Bezug auf das Beispiel aus 6D stellt ein Anwendungsprogrammierschnittstellen- (API) Gateway 662 eine gemeinsame Schnittstelle für den Zugriff auf die Blockchain-Logik (z. B. den intelligenten Vertrag 630 oder einen anderen Kettencode) und Daten (z. B. das verteilte Hauptbuch usw.) bereit. Bei diesem Beispiel ist das API-Gateway 662 eine gemeinsame Schnittstelle zum Ausführen von Transaktionen (Aufrufen, Abfragen usw.) in der Blockchain durch das Verbinden von einer oder mehrerer Entitäten 652 und 656 mit einem Blockchain-Peer (d. h. einem Server 654). Hierbei ist der Server 654 eine Blockchain-Netzwerk-Peer-Komponente, die eine Kopie des Weltzustands und ein verteiltes Hauptbuch enthält, die es den Clients 652 und 656 ermöglichen, Daten über den Weltzustand abzufragen sowie Transaktionen in das Blockchain-Netzwerk einzureichen, wobei in Abhängigkeit von dem intelligenten Vertrag 630 und der Indossamentrichtlinie indossierende Peers die intelligenten Verträge 630 ausführen.
  • Die obigen Ausführungsformen können als Hardware, als Computerprogramm, das von einem Prozessor ausgeführt wird, als Firmware oder in einer Kombination davon ausgeführt werden. Ein Computerprogramm kann auf einem computerlesbaren Medium, wie etwa einem Ablagemedium ausgebildet sein. Beispielsweise kann sich ein Computerprogramm in einem Arbeitsspeicher („RAM“), einem Flash-Speicher, einem Festspeicher („ROM“), einem löschbaren programmierbaren Festspeicher („EPROM“), einem elektrisch löschbaren programmierbaren Festspeicher („EEPROM“), Registern, einer Festplatte, einer Wechselplatte, einem Compact-Disk-Festspeicher („CD-ROM“) oder einer beliebigen anderen Form von Ablagemedium, das in der Technik bekannt ist, vorliegen.
  • Ein beispielhaftes Ablagemedium kann mit dem Prozessor derart gekoppelt sein, dass der Prozessor Informationen aus dem Ablagemedium lesen und Informationen darauf schreiben kann. Alternativ kann das Ablagemedium in den Prozessor integriert sein. Der Prozessor und das Ablagemedium können sich in einer anwendungsspezifischen integrierten Schaltung („ASIC“) befinden. Alternativ können der Prozessor und das Ablagemedium als diskrete Komponenten vorliegen.
  • 7A bildet einen Prozess 700, bei dem ein neuer Block zu einem verteilten Hauptbuch 720 hinzugefügt wird, gemäß Ausführungsbeispielen ab, und 7B bildet den Inhalt einer neuen Datenblockstruktur 730 für die Blockchain gemäß Ausführungsbeispielen ab. Mit Bezug auf 7A können Clients (nicht gezeigt) Transaktionen an Blockchain-Knoten 711, 712 und/oder 713 einreichen. Die Clients können Anweisungen sein, die von einer beliebigen Quelle empfangen werden, um die Aktivität in der Blockchain 720 zu verordnen. Als ein Beispiel können Clients Anwendungen sein, die im Namen eines Antragsstellers agieren, wie etwa einer Vorrichtung, einer Person oder einer Entität, um Transaktionen für die Blockchain vorzuschlagen. Die Vielzahl von Blockchain-Peers (z. B. die Blockchain-Knoten 711, 712 und 713) kann einen Zustand des Blockchain-Netzwerks und eine Kopie des verteilten Hauptbuch 720 pflegen. Verschiedene Arten von Blockchain-Knoten/Peers können in dem Blockchain-Netzwerk vorliegen, wozu indossierende Peers gehören, die Transaktionen simulieren und indossieren, die von Clients und festschreibenden Peers vorgeschlagen werden, die Indossamente verifizieren, Transaktionen validieren und Transaktionen in dem verteilten Hauptbuch 720 festschreiben. Bei diesem Beispiel können die Blockchain-Knoten 711, 712 und 713 die Rolle eines Indossantenknotens, eines Committer-Knotens oder beiden ausführen.
  • Das verteilte Hauptbuch 720 umfasst eine Blockchain, die unveränderliche, sequenzierte Einträge in Blöcken ablegt, und eine Zustandsdatenbank 724 (aktueller Weltzustand), die einen aktuellen Zustand der Blockchain 722 pflegt. Ein verteiltes Hauptbuch 720 kann pro Kanal existieren, und jeder Peer pflegt seine eigene Kopie des verteilten Hauptbuchs 720 für jeden Kanal, von dem er Mitglied ist. Die Blockchain 722 ist ein Transaktionslogbuch, das als Hash-verlinkte Blöcke strukturiert ist, wobei jeder Block eine Sequenz von N Transaktionen einschließt. Die Blöcke können diverse Komponenten und Transaktionen einschließen, wie etwa in 7B gezeigt. Die Verlinkung der Blöcke (in 7A durch Pfeile gezeigt) kann generiert werden, indem ein Hash einer Kopfzeile eines vorherigen Blocks innerhalb einer Blockkopfzeile eines aktuellen Blocks generiert wird. Auf diese Art und Weise werden alle Transaktionen in der Blockchain 722 sequenziert und kryptografisch miteinander verlinkt, was eine Manipulation der Blockchain-Daten verhindert, ohne die Hash-Links zu unterbrechen. Außerdem stellt der neueste Block in der Blockchain 722 wegen der Links jede vorhergehende Transaktion dar. Die Blockchain 722 kann in einem Peer-Dateisystem (lokale oder angehängte Ablage) abgelegt sein, das eine Nur-Anhänge-Blockchain-Nutzlast unterstützt.
  • Der aktuelle Zustand der Blockchain 722 und des verteilten Hauptbuchs 722 kann in der Zustandsdatenbank 724 abgelegt sein. Hierbei stellen die aktuellen Zustandsdaten die neuesten Werte für alle Schlüssel dar, die jemals in dem Kettentransaktionslogbuch der Blockchain 722 enthalten waren. Kettencodeaufrufe führen Transaktionen gegenüber dem aktuellen Zustand in der Zustandsdatenbank 724 aus. Um diese Kettencodeinteraktionen extrem wirksam zu machen, werden die neuesten Werte aller Schlüssel in der Zustandsdatenbank 724 abgelegt. Die Zustandsdatenbank 724 kann einen indexierten Blick auf das Transaktionslogbuch der Blockchain 722 einschließen, sie kann daher jederzeit aus der Kette regeneriert werden. Die Zustandsdatenbank 724 kann beim Hochfahren eines Peers, bevor Transaktionen angenommen werden, automatisch wiederhergestellt werden (oder bei Bedarf generiert werden).
  • Die indossierenden Knoten empfangen Transaktionen von Clients und indossieren die Transaktion basierend auf simulierten Ergebnissen. Die indossierenden Knoten enthalten intelligente Verträge, welche die Transaktionsvorschläge simulieren. Wenn ein indossierender Knoten eine Transaktion indossiert, erstellen die indossierenden Knoten ein Transaktionsindossament, das eine signierte Antwort von dem indossierenden Knoten an die Client-Anwendung ist, die das Indossament der simulierten Transaktion angibt. Das Verfahren des Indossierens einer Transaktion ist von einer Indossamentrichtlinie abhängig, die in dem Kettencode vorgegeben sein kann. Ein Beispiel einer Indossamentrichtlinie ist „die Mehrheit der indossierenden Peers muss die Transaktion indossieren“. Verschiedene Kanäle können unterschiedliche Indossamentrichtlinien aufweisen. Indossierte Transaktionen werden von der Client-Anwendung an den Ordnungsdienst 710 weitergeleitet.
  • Der Ordnungsdienst 710 nimmt indossierte Transaktionen an, ordnet sie in einen Block und liefert die Blöcke an die festschreibenden Peers. Beispielsweise kann der Ordnungsdienst 710 einen neuen Block einleiten, wenn eine Schwelle von Transaktionen erreicht wurde, ein Zeitgeber abgelaufen oder eine andere Bedingung erfüllt ist. Bei dem Beispiel aus 7A ist der Blockchain-Knoten 712 ein festschreibender Peer, der einen neuen Datenblock 730 zur Ablage in der Blockchain 720 empfangen hat. Der erste Block in der Blockchain kann als Genesis-Block bezeichnet werden, der Information über die Blockchain, ihre Mitglieder, die darin abgelegten Daten abgelegt usw. einschließt.
  • Der Ordnungsdienst 710 kann aus einem Cluster von Ordnern bestehen. Der Ordnungsdienst 710 verarbeitet keine Transaktionen, intelligenten Verträge oder pflegt das geteilte Hauptbuch. Vielmehr kann der Ordnungsdienst 710 die indossierten Transaktionen annehmen und gibt die Reihenfolge vor, in der diese Transaktionen in dem verteilten Hauptbuch 720 festgeschrieben werden. Die Architektur des Blockchain-Netzwerks kann derart ausgelegt sein, dass die spezifische Umsetzung des „Ordnens“ (z. B. Solo, Kafka, BFT usw.) zu einer einfügbaren Komponente wird.
  • Die Transaktionen werden in einer zusammenhängenden Reihenfolge in das verteilte Hauptbuch 720 geschrieben. Die Reihenfolge der Transaktionen wird erstellt, um sicherzustellen, dass die Aktualisierungen der Zustandsdatenbank 724 gültig sind, wenn sie in dem Netzwerk festgeschrieben werden. Anders als bei einem Kryptowährungs-Blockchain-System (z. B. Bitcoin usw.), bei dem das Ordnen durch das Lösen eines kryptografischen Rätsels oder durch Mining erfolgt, können die Parteien des verteilten Hauptbuchs 720 bei diesem Beispiel den Ordnungsmechanismus wählen, der am besten zu diesem Netzwerk passt.
  • Wenn der Ordnungsdienst 710 einen neuen Datenblock 730 initialisiert, kann der neue Datenblock 730 an festschreibende Peers (z. B. die Blockchain-Knoten 711, 712 und 713) rundgesendet werden. Daraufhin validiert jeder festschreibende Peer die Transaktion in dem neuen Datenblock 730, indem er überprüft, dass der Lesesatz und der Schreibsatz immer noch mit dem aktuellen Weltzustand in der Zustandsdatenbank 724 übereinstimmen. Insbesondere kann der festschreibende Peer bestimmen, ob die gelesenen Daten, die existierten, als die Indossanten die Transaktion simulierten, mit dem aktuellen Weltzustand in der Zustandsdatenbank 724 identisch ist. Wenn der festschreibende Peer die Transaktion validiert, wird die Transaktion in die Blockchain 722 in dem verteilten Hauptbuch 720 geschrieben, und die Zustandsdatenbank 724 wird mit den geschriebenen Daten aus dem Lese-/Schreib-Satz aktualisiert. Falls eine Transaktion fehlschlägt, d. h. falls der festschreibende Peer herausfindet, dass der Lese-/Schreib-Satz nicht mit dem aktuellen Weltzustand in der Zustandsdatenbank 724 übereinstimmt, wird die Transaktion, die zu einem Block geordnet wurde, dennoch in diesen Block eingefügt, wird jedoch als ungültig markiert, und die Zustandsdatenbank 724 wird nicht aktualisiert.
  • Mit Bezug auf 7B kann ein neuer Datenblock 730 (auch als Datenblock bezeichnet), der in der Blockchain 722 des verteilten Hauptbuchs 720 abgelegt ist, mehrere Datensegmente einschließen, wie etwa eine Blockkopfzeile 740, Blockdaten 750 und Blockmetadaten 760. Es versteht sich, dass die diversen dargestellten Blöcke und ihr Inhalt, wie etwa der neue Datenblock 730 und sein Inhalt, in 7B gezeigt, nur Beispiele sind und nicht dazu gedacht sind, den Umfang der Ausführungsbeispiele einzuschränken. Der neue Datenblock 730 kann Transaktionsinformationen von N Transaktionen (z. B. 1, 10, 100, 500, 1000, 2000, 3000 usw.) in den Blockdaten 750 ablegen. Der neue Datenblock 730 kann auch einen Link zu einem vorhergehenden Block (z. B. in der Blockchain 722 in 7A) innerhalb der Blockkopfzeile 740 einschließen. Insbesondere kann die Blockkopfzeile 740 einen Hash einer Kopfzeile eines vorhergehenden Blocks einschließen. Die Blockkopfzeile 740 kann auch eine einzigartige Blocknummer, einen Hash der Blockdaten 750 des neuen Datenblocks 730 und dergleichen einschließen. Die Blocknummer des neuen Datenblocks 730 kann einzigartig sein und in diversen Reihenfolgen zugeteilt sein, wie etwa in einer inkrementalen/sequentiellen Reihenfolge, die mit Null beginnt.
  • Die Blockdaten 750 können Transaktionsinformationen jeder Transaktion, die in dem neuen Datenblock 730 eingetragen ist, speichern. Beispielsweise können die Transaktionsdaten eines oder mehrere von einer Art der Transaktion, einer Version, einem Zeitstempel, einer Kanal-ID des verteilten Hauptbuchs 720, einer Transaktions-ID, einer Epoche, einer Nutzlastsichtbarkeit, einem Kettencodepfad (TX Einsetzen), einem Kettencodenamen, einer Kettencodeversion, einer Eingabe (Kettencode und Funktionen), einer Client- (Erzeuger-) Identifizierung, wie etwa einem öffentlichen Schlüssel und einem Zertifikat, einer Signatur des Clients, Identitäten von Indossanten, Signaturen von Indossanten, einem Vorschlag-Hash, Kettencodeereignissen, einem Antwortstatus, einem Namensraum, einem Lesesatz (Liste mit Schlüssel und Version, die von der Transaktion gelesen wird, usw.), einem Schreibsatz (Liste mit Schlüssel und Wert usw.), einem Startschlüssel, einem Endschlüssel, einer Schlüsselliste, einer Hash-Baumabfragezusammenfassung, und dergleichen speichern. Die Transaktionsdaten können für jede der N Transaktionen abgelegt werden.
  • Gemäß diversen Ausführungsformen können die Blockdaten 750 auch stromabwärtige Transportdaten 752 speichern, die eine Kennung einer Sendung/ eines Transports, Kennungen der Parteien, die zu dem Transport gehören, die Rollen der Parteien, Berechtigungen zum Lesen und Schreiben, die den Parteien gewährt wurden (wie etwa Dokumente, Ereignisdaten usw.) und dergleichen einschließen. Die Transportdaten 752 können verwendet werden, um zu verifizieren, dass ein Benutzer, der Zugriff auf Transportinformationen anfragt, basierend auf den Berechtigungen, die in den Transportdaten 752 abgelegt sind, auf diese Daten zugreifen darf. Die Transportdaten 752 schließen einen oder mehrere der Schritte, Merkmale, Prozesse und/oder Aktionen ein, die hier beschrieben oder dargestellt sind. Entsprechend können die Transportdaten 752 in einem unveränderlichen Logbuch von Blöcken in dem verteilten Hauptbuch 720 abgelegt werden. Einige der Vorzüge des Ablegens der Transportdaten 752 in der Blockchain sind in den diversen hier offenbarten und dargestellten Ausführungsformen wiedergegeben.
  • Die Blockmetadaten 760 können mehrere Felder von Metadaten (z. B. als Byte-Array usw.) speichern. Die Metadatenfelder können eine Signatur bei der Blockerstellung, eine Referenz auf einen letzten Konfigurationsblock, einen Transaktionsfilter, der gültige und ungültige Transaktionen in dem Block identifiziert, den letzten bestehenden Versatz eines Ordnungsdienstes, der den Block geordnet hat, und dergleichen einschließen. Die Signatur, der letzte Konfigurationsblock und die Ordnermetadaten können von dem Ordnungsdienst 710 hinzugefügt werden. Dabei kann ein Committer des Blocks (wie etwa der Blockchain-Knoten 712) Gültigkeits-/Ungültigkeitsinformationen basierend auf einer Indossamentrichtlinie, einer Verifizierung von Lese-/Schreib-Sätzen und dergleichen hinzufügen. Der Transaktionsfilter kann ein Byte-Array einer Größe gleich der Anzahl von Transaktionen in den Blockdaten 750 und einen Validierungscode, der identifiziert, ob eine Transaktion gültig/ungültig war, einschließen. Bei einigen Ausführungsformen, obwohl in 7B nicht gezeigt, können die Blockmetadaten 760 Metadaten der empfohlenen intelligenten Verträge darin speichern.
  • 7C bildet eine Ausführungsform einer Blockchain 770 für digitalen Inhalt gemäß den hier beschriebenen Ausführungsformen ab. Der digitale Inhalt kann eine oder mehrere Dateien und verknüpfte Informationen einschließen. Die Dateien können Medien, Bilder, Videomaterial, Audiomaterial, Text, Links, Grafiken, Animationen, Web-Seiten, Dokumente oder andere Formen von digitalem Inhalt einschließen. Die unveränderlichen Nur-Anhänge-Aspekte der Blockchain dienen als Schutzmaßnahme, um die Integrität, Gültigkeit und Authentizität des digitalen Inhalts zu schützen, wodurch er zur Verwendung bei Rechtsverfahren, bei denen Zulässigkeitsregeln gelten, oder in anderen Fällen, bei denen Beweise berücksichtigt werden, oder bei denen die Präsentation und die Verwendung von digitalen Informationen anderweitig interessant ist, geeignet ist. In diesem Fall kann der digitale Inhalt als digitaler Beweis bezeichnet werden.
  • Die Blockchain kann auf diverse Art und Weise gebildet werden. Bei einer Ausführungsform kann der digitale Inhalt in der Blockchain selber enthalten und von dieser aus zugänglich sein. Beispielsweise kann jeder Block der Blockchain einen Hash-Wert von Referenzinformationen (z. B. Kopfzeile, Wert usw.) zusammen mit dem verknüpften digitalen Inhalt speichern. Der Hash-Wert und der verknüpfte digitale Inhalt können dann zusammen verschlüsselt werden. Somit kann auf den digitalen Inhalt jedes Blocks zugegriffen werden, indem jeder Block in der Blockchain entschlüsselt wird, und der Hash-Wert jedes Blocks kann als Grundlage verwendet werden, um einen vorhergehenden Block zu referenzieren. Dies kann folgendermaßen erläutert werden:
    Block 1 Block 2 . . . . . . . Block N
    Hash-Wert 1 Hash-Wert 2 Hash-Wert N
    Digitaler Inhalt 1 Digitaler Inhalt 2 Digitaler Inhalt N
  • Bei einer Ausführungsform ist der digitale Inhalt vielleicht nicht in der Blockchain enthalten. Beispielsweise kann die Blockchain die verschlüsselten Hashes des Inhalts jedes Blocks ohne jeglichen digitalen Inhalt speichern. Der digitale Inhalt kann in einem anderen Ablagebereich oder an einer anderen Speicheradresse in Verbindung dem Hash-Wert der ursprünglichen Datei abgelegt werden. Der andere Ablagebereich kann die gleiche Ablagevorrichtung sein, die verwendet wird, um die Blockchain abzulegen, oder kann ein anderer Ablagebereich oder sogar eine separate relationale Datenbank sein. Der digitale Inhalt jedes Blocks kann referenziert werden bzw. zugänglich sein, indem der Hash-Wert eines interessierenden Blocks erzielt oder abgefragt wird und dann dieser Hash-Wert in dem Ablagebereich gesucht wird, der in Übereinstimmung mit dem tatsächlichen digitalen Inhalt abgelegt ist. Dieser Vorgang kann beispielsweise von einem Datenbankwächter ausgeführt werden. Dies kann folgendermaßen erläutert werden:
    Blockchain Ablagebereich
    Block1 -Hash-Wert Block1-Hash-Wert ... Inhalt
    · ·
    · ·
    · ·
    BlockN-Hash-Wert BlockN-Hash-Wert ... Inhalt
  • Bei dem Ausführungsbeispiel aus 7C umfasst die Blockchain 770 eine Anzahl von Blöcken 7781, 7782, ... 778N, die kryptografisch in einer geordneten Sequenz verlinkt sind, wobei N ≥ 1. Die Verschlüsselung, die verwendet wird, um die Blöcke 7781, 7782, ... 778N zu verlinken, kann eine beliebige von einer Anzahl von verschlüsselten oder unverschlüsselten Hash-Funktionen sein. Bei einer Ausführungsform werden die Blöcke 7781, 7782, ... 778N einer Hash-Funktion unterzogen, die alphanumerische n-Bit-Ausgaben (wobei n gleich 256 oder eine andere Zahl) aus Eingaben, die auf Informationen in den Blöcken basieren, erzeugt. Beispiele einer derartigen Hash-Funktion schließen ohne Einschränkung einen SHA-artigen (SHA bedeutet „Secured Hash Algorithm“) Algorithmus, einen Merkle-Damgard-Algorithmus, einen HAIFA-Algorithmus, einen Hash-Baum-Algorithmus, einen Nonce-basierten Algorithmus und einen nicht kollisionsresistenten PRF-Algorithmus ein. Bei einer anderen Ausführungsform können die Blöcke 7781, 7782, ..., 778N durch eine Funktion, die anders als eine Hash-Funktion ist, kryptografisch verlinkt werden. Zur Erläuterung erfolgt die nachstehende Beschreibung mit Bezug auf eine Hash-Funktion, z. B. SHA-2.
  • Jeder der Blöcke 7781, 7782, ..., 778N in der Blockchain umfasst eine Kopfzeile, eine Version der Datei und einen Wert. Die Kopfzeile und der Wert sind für jeden Block infolge des Hashens in der Blockchain unterschiedlich. Bei einer Ausführungsform kann der Wert in der Kopfzeile enthalten sein. Wie es nachstehend ausführlicher beschrieben wird, kann die Version der Datei die ursprüngliche Datei oder eine andere Version der ursprünglichen Datei sein.
  • Der erste Block 7781 in der Blockchain wird als Genesis-Block bezeichnet und schließt die Kopfzeile 7721, die ursprüngliche Datei 7741 und einen anfänglichen Wert 7761 ein. Das Hash-Schema, das für den Genesis-Block und in der Tat in allen nachfolgenden Blöcken verwendet wird, kann variieren. Beispielsweise können alle Informationen in dem ersten Block 7781 zusammen und gleichzeitig gehasht werden, oder jede Information oder ein Teil der Informationen in dem ersten Block 7781 kann separat gehasht werden, und dann kann ein Hash der separat gehashten Teile ausgeführt werden.
  • Die Kopfzeile 7721 kann einen oder mehrere anfängliche Parameter einschließen, die beispielsweise eine Versionsnummer, einen Zeitstempel, eine Nonce, eine Root-Information, einen Schwierigkeitsgrad, ein Konsensprotokoll, eine Dauer, ein Medienformat, eine Quelle, beschreibende Schlüsselwörter und/oder andere Informationen, die mit der ursprünglichen Datei 7741 und/oder der Blockchain verknüpft sind, einschließen. Die Kopfzeile 7721 kann automatisch (z. B. durch Blockchain-Netzwerkverwaltungs-Software) oder manuell von einem Blockchain-Teilnehmer generiert werden. Anders als die Kopfzeile in den anderen Blöcken 7782 bis 778N in der Blockchain bezieht sich die Kopfzeile 7721 in dem Genesis-Block nicht auf einen vorhergehenden Block, da es einfach keinen vorhergehenden Block gibt.
  • Die ursprüngliche Datei 7741 in dem Genesis-Block kann beispielsweise Daten entsprechen, wie sie durch eine Vorrichtung aufgenommen werden, mit oder ohne Verarbeitung vor ihrer Einbeziehung in die Blockchain. Die ursprüngliche Datei 7741 wird über die Schnittstelle des Systems von der Vorrichtung, einer Medienquelle oder einem Knoten empfangen. Die ursprüngliche Datei 7741 ist mit Metadaten verknüpft, die beispielsweise durch einen Benutzer, die Vorrichtung und/oder den Systemprozessor, entweder manuell oder automatisch generiert werden können. Die Metadaten können in dem ersten Block 7781 in Verbindung mit der ursprünglichen Datei 7741 enthalten sein.
  • Der Wert 7761 in dem Genesis-Block ist ein anfänglicher Wert, der basierend auf einem oder mehreren einzigartigen Attributen der ursprünglichen Datei 7741 generiert wird. Bei einer Ausführungsform können das eine oder die mehreren einzigartigen Attribute den Hash-Wert für die ursprüngliche Datei 7741, Metadaten für die ursprüngliche Datei 7741 und andere Informationen, die mit der Datei verknüpft sind, einschließen. Bei einer Umsetzung kann der anfängliche Wert 7761 auf den folgenden einzigartigen Attributen basieren:
    • 1) einem mit SHA-2 berechneten Hash-Wert für die ursprüngliche Datei
    • 2) der Ursprungsvorrichtungs-ID
    • 3) dem Anfangszeitstempel für die ursprüngliche Datei
    • 4) dem anfänglichen Ablageort der ursprünglichen Datei
    • 5) der Blockchain-Netzwerkmitglieds-ID für Software zum aktuellen Kontrollieren der ursprünglichen Datei und der verknüpften Metadaten
  • Die anderen Blöcke 7782 bis 778N in der Blockchain weisen ebenfalls Kopfzeilen, Dateien und Werte auf. Anders als der erste Block 7721 schließt jedoch jede der Kopfzeilen 7722 bis 772N in den anderen Blöcken den Hash-Wert eines unmittelbar vorhergehenden Blocks ein. Der Hash-Wert des unmittelbar vorhergehenden Blocks kann nur der Hash der Kopfzeile des vorherigen Blocks oder der Hash-Wert des gesamten vorherigen Blocks sein. Dadurch dass der Hash-Wert eines vorhergehenden Blocks in jedem der verbleibenden Blöcke einbezogen wird, kann eine Verfolgung von dem N. Block zurück zum Genesis-Block (und der verknüpften ursprünglichen Datei) auf Block-für-Block-Basis, wie durch die Pfeile 780 angegeben, ausgeführt werden, um eine prüfbare und unveränderliche Kontrollkette herzustellen.
  • Jede der Kopfzeilen 7722 bis 772N in den anderen Blöcken kann auch andere Informationen, z. B. eine Versionsnummer, einen Zeitstempel, eine Nonce, eine Root-Information, einen Schwierigkeitsgrad, ein Konsensprotokoll und/oder andere Parameter oder Informationen, die mit den entsprechenden Dateien und/oder der Blockchain im Allgemeinen verknüpft sind, einschließen.
  • Die Dateien 7742 bis 774N in den anderen Blöcken können gleich der ursprünglichen Datei sein oder können eine geänderte Version der ursprünglichen Datei in dem Genesis-Block sein, beispielsweise je nach der Art der ausgeführten Verarbeitung. Die Art der ausgeführten Verarbeitung kann von Block zu Block variieren. Die Verarbeitung kann beispielsweise eine beliebige Änderung einer Datei in einem vorhergehenden Block, wie etwa das Zensieren von Informationen oder anderweitiges Ändern des Inhalts, das Entfernen von Informationen aus oder das Hinzufügen oder Anhängen von Informationen zu den/an die Dateien bedingen.
  • Zusätzlich oder alternativ kann die Verarbeitung nur das Kopieren der Datei aus einem vorhergehenden Block, das Ändern eines Ablageorts der Datei, das Analysieren der Datei aus einem oder mehreren vorhergehenden Blöcken, das Bewegen der Datei von einem Ablage- oder Speicherort zum anderen oder das Ausführen einer Aktion mit Bezug auf die Datei der Blockchain und/oder ihre verknüpften Metadaten bedingen. Das Verarbeiten, welches das Analysieren einer Datei bedingt, kann beispielsweise das Anhängen, Einbeziehen oder anderweitige Verknüpfen diverse analytischer, statistischer oder anderer Informationen, die mit der Datei verknüpft sind, einschließen.
  • Die Werte in jedem der anderen Blöcke 7762 bis 776N in den anderen Blöcken sind einzigartige Werte und sind alle anders als ein Ergebnis der ausgeführten Verarbeitung. Beispielsweise entspricht der Wert in einem beliebigen Block einer aktualisierten Version des Wertes in dem vorhergehenden Block. Die Aktualisierung wird in dem Hash des Blocks, dem der Wert zugeteilt ist, wiedergegeben. Die Werte der Blöcke stellen daher eine Angabe davon bereit, welche Verarbeitung in den Blöcken ausgeführt wurde, und ermöglichen auch eine Verfolgung durch die Blockchain zurück zu der ursprünglichen Datei. Diese Verfolgung bestätigt die Kontrollkette der Datei in der gesamten Blockchain.
  • Man nehme beispielsweise den Fall, bei dem Teile der Datei in einem vorherigen Block zensiert, durchgestrichen oder verpixelt werden, um die Identität einer Person zu schützen, die in der Datei gezeigt wird. In diesem Fall schließt der Block, der die zensierte Datei einschließt, Metadaten, die mit der zensierten Datei verknüpft sind, ein z. B. wie die Zensierung ausgeführt wurde, wer die Zensierung ausgeführt hat, Zeitstempel, zu denen die Zensierung(en) erfolgte(n), usw. Die Metadaten können gehasht werden, um den Wert zu bilden. Da die Metadaten für den Block anders als die Informationen sind, die gehasht wurden, um den Wert in dem vorhergehenden Block zu bilden, unterscheiden sich die Werte und können wiederhergestellt werden, wenn sie entschlüsselt werden.
  • Bei einer Ausführungsform kann der Wert eines vorherigen Blocks aktualisiert werden (z. B. kann ein neuer Hash-Wert berechnet werden), um den Wert eines aktuellen Blocks zu bilden, wenn eines oder mehrere der folgenden Ereignisse vorkommen. Der neue Hash-Wert kann bei diesem Ausführungsbeispiel berechnet werden, indem die nachstehend aufgeführten Informationen ganz oder teilweise berechnet werden.
    1. a) ein neuer mit SHA-2 berechneter Hash-Wert, falls die Datei irgendwie verarbeitet wurde (z. B. falls die Datei zensiert, kopiert, abgeändert wurde, falls auf sie zugegriffen wurde oder eine gewisse andere Aktion unternommen wurde)
    2. b) ein neuer Ablageort für die Datei
    3. c) neue Metadaten, die als mit der Datei verknüpft identifiziert werden
    4. d) eine Übertragung des Zugriffs oder der Kontrolle der Datei von einem Blockchain-Teilnehmer auf einen anderen Blockchain-Teilnehmer
  • 7D bildet eine Ausführungsform eines Blocks ab, der die Struktur der Blöcke in der Blockchain 790 gemäß einer Ausführungsform darstellen kann. Der Block, Blockt, schließt eine Kopfzeile 772i, eine Datei 774i und einen Wert 776i ein.
  • Die Kopfzeile 772i umfasst einen Hash-Wert eines vorherigen Blocks Blocki-1 und zusätzliche Referenzinformationen, die beispielsweise beliebige der hier besprochenen Arten von Informationen sein können (z. B. Kopfzeileninformationen, die Referenzen, Kennzeichen, Parameter usw. einschließen). Alle Blöcke referenzieren den Hash eines vorherigen Blocks mit Ausnahme natürlich des Genesis-Blocks. Der Hash-Wert des vorherigen Block kann nur ein Hash der Kopfzeile in dem vorherigen Block oder ein Hash aller oder eines Teils der Informationen in dem vorherigen Block, einschließlich der Datei und Metadaten, sein.
  • Die Datei 774i schließt eine Vielzahl von Daten, wie etwa der Reihe nach Daten 1, Daten 2, ..., Daten N ein. Die Daten sind mit den Metadaten Metadaten 1, Metadaten 2, ..., Metadaten N markiert, die den Inhalt und/oder die Kennzeichen beschreiben, die mit den Daten verknüpft sind. Beispielsweise können die Metadaten für jedes Datenelement Informationen zum Angeben eines Zeitstempels für die Daten, zur Verarbeitung der Daten, Schlüsselwörter, welche die Personen oder andere Inhalte angeben, die in den Daten dargestellt sind, und/oder andere Merkmale, die dabei helfen können, die Gültigkeit und den Inhalt der Datei insgesamt festzustellen, und insbesondere ihre Verwendung als digitale Beweis, beispielsweise wie in Verbindung mit einer nachstehend besprochenen Ausführungsform beschrieben, einschließen. Zusätzlich zu den Metadaten kann jedes Datenelement mit einer Referenz REF1, REF2, ..., REFN auf ein vorheriges Datenelement markiert sein, um Manipulation, Lücken in der Datei und eine sequentielle Referenz über die Datei zu verhindern.
  • Sobald die Metadaten den Daten (z. B. über einen intelligenten Vertrag) zugeteilt wurden, können die Metadaten nicht abgeändert werden, ohne dass sich der Hash ändert, was zum Ungültigmachen leicht zu identifizieren ist. Die Metadaten erstellen somit ein Datenlogbuch mit Informationen, auf das die Teilnehmer in der Blockchain zur Verwendung zugreifen können.
  • Der Wert 776i ist ein Hash-Wert oder ein anderer Wert, der basierend auf einer beliebigen der zuvor besprochenen Arten von Informationen berechnet wird. Beispielsweise kann für jeden gegebenen Block Block; der Wert für diesen Block aktualisiert werden, um die Verarbeitung wiederzugeben, die für diesen Block ausgeführt wurde, z. B. einen neuen Hash-Wert, einen neuen Ablageort, neue Metadaten für die verknüpfte Datei, eine Übertragung von Kontrolle oder Zugriff, eine Kennung oder eine andere hinzuzufügende Aktion oder Information. Obwohl der Wert in jedem Block für die Daten der Datei und der Kopfzeile als von den Metadaten getrennt gezeigt wird, kann der Wert bei einer anderen Ausführungsform teilweise oder insgesamt auf diesen Metadaten basieren.
  • Sobald die Blockchain 770 gebildet ist, kann zu einem beliebigen Zeitpunkt die unveränderliche Kontrollkette für die Datei durch Abfragen der Blockchain nach dem Transaktionsablauf der Werte über die Blöcke erzielt werden. Diese Abfrage bzw. dieser Verfolgungsvorgang kann mit dem Entschlüsseln des Wertes des Blocks, der zuletzt einbezogen wurde (z. B. der neueste (N.) Block) beginnen und dann mit dem Entschlüsseln des Wertes der anderen Blöcke fortfahren, bis der Genesis-Block erreicht ist und die ursprüngliche Datei wiederhergestellt ist. Die Entschlüsselung kann auch das Entschlüsseln der Kopfzeilen und Dateien und der verknüpften Metadaten in jedem Block bedingen.
  • Die Entschlüsselung wird basierend auf der Art der Verschlüsselung, die in jedem Block stattgefunden hat, ausgeführt. Dies kann die Verwendung von privaten Schlüsseln, öffentlichen Schlüsseln oder eines Paars aus einem öffentlichen Schlüssel und einem privaten Schlüssel bedingen. Wenn beispielsweise eine asymmetrische Verschlüsselung verwendet wird, können die Blockchain-Teilnehmer oder ein Prozessor in dem Netzwerk ein Paar aus einem öffentlichen Schlüssel und einem privaten Schlüssel unter Verwendung eines vorbestimmten Algorithmus generieren. Der öffentliche Schlüssel und der private Schlüssel sind miteinander durch eine gewisse mathematische Beziehung verknüpft. Der öffentliche Schlüssel kann öffentlich verteilt werden, um als Adresse zu dienen, um Nachrichten von einem anderen Benutzer, z. B. eine IP-Adresse oder eine Privatadresse, zu empfangen. Der private Schlüssel wird geheim gehalten und verwendet, um Nachrichten digital zu signieren, die an andere Blockchain-Teilnehmer gesendet werden. Die Signatur ist in der Nachricht enthalten, so dass der Empfänger sie unter Verwendung des öffentlichen Schlüssels des Senders verifizieren kann. Auf diese Art und Weise kann der Empfänger sicher sein, dass nur der Sender diese Nachricht gesendet haben kann.
  • Das Generieren eines Schlüsselpaars kann ähnlich wie das Erstellen eines Kontos in der Blockchain sein, ohne sich jedoch wirklich irgendwo registrieren zu müssen. Auch ist jede Transaktion, die in der Blockchain ausgeführt wird, durch den Sender unter Verwendung seines privaten Schlüssels digital signiert. Diese Signatur stellt sicher, dass nur der Besitzer des Kontos die Datei der Blockchain verfolgen und verarbeiten kann (falls dies zum Berechtigungsumfang gehört, der durch einen intelligenten Vertrag bestimmt wird).
  • 8A und 8B bilden zusätzliche Beispiele von Verwendungsfällen für die Blockchain ab, die hier übernommen und verwendet werden können. Insbesondere bildet 8A ein Beispiel 800 einer Blockchain 810 ab, die Daten zum maschinellen Lernen (künstliche Intelligenz) speichert. Das maschinelle Lernen beruht auf riesigen Mengen von historischen Daten (bzw. Trainingsdaten), um Vorhersagemodelle für eine genaue Vorhersage an neuen Daten aufzubauen. Die Software zum maschinellen Lernen (z. B. neuronale Netzwerke usw.) kann oft Millionen von Einträgen durchgehen, um nicht intuitive Muster ausfindig zu machen.
  • Bei dem Beispiel aus 8A baut eine Host-Plattform 820 ein Modell zum maschinellen Lernen für das vorausschauende Überwachen von Anlagen 830 auf und setzt es ein. Hierbei kann die Host-Plattform 820 eine Cloud-Plattform, ein Industrieserver, ein Web-Server, ein PC, eine Benutzervorrichtung und dergleichen sein. Die Anlagen 830 können eine beliebige Art von Anlage (z. B. eine Maschine oder Einrichtung usw.), wie etwa ein Flugzeug, eine Lokomotive, eine Turbine, medizinische Gerätschaften und Einrichtungen, Öl- und Gaseinrichtungen, Boote, Schiffe, Fahrzeuge und dergleichen sein. Als ein anderes Beispiel können die Anlagen 830 nicht greifbare Anlagen sein, wie etwa Aktien, Währungen, digitale Münzen, Versicherung oder dergleichen.
  • Die Blockchain 810 kann verwendet werden, um sowohl einen Trainingsprozess 802 des Modells zum maschinellen Lernen als auch einen Vorhersageprozess 804 basierend auf einem trainierten Modell zum maschinellen Lernen erheblich zu verbessern. Beispielsweise können bei 802, statt dass ein Datenwissenschaftler/Ingenieur oder ein anderer Benutzer die Daten erheben muss, historische Daten von den Anlagen 830 selber (oder über einen Vermittler, nicht gezeigt) in der Blockchain 810 abgelegt werden. Dies kann die Erhebungszeit, die von der Host-Plattform 820 benötigt wird, wenn sie ein Vorhersagemodelltraining ausführt, erheblich reduzieren. Beispielsweise können Daten unter Verwendung von intelligenten Verträgen unmittelbar und zuverlässig direkt von ihrer Ursprungsstelle auf die Blockchain 810 übertragen werden. Durch die Verwendung der Blockchain 810, um die Sicherheit und die Inhaberschaft der erhobenen Daten sicherzustellen, können intelligente Verträge die Daten direkt von den Anlagen an die Personen senden, welche die Daten zum Aufbauen eines Modells zum maschinellen Lernen verwenden. Somit können die Daten von den Anlagen 830 gemeinsam genutzt werden.
  • Die erhobenen Daten können basierend auf einem Konsensmechanismus in der Blockchain 810 abgelegt werden. Der Konsensmechanismus holt (berechtigte Knoten) ein, um sicherzustellen, dass die Daten, die aufgezeichnet werden, verifiziert und fehlerfrei sind. Die aufgezeichneten Daten werden mit einem Zeitstempel versehen, kryptografisch signiert und unveränderlich gemacht. Sie sind daher prüfbar, transparent und sicher. Das Hinzufügen von IoT-Vorrichtungen, die direkt in die Blockchain schreiben, kann in manchen Fällen (z. B. Versorgungskette, Gesundheitswesen, Logistik usw.) sowohl die Frequenz als auch die Richtigkeit der Daten, die aufgezeichnet werden, erhöhen.
  • Außerdem kann das Trainieren des Modells zum maschinellen Lernen an den erhobenen Daten Verfeinerungs- und Testrunden durch die Host-Plattform 820 vornehmen. Jede Runde kann auf zusätzlichen Daten oder auf Daten, von denen zuvor nicht angenommen wurde, dass sie dazu beitragen würden, das Wissen des Modells zum maschinellen Lernen zu erweitern, basieren. Bei 802 können die verschiedenen Trainings- und Testschritte (und die damit verknüpften Daten) durch die Host-Plattform 820 in der Blockchain 810 abgelegt werden. Jede Verfeinerung des Modells zum maschinellen Lernen (z. B. Änderungen von Variablen, Gewichtungen usw.) kann in der Blockchain 810 abgelegt werden. Dies stellt einen verifizierbaren Nachweis davon bereit, wie das Modell trainiert wurde und welche Daten zum Trainieren des Modells verwendet wurden. Wenn die Host-Plattform 820 ein fertig trainiertes Modell erreicht hat, kann das sich ergebende Modell außerdem in der Blockchain 810 abgelegt werden.
  • Nachdem das Modell trainiert wurde, kann es in einer Live-Umgebung eingesetzt werden, in der es Vorhersagen/Entscheidungen basierend auf der Ausführung des fertig trainierten Modells zum maschinellen Lernen vornehmen kann. Beispielsweise kann das Modell zum maschinellen Lernen bei 804 zur bedingungsbasierten Wartung (CBM) für eine Anlage, wie etwa ein Flugzeug, eine Windturbine, eine Gesundheitsversorgungsmaschine und dergleichen, verwendet werden. Bei diesem Beispiel können Daten, die von der Anlage 830 zurückgegeben werden, in das Modell zum maschinellen Lernen eingegeben und verwendet werden, um Ereignisvorhersagen, wie etwa Ausfallereignisse, Fehlercodes und dergleichen, vorzunehmen. Bestimmungen, die durch die Ausführung des Modells zum maschinellen Lernen an der Host-Plattform 820 vorgenommen werden, können in der Blockchain 810 abgelegt werden, um einen prüfbaren/verifizierbaren Nachweis bereitzustellen. Als ein nicht einschränkendes Beispiel kann das Modell zum maschinellen Lernen eine zukünftige Störung/ einen Ausfall an einem Teil der Anlage 830 vorhersagen und einen Alarm oder eine Meldung erstellen, das Teil zu ersetzen. Die Daten, die dieser Entscheidung zugrundeliegen, können von der Host-Plattform 820 in der Blockchain 810 abgelegt werden. Bei einer Ausführungsform können die hier beschriebenen und/oder dargestellten Merkmale und/oder Aktionen an oder mit Bezug auf die Blockchain 810 vorkommen.
  • Neue Transaktionen für eine Blockchain können zu einem neuen Block zusammengestellt und zu einem existierenden Hash-Wert hinzugefügt werden. Dieser wird dann verschlüsselt, um einen neuen Hash für den neuen Block zu erstellen. Dieser wird zu der nächsten Liste mit Transaktionen, wenn diese verschlüsselt werden, hinzugefügt, und so weiter. Das Ergebnis ist eine Kette von Blöcken, die jeweils die Hash-Werte von allen vorhergehenden Blöcken enthalten. Computer, die diese Blöcke speichern, vergleichen regelmäßig ihre Hash-Werte, um sicherzustellen, dass sie alle übereinstimmen. Jeder Computer, der nicht übereinstimmt, verwirft die Einträge, die das Problem verursachen. Dieser Ansatz dient dazu, die Manipulationssicherheit der Blockchain sicherzustellen, ist jedoch nicht perfekt.
  • Eine Möglichkeit, dieses System zu überlisten, besteht darin, dass ein unehrlicher Benutzer die Liste von Transaktionen zu seinen Gunsten ändert, jedoch so, dass der Hash unverändert bleibt. Dies kann durch brutale Gewalt erfolgen, mit anderen Worten, indem ein Eintrag geändert wird, das Ergebnis verschlüsselt wird, und man sieht, ob der Hash-Wert der gleiche ist. Und wenn nicht, indem man es immer wieder versucht, bis man einen Hash findet, der passt. Die Sicherheit von Blockchains basiert auf dem Glauben, dass normale Computer diese Art von brutalen Gewaltangriffen nur in Zeitrahmen vornehmen können, die völlig unrealistisch sind, wie etwa das Alter des Universums. Dagegen sind Quantencomputer viel schneller (mehrere 1000mal schneller) und stellen daher eine viel größere Bedrohung dar.
  • 8B bildet ein Beispiel 850 einer quantensicheren Blockchain 852 ab, die eine Quantenschlüsselverteilung (QKD) umsetzt, um sich vor einem Quantencomputerangriff zu schützen. Bei diesem Beispiel können die Blockchain-Benutzer unter Verwendung von QKD ihre gegenseitigen Identitäten verifizieren. Es werden Informationen unter Verwendung von Quantenteilchen, wie etwa Photonen, die nicht von einem Horcher kopiert werden können, ohne sie zu zerstören, gesendet. Auf diese Art und Weise können sich ein Sender und ein Empfänger über die Blockchain ihrer gegenseitigen Identität sicher sein.
  • Bei dem Beispiel aus 8B sind vier Benutzer 854, 856, 858 und 860 anwesend. Jedes Benutzerpaar kann einen geheimen Schlüssel 862 (d. h. eine QKD) gemeinsam nutzen. Da es bei diesem Beispiel vier Knoten gibt, existieren sechs Knotenpaare, und daher werden sechs verschiedene geheime Schlüssel 862 verwendet, einschließlich QKDAB, QKDAC, QKDAD, QKDBC, QKDBD und QKDCD. Jedes Paar kann eine QKD erstellen, indem es Informationen unter Verwendung von Quantenteilchen, wie etwa Photonen, die von einem Horcher nicht kopiert werden können, ohne sie zu zerstören, sendet. Auf diese Art und Weise kann sich ein Benutzerpaar seiner gegenseitigen Identität sicher sein.
  • Der Betrieb der Blockchain 852 basiert auf zwei Vorgehensweiseen (i) der Erstellung von Transaktionen, und (ii) der Konstruktion von Blöcken, welche die neuen Transaktionen zusammenstellen. Neue Transaktionen können ähnlich wie bei einem herkömmlichen Blockchain-Netzwerk erstellt werden. Jede Transaktion kann Informationen über einen Sender, einen Empfänger, einen Erstellungszeitpunkt, einen zu übertragenden Betrag (oder Wert), eine Liste mit Referenztransaktionen, die rechtfertigt, dass der Sender über Gelder für den Vorgang verfügt, und dergleichen enthalten. Dieser Transaktionseintrag wird dann an alle anderen Knoten gesendet, an denen er in eine Sammlung von nicht bestätigten Transaktionen eingegeben wird. Hierbei authentifizieren zwei Parteien (d. h. ein Benutzerpaar von 854 bis 860) die Transaktion, indem sie ihren gemeinsam genutzten geheimen Schlüssel 862 (QKD) bereitstellen. Diese Quantensignatur kann an jede Transaktion angehängt werden, wodurch es extrem schwierig wird, sie zu manipulieren. Jeder Knoten prüft seine Eingaben im Verhältnis zu einer lokalen Kopie der Blockchain 852, um zu verifizieren, dass jede Transaktion über ausreichende Mittel verfügt. Die Transaktionen sind jedoch noch nicht bestätigt.
  • Statt einen herkömmlichen Mining-Prozess an den Blöcken auszuführen, können die Blöcke dezentral unter Verwendung eines Rundsendeprotokolls erstellt werden. In einem vorbestimmten Zeitraum (z. B. Sekunden, Minuten, Stunden usw.) kann das Netzwerk das Rundsendeprotokoll auf jede nicht bestätigte Transaktion anwenden, um dadurch eine byzantinische Vereinbarung (Konsens) bezüglich einer korrekten Version der Transaktion zu erreichen. Beispielsweise kann jeder Knoten einen privaten Wert besitzen (Transaktionsdaten dieses bestimmten Knotens). In einer ersten Runde übertragen die Knoten ihre privaten Werte aneinander. In nachfolgenden Runden teilen die Knoten die Informationen mit, die sie in der vorherigen Runde von anderen Knoten empfangen haben. Hierbei sind ehrliche Knoten in der Lage, einen kompletten Satz von Transaktionen in einem neuen Block zu erstellen. Dieser neue Block kann zu der Blockchain 852 hinzugefügt werden. Bei einer Ausführungsform können die hier beschriebenen und/oder dargestellten Merkmale und/oder Aktionen in oder mit Bezug auf die Blockchain 852 vorkommen.
  • 9 bildet ein beispielhaftes System 900 ab, das ein oder mehrere der hier beschriebenen und/oder dargestellten Ausführungsbeispiele abbildet. Das System 900 umfasst ein Computersystem/einen Server 902, das bzw. der mit zahlreichen anderen universellen oder speziellen Computersystemumgebungen oder Konfigurationen betriebsfähig ist. Beispiele von wohlbekannten Computersystemen, Umgebungen und/oder Konfigurationen, die zur Verwendung mit dem Computersystem/Server 902 geeignet sein können, schließen ohne Einschränkung persönliche Computersysteme, Server-Computersysteme, Thin Clients, Thick Clients, handgehaltene oder Laptop-Vorrichtungen, Mehrprozessorsysteme, Systeme auf Mikroprozessorbasis, Set-Top-Boxes, programmierbare Verbraucherelektronik, Netzwerk-PCs, Minicomputersysteme, Großrechnersysteme und verteilte Cloud-Computing-Umgebungen ein, die beliebige der obigen Systeme oder Vorrichtungen und dergleichen einschließen.
  • Das Computersystem/ der Server 902 kann im allgemeinen Zusammenhang von computersystemausführbaren Anweisungen, wie etwa Programmmodulen, die von einem Computersystem ausgeführt werden, beschrieben werden. Im Allgemeinen können die Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen und so weiter einschließen, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen umsetzen. Das Computersystem/ der Server 902 kann in verteilten Cloud-Computing-Umgebungen in die Praxis umgesetzt werden, wobei Aufgaben von entfernten Verarbeitungsvorrichtungen ausgeführt werden, die über ein Kommunikationsnetzwerk verlinkt sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch entfernten Computersystemablagemedien befinden, wozu Speicherablagevorrichtungen gehören.
  • Wie in 9 gezeigt, wird das Computersystem/ der Server 902 in dem Cloud-Computing-Knoten 900 als eine universelle Computervorrichtung gezeigt. Die Komponenten des Computersystems/Servers 902 können ohne Einschränkung einen oder mehrere Prozessoren oder eine oder mehrere Verarbeitungseinheiten 904, einen Systemspeicher 906 und einen Bus, der diverse Systemkomponenten, einschließlich des Systemspeichers 906, mit dem Prozessor 904 koppelt, einschließen.
  • Der Bus stellt eine oder mehrere von einer beliebigen von mehreren Arten von Busstrukturen dar, wozu ein Speicherbus oder Speicher-Controller, ein Peripheriebus, ein Accelerated Graphics Port und ein Prozessor oder ein lokaler Bus, der eine beliebige von diversen Busarchitekturen verwendet, gehören. Beispielhaft und nicht einschränkend schließen derartige Architekturen einen ISA-Bus („Industry Standard Architecture“), einen MCA-Bus („Micro Channel Architecture“) Bus, einen Enhanced-ISA- (EISA-) Bus, einen lokalen VESA-Bus („Video Electronics Standards Association“) und einen PCI-Bus („Peripheral Component Interconnect“) Bus ein.
  • Das Computersystem/ der Server 902 schließt typischerweise diverse von dem Computersystem lesbare Medien ein. Diese Medien können beliebige verfügbare Medien sein, die für das Computersystem/ den Server 902 zugänglich sind, und sie schließen sowohl flüchtige als auch nicht flüchtige Medien, abnehmbare als auch nicht abnehmbare Medien ein. Der Systemspeicher 906 setzt bei einer Ausführungsform die Flussdiagramme der anderen Figuren um. Der Systemspeicher 906 kann computersystemlesbare Medien in Form eines flüchtigen Speichers, wie etwa eines Arbeitsspeichers (RAM) 910 und/oder eines Zwischenspeichers 912, einschließen. Das Computersystem/ der Server 902 kann ferner andere abnehmbare/ nicht abnehmbare, flüchtige/ nicht flüchtige Computersystemablagemedien einschließen. Rein beispielhaft kann das Ablagesystem 914 zum Lesen aus und zum Schreiben auf ein nicht abnehmbares, nicht flüchtiges Magnetmedium (nicht gezeigt und typischerweise als „Festplatte“ bezeichnet) bereitgestellt werden. Obwohl dies nicht gezeigt ist, können ein Magnetplattenlaufwerk zum Lesen von und zum Schreiben auf einer abnehmbaren, nicht flüchtigen Magnetplatte (z. B. einer „Diskette“), und ein optisches Laufwerk zum Lesen von oder zum Schreiben auf einer abnehmbaren, nicht flüchtigen optischen Platte, wie etwa einer CD-ROM, einer DVD-ROM, oder ein anderes optisches Medium bereitgestellt werden. In solchen Fällen können sie jeweils durch ein oder mehrere Datenmedienschnittstellen an den Bus angeschlossen werden. Wie es nachstehend ferner dargestellt und beschrieben wird, kann der Speicher 906 mindestens ein Programmprodukt einschließen, das einen Satz von Programmmodulen (z. B. mindestens eines) aufweist, die konfiguriert sind, um die Funktionen von diversen Ausführungsformen der Anwendung auszuführen.
  • Das Programm/Dienstprogramm 916, das einen Satz von Programmmodulen 918 (mindestens eines) aufweist, kann beispielhaft aber nicht einschränkend in dem Speicher 906, sowie ein Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten gespeichert sein. Das Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten oder eine Kombination davon können jeweils eine Umsetzung einer Netzwerkumgebung einschließen. Die Programmmodule 918 führen im Allgemeinen die Funktionen und/oder Methodologien von diversen Ausführungsformen der hier beschriebenen Anwendung aus.
  • Wie es der Fachmann verstehen wird, können die Aspekte der vorliegenden Anwendung als System, Verfahren oder Computerprogrammprodukt ausgebildet sein. Entsprechend können die Aspekte der vorliegenden Anwendung die Form einer Ausführungsform ganz aus Hardware, einer Ausführungsform ganz aus Software (einschließlich Firmware, residenter Software, Mikrocode usw.) oder einer Ausführungsform, die Software- und Hardware-Aspekte kombiniert, die alle im Allgemeinen hier als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können, annehmen. Außerdem können die Aspekte der vorliegenden Anwendung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien ausgebildet ist, auf denen computerlesbarer Programmcode ausgebildet ist.
  • Das Computersystem/ der Server 902 kann auch mit einer oder mehreren externen Vorrichtungen 920 kommunizieren, wie etwa mit einer Tastatur, einer Zeigevorrichtung, einer Anzeige 922 usw.; einer oder mehreren Vorrichtungen, die es einem Benutzer ermöglichen, mit dem Computersystem/Server 902 zu interagieren; und/oder beliebigen Vorrichtungen (z. B. einer Netzwerkkarte, einem Modem usw.), die es dem Computersystem/Server 902 ermöglichen, mit einer oder mehreren anderen Computervorrichtungen zu kommunizieren. Diese Kommunikation kann über E/A-Schnittstellen 924 erfolgen. Ferner kann das Computersystem/ der Server 902 mit einem oder mehreren Netzwerken, wie etwa mit einem lokalen Netzwerk (LAN), einem Großraumnetzwerk (WAN) und/oder einem öffentlichen Netzwerk (z. B. Internet), über einen Netzwerkadapter 926 kommunizieren. Wie dargestellt, kommuniziert der Netzwerkadapter 926 mit den anderen Komponenten des Computersystems/Servers 902 über einen Bus. Es versteht sich, dass obwohl dies nicht gezeigt ist, andere Hardware- und/oder Software-Komponenten in Verbindung mit dem Computersystem/Server 902 verwendet werden könnten. Beispiele schließen ohne Einschränkung: Mikrocode, Vorrichtungstreiber, redundante Verarbeitungseinheiten, externe Laufwerk-Arrays, RAID-Systeme, Bandlaufwerke und Datenarchivablagesysteme usw ein.
  • Obwohl eine beispielhafte Ausführungsform mindestens von einem von einem System, einem Verfahren und einem nicht vorübergehenden computerlesbaren Medium in den beiliegenden Zeichnungen abgebildet wurde und in der vorstehenden ausführlichen Beschreibung beschrieben wurde, versteht es sich, dass die Anwendung nicht auf die offenbarten Ausführungsformen eingeschränkt ist, sondern zu zahlreichen Umgestaltungen, Änderungen und Ersetzungen fähig ist, wie durch die folgenden Ansprüche dargelegt und definiert. Beispielsweise können die Fähigkeiten des Systems der diversen Figuren von einem oder mehreren hier beschriebenen Modulen oder Komponenten oder in einer verteilten Architektur ausgeführt werden und können einen Sender, einen Empfänger oder ein Paar von beiden einschließen. Beispielsweise kann die Funktionalität, die von den einzelnen Modulen ausgeführt wird, ganz oder teilweise von einem oder mehreren dieser Module ausgeführt werden. Ferner kann die hier beschriebene Funktionalität zu diversen Zeitpunkten und mit Bezug auf diverse Ereignisse, intern oder extern gegenüber den Modulen oder Komponenten, ausgeführt werden. Auch können die Informationen, die zwischen diversen Modulen gesendet werden, über mindestens eines von: einem Datennetzwerk, Internet, einem Sprachnetzwerk, einem Internet-Protokoll-Netzwerk, einer drahtlosen Vorrichtung, einer drahtgebundenen Vorrichtung und/oder über eine Vielzahl von Protokollen gesendet werden. Auch können die Nachrichten, die von einem der Module gesendet oder empfangen werden, direkt und/oder über ein oder mehrere der anderen Module gesendet oder empfangen werden.
  • Der Fachmann wird verstehen, dass ein „System“ als PC, Server, Konsole, persönlicher digitaler Assistent (PDA), Mobiltelefon, Tablet-Computer, Smartphone oder als eine beliebige andere geeignete Computervorrichtung oder Kombination von Vorrichtungen ausgebildet sein könnte. Die Präsentation der zuvor beschriebenen Funktionen als von einem „System“ ausgeführt ist nicht dazu gedacht, den Umfang der vorliegenden Anmeldung irgendwie einzuschränken, sondern ist dazu gedacht, ein Beispiel von vielen Ausführungsformen bereitzustellen. In der Tat können die hier offenbarten Verfahren, Systeme und Geräte in lokalisierten und verteilten Formen, die mit der Computertechnologie vereinbar sind, umgesetzt werden.
  • Es sei zu beachten, dass einige der in der vorliegenden Beschreibung beschriebenen Systemmerkmale als Module präsentiert wurden, um insbesondere ihre Umsetzungsunabhängigkeit weiter hervorzuheben. Beispielsweise kann ein Modul als eine Hardware-Schaltung umgesetzt werden, die spezifische Großintegrations- (VLSI-) Schaltungen oder Gate-Arrays, handelsübliche Halbleiter, wie etwa Logik-Chips, Transistoren oder andere diskrete Komponenten umfasst. Ein Modul kann auch in programmierbaren Hardware-Vorrichtungen, wie etwa in benutzerprogrammierbaren Gate-Arrays, in programmierbarer Array-Logik, in programmierbaren logischen Vorrichtungen, Grafikverarbeitungseinheiten oder dergleichen, umgesetzt werden.
  • Ein Modul kann auch mindestens teilweise in Software zur Ausführung durch diverse Arten von Prozessoren umgesetzt werden. Eine identifizierte Einheit von ausführbarem Code kann beispielsweise einen oder mehrere räumliche oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als Objekt, Vorgang oder Funktion organisiert sein können. Dennoch müssen sich die Programmdateien eines identifizierten Moduls nicht räumlich zusammen befinden, sondern können getrennte Anweisungen umfassen, die an verschiedenen Standorten abgelegt sind, die, wenn sie logisch zusammengefügt werden, das Modul bilden und den genannten Zweck für das Modul erreichen. Ferner können die Module auf einem computerlesbaren Medien abgelegt sein, das beispielsweise ein Festplattenlaufwerk, eine Flash-Vorrichtung, ein Arbeitsspeicher (RAM), ein Band oder ein beliebiges anderes derartiges Medium sein kann, das zum Speichern von Daten verwendet wird.
  • In der Tat könnte ein Modul von ausführbarem Code eine einzelne Anweisung oder mehrere Anweisungen sein, und kann sogar auf mehrere verschiedene Codesegmente zwischen verschiedenen Programmen und über mehrere Speichervorrichtungen verteilt sein. Ähnlich können Betriebsdaten hier in Modulen identifiziert und abgebildet sein und können in einer beliebigen geeigneten Form ausgebildet sein und in einer beliebigen geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einzelner Datensatz erhoben werden oder können über verschiedene Standorte verteilt sein, und zwar auch über verschiedene Ablagevorrichtungen, und können mindestens teilweise nur als elektronische Signale in einem System oder Netzwerk existieren.
  • Es versteht sich ohne Weiteres, dass die Komponenten der Anwendung, wie sie hier generell beschrieben und in den Figuren abgebildet sind, in vielen verschiedenen Konfigurationen angeordnet und ausgelegt sein können. Somit ist die ausführliche Beschreibung der Ausführungsformen nicht dazu gedacht, den Umfang der beanspruchten Anwendung einzuschränken, sondern ist nur für ausgewählte Ausführungsformen der Anwendung repräsentativ.
  • Der Fachmann wird ohne Weiteres verstehen, dass das Vorstehende mit Schritten in einer anderen Reihenfolge und/oder mit Hardware-Elementen in Konfigurationen, die anders als die offenbarten sind, in die Praxis umgesetzt werden kann. Obwohl daher die Anwendung basierend auf diesen bevorzugten Ausführungsformen beschrieben wurde, wird es für den Fachmann ersichtlich sein, dass gewisse Änderungen, Variationen und alternative Konstruktionen offensichtlich sind.
  • Obwohl bevorzugte Ausführungsformen der vorliegenden Anwendung beschrieben wurden, versteht es sich, dass die beschriebenen Ausführungsformen rein erläuternd sind und der Umfang der Anmeldung nur durch die beiliegenden Ansprüche zu definieren ist, wenn sie mit allen möglichen Äquivalenten und Änderungen (z. B. Protokolle, Hardware-Vorrichtungen, Software-Plattformen usw.) dafür betrachtet werden.

Claims (20)

  1. Gerät, umfassend: eine Netzwerkschnittstelle, die konfiguriert ist, um Transportdaten eines Transportprozesses mit mehreren Parteien zu empfangen; und einen Prozessor, der konfiguriert ist, um Dokumente und Ereignisse, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten zu identifizieren, um Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen dynamisch zu bestimmen, und um eine Kennung des Transportprozesses mit mehreren Parteien und die dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain abzulegen.
  2. Gerät nach Anspruch 1, wobei der Prozessor konfiguriert ist, um Berechtigungen zum Lesen und Schreiben von Daten in der Blockchain für eine Vielzahl von Parteien, die zu dem Transportprozess mit mehreren Parteien gehören, basierend auf vordefinierten Rollen, die den Parteien durch den Kettencode der Blockchain zugeordnet sind, abzuleiten.
  3. Gerät nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist, um eine Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, zu empfangen, und um die Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, zu gewähren.
  4. Gerät nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist, um eine Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, zu empfangen, und um die Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, zu verweigern.
  5. Gerät nach Anspruch 1, wobei der Prozessor die Lese- und Schreib-Berechtigungen basierend auf einem Ursprung, einem Ziel und einem oder mehreren Zwischenstandorten des Transportprozesses mit mehreren Parteien bestimmt.
  6. Gerät nach Anspruch 1, wobei die Netzwerkschnittstelle ferner konfiguriert ist, um eine Aktualisierung von Ereignisdaten des Prozesses mit mehreren Parteien zu empfangen, und um die Aktualisierung von Ereignisdaten und die Lese- und Schreib-Berechtigungen für die Aktualisierung von Ereignisdaten in einem Block in der Blockchain abzulegen.
  7. Gerät nach Anspruch 6, wobei die Aktualisierung von Ereignisdaten eine Änderung an einem zuvor abgelegten Dokument umfasst.
  8. Gerät nach Anspruch 6, bei dem die Aktualisierung von Ereignisdaten eine Änderung an zuvor bestimmten Lese- und Schreib-Berechtigungen für ein Ereignis und seine Daten umfasst.
  9. Verfahren, umfassend: Empfangen von Transportdaten eines Transportprozesses mit mehreren Parteien; Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten; dynamisches Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen; und Speichern einer Kennung des Transportprozesses mit mehreren Parteien und der dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain.
  10. Verfahren nach Anspruch 9, wobei das dynamische Bestimmen das Ableiten von Berechtigungen zum Lesen und Schreiben von Daten in der Blockchain für eine Vielzahl von Parteien, die zu dem Transportprozess mit mehreren Parteien gehören, basierend auf vordefinierten Rollen, die den Parteien durch den Kettencode der Blockchain zugeordnet sind, umfasst.
  11. Verfahren nach Anspruch 9, ferner umfassend das Empfangen einer Anfrage, auf eines oder mehrerer von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Gewähren der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind.
  12. Verfahren nach Anspruch 9, ferner umfassend das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Verweigern der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind.
  13. Verfahren nach Anspruch 9, wobei das dynamische Bestimmen der Lese- und Schreib-Berechtigungen ferner basierend auf einem Ursprung, einem Ziel und einem oder mehreren Zwischenstandorten des Transportprozesses mit mehreren Parteien bestimmt wird.
  14. Verfahren nach Anspruch 9, ferner umfassend das Empfangen einer Aktualisierung von Ereignisdaten des Prozesses mit mehreren Parteien, und das Ablegen der Aktualisierung von Ereignisdaten und der Lese- und Schreib-Berechtigungen für die Aktualisierung von Ereignisdaten in einem Block in der Blockchain.
  15. Verfahren nach Anspruch 14, wobei die Aktualisierung von Ereignisdaten eine Änderung an einem zuvor abgelegten Dokument umfasst.
  16. Verfahren nach Anspruch 14, wobei die Aktualisierung von Ereignisdaten eine Änderung an zuvor bestimmten Lese- und Schreib-Berechtigungen für ein Ereignis und seine Daten umfasst.
  17. Nicht vorübergehendes computerlesbares Medium, das Anweisungen umfasst, die, wenn sie von einem Prozessor gelesen werden, bewirken, dass der Prozessor ein Verfahren ausführt, umfassend: Empfangen von Transportdaten eines Transportprozesses mit mehreren Parteien; Identifizieren von Dokumenten und Ereignissen, die mit dem Transportprozess mit mehreren Parteien verknüpft sind, basierend auf den empfangenen Transportdaten; dynamisches Bestimmen von Lese- und Schreib-Berechtigungen für die Dokumente und die Ereignisse des Transportprozesses mit mehreren Parteien basierend auf vordefinierten Rollen; und Speichern einer Kennung des Transportprozesses mit mehreren Parteien und der dynamisch bestimmten Lese- und Schreib-Berechtigungen in einem Block in einer Blockchain.
  18. Nicht vorübergehendes computerlesbares Medium nach Anspruch 17, wobei das dynamische Bestimmen das Ableiten von Berechtigungen zum Lesen und Schreiben von Daten in der Blockchain für eine Vielzahl von Parteien, die zu dem Transportprozess mit mehreren Parteien gehören, basierend auf vordefinierten Rollen, die den Parteien durch den Kettencode der Blockchain zugeordnet sind, umfasst.
  19. Nicht vorübergehendes computerlesbares Medium nach Anspruch 17, wobei das Verfahren ferner das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Gewähren der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, umfasst.
  20. Nicht vorübergehendes computerlesbares Medium nach Anspruch 17, wobei das Verfahren ferner das Empfangen einer Anfrage, auf eines oder mehrere von einem Dokument und einem Ereignis des Transportprozesses mit mehreren Parteien zuzugreifen, und das Verweigern der Anfrage basierend auf den dynamisch bestimmten Lese- und Schreib-Berechtigungen, die in der Blockchain abgelegt sind, umfasst.
DE112020005794.1T 2019-11-27 2020-11-20 Dynamische rechtevergabe und durchsetzung für transportprozess Pending DE112020005794T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/698,911 US11693979B2 (en) 2019-11-27 2019-11-27 Dynamic permission assignment and enforcement for transport process
US16/698,911 2019-11-27
PCT/IB2020/060990 WO2021105836A1 (en) 2019-11-27 2020-11-20 Dynamic permission assignment and enforcement for transport process

Publications (1)

Publication Number Publication Date
DE112020005794T5 true DE112020005794T5 (de) 2022-12-15

Family

ID=73695089

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020005794.1T Pending DE112020005794T5 (de) 2019-11-27 2020-11-20 Dynamische rechtevergabe und durchsetzung für transportprozess

Country Status (6)

Country Link
US (1) US11693979B2 (de)
JP (1) JP2023505757A (de)
CN (1) CN114762292A (de)
DE (1) DE112020005794T5 (de)
GB (1) GB2604561A (de)
WO (1) WO2021105836A1 (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10721069B2 (en) 2018-08-18 2020-07-21 Eygs Llp Methods and systems for enhancing privacy and efficiency on distributed ledger-based networks
US11316691B2 (en) 2019-04-15 2022-04-26 Eygs Llp Methods and systems for enhancing network privacy of multiple party documents on distributed ledger-based networks
US11232439B2 (en) 2019-08-09 2022-01-25 Eygs Llp Methods and systems for preventing transaction tracing on distributed ledger-based networks
AU2020387408A1 (en) 2019-11-20 2022-05-19 Eygs Llp Systems, apparatus and methods for identifying and securely storing distinguishing characteristics in a distributed ledger within a distributed ledger-based network based on fungible and non-fungible tokens
US11788852B2 (en) 2019-11-28 2023-10-17 Toyota Motor North America, Inc. Sharing of transport user profile
US11388582B2 (en) * 2019-11-28 2022-07-12 Toyota Motor North America, Inc. Providing media based on profile sharing
CN110751448B (zh) * 2019-12-20 2020-06-05 北京京邦达贸易有限公司 基于区块链的签单返还方法、装置、设备和可读存储介质
US11574308B2 (en) * 2020-04-15 2023-02-07 Eygs Llp Intelligent assertion tokens for authenticating and controlling network communications using a distributed ledger
SG11202102402QA (en) * 2020-06-08 2021-04-29 Alipay Labs Singapore Pte Ltd Blockchain-based import custom clearance data processing
EP3841507B1 (de) 2020-06-08 2023-04-26 Alipay Labs (Singapore) Pte. Ltd. Benutzerverwaltung einer blockchain-basierten zollabfertigungsdienstplattform
EP3837617B1 (de) 2020-06-08 2023-08-02 Alipay Labs (Singapore) Pte. Ltd. Verteilte speicherung von zollabfertigungsdaten
EP3841491B1 (de) 2020-06-08 2023-08-02 Alipay Labs (Singapore) Pte. Ltd. Blockchain-basierte smart-contract-pools
EP3844655B1 (de) 2020-06-08 2023-05-03 Alipay Labs (Singapore) Pte. Ltd. Verwaltung von benutzerberechtigungen für blockchain-basierte anwenderspezifische abrechnungsdienste
SG11202102583UA (en) 2020-06-08 2021-04-29 Alipay Labs Singapore Pte Ltd Blockchain-based document registration for custom clearance
US12033192B2 (en) * 2020-10-30 2024-07-09 Toyota Motor North America, Inc. Transport use determination
JP2023031079A (ja) * 2021-08-24 2023-03-08 富士通株式会社 データ処理プログラム、データ処理方法およびデータ処理装置
CN114331732B (zh) * 2022-03-15 2022-05-24 北京微芯感知科技有限公司 一种共识报文压缩方法
US11907229B2 (en) * 2022-03-31 2024-02-20 Gm Cruise Holdings Llc System and method for platform-independent access bindings
CN114938278B (zh) * 2022-04-11 2023-10-31 北京邮电大学 一种零信任访问控制方法及装置
EP4366227A1 (de) * 2022-11-04 2024-05-08 Abb Schweiz Ag Unveränderliche und manipulationssichere ereignisdaten

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2017239933A1 (en) * 2016-03-31 2018-11-08 Tbsx3 Pty Ltd Information system for item verification
CN106796688B (zh) 2016-12-26 2020-12-18 深圳前海达闼云端智能科技有限公司 区块链的权限控制方法、装置、***及节点设备
CN107426157B (zh) 2017-04-21 2020-04-17 杭州趣链科技有限公司 一种基于数字证书以及ca认证体系的联盟链权限控制方法
US10528551B2 (en) * 2017-09-29 2020-01-07 Oracle International Corporation System and method for providing a representational state transfer proxy service for a blockchain cloud service
CN107909372A (zh) 2017-10-25 2018-04-13 复旦大学 一种基于区块链技术的农产品溯源方法
US20190188706A1 (en) * 2017-12-18 2019-06-20 Apple Inc. Transference tracking
US11205178B2 (en) * 2017-12-28 2021-12-21 International Business Machines Corporation Converting processes into multiple blockchain smart contracts
CN108173850B (zh) 2017-12-28 2021-03-19 杭州趣链科技有限公司 一种基于区块链智能合约的身份认证***和身份认证方法
CN110602050B (zh) 2018-04-28 2022-01-07 腾讯科技(深圳)有限公司 区块链访问的鉴权方法和装置、存储介质、电子装置
US10692086B2 (en) * 2018-05-07 2020-06-23 Accenture Global Solutions Limited Distributed ledger based identity and origins of supply chain application enabling financial inclusion and sustainability
CN108768988B (zh) 2018-05-17 2021-01-05 深圳前海微众银行股份有限公司 区块链访问控制方法、设备及计算机可读存储介质
US10846268B2 (en) * 2018-06-08 2020-11-24 Saphyre, Inc. and Gabino M. Roche Jr. Technologies for file sharing
US11361088B2 (en) * 2019-02-25 2022-06-14 Oocl (Infotech) Holdings Limited Zero trust communication system for freight shipping organizations, and methods of use
CN109872238A (zh) 2019-02-26 2019-06-11 重庆大数美联科技有限公司 基于区块链的资产交易***访问控制方法及***
CN111066047B (zh) * 2019-06-27 2024-04-19 创新先进技术有限公司 实现基于区块链的工作流

Also Published As

Publication number Publication date
CN114762292A (zh) 2022-07-15
US11693979B2 (en) 2023-07-04
WO2021105836A1 (en) 2021-06-03
GB2604561A (en) 2022-09-07
JP2023505757A (ja) 2023-02-13
GB202209139D0 (en) 2022-08-10
US20210157947A1 (en) 2021-05-27

Similar Documents

Publication Publication Date Title
DE112020005794T5 (de) Dynamische rechtevergabe und durchsetzung für transportprozess
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
AU2021273375B2 (en) Cross-network identity provisioning
DE112020005075T5 (de) Effiziente schwellenwertspeicherung von datenobjekten
DE112021000608T5 (de) Schnellere ansichtsänderung für eine blockchain
US11646900B2 (en) Subscription service for networks
DE112021000688T5 (de) Indexstruktur für blockchain-ledger
US11455403B2 (en) Privacy-preserving document sharing
US11488099B2 (en) Supply-chain simulation
US11455598B2 (en) Automated conflict resolution
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
US20210117896A1 (en) Supply-chain simulation
US11354425B2 (en) Privacy-preserving document sharing
DE112021006165T5 (de) Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf
DE112021000219T5 (de) Konfliktfreie versionssteuerung
US11310311B2 (en) Media obfuscation
US11683185B2 (en) Entity certification management
US20210314155A1 (en) Trusted ledger stamping
US20210174292A1 (en) Anonymization of partners
DE112021004120B4 (de) Schwellenwertverschlüsselung für sendeinhalt
US11876890B2 (en) Anonymization of partners
DE112021005625T5 (de) Automatisiertes zusammenführen von dlt-netzwerken
US20210248271A1 (en) Document verification
US11379594B2 (en) Media obfuscation
US11856109B2 (en) Entity certification management