DE102020207619A1 - Verfahren und Vorrichtung zur Bereitstellung einer Ressource - Google Patents

Verfahren und Vorrichtung zur Bereitstellung einer Ressource Download PDF

Info

Publication number
DE102020207619A1
DE102020207619A1 DE102020207619.7A DE102020207619A DE102020207619A1 DE 102020207619 A1 DE102020207619 A1 DE 102020207619A1 DE 102020207619 A DE102020207619 A DE 102020207619A DE 102020207619 A1 DE102020207619 A1 DE 102020207619A1
Authority
DE
Germany
Prior art keywords
resource
status
exemplary embodiments
further exemplary
request
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
DE102020207619.7A
Other languages
English (en)
Inventor
Christian Hoeppler
Daniel Kunz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102020207619.7A priority Critical patent/DE102020207619A1/de
Priority to US17/306,619 priority patent/US11861559B2/en
Priority to CN202110682464.5A priority patent/CN113821562A/zh
Publication of DE102020207619A1 publication Critical patent/DE102020207619A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06315—Needs-based resource requirements planning or analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G06Q20/145—Payments according to the detected use or quantity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/06—Energy or water supply
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • Marketing (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Operations Research (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Verfahren, insbesondere computerimplementiertes Verfahren, zum Verwalten einer Bereitstellung einer Ressource, aufweisend die folgenden Schritte: Empfangen einer Anforderung bezüglich einer Nutzung der Ressource, Validieren der Anforderung, und, basierend auf der Validierung der Anforderung, Etablieren eines Zustandskanals.

Description

  • Stand der Technik
  • Die Offenbarung betrifft ein, insbesondere computerimplementiertes, Verfahren zum Verwalten einer Bereitstellung einer Ressource.
  • Die Offenbarung betrifft ferner eine Vorrichtung zum Verwalten einer Bereitstellung einer Ressource.
  • Offenbarung der Erfindung
  • Beispielhafte Ausführungsformen beziehen sich auf ein Verfahren, insbesondere ein computerimplementiertes Verfahren, zum Verwalten einer Bereitstellung einer Ressource, aufweisend die folgenden Schritte: Empfangen einer Anforderung bezüglich einer Nutzung der Ressource, Validieren der Anforderung, und, basierend auf der Validierung der Anforderung, Etablieren eines Zustandskanals (englisch: state channel). Bei manchen beispielhaften Ausführungsformen ist dadurch eine dezentrale Nutzung von Ressourcen ermöglicht.
  • Bei weiteren beispielhaften Ausführungsformen kann wenigstens ein Zustandskanal, wie er z.B. in der nachfolgend genannten [Referenz 2] beschrieben ist, z.B. für das Empfangen (und/oder das Senden) der Anforderung verwendet werden, und/oder für eine weitere Kommunikation bezüglich der Bereitstellung der Ressource.
  • Die nachfolgend aufgeführten Dokumente [Referenz 1] und [Referenz 2] werden hiermit ausdrücklich in die vorliegende Beschreibung aufgenommen.
  • Stefan Dziembowski, Sebastian Faust, and Kristina Hostäkovä. 2018. General State Channel Networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS '18). Association for Computing Machinery, New York, NY, USA, 949-966. DOI:https://doi.org/10.1145/3243734.3243856 [Referenz 1].
  • S. Dziembowski, L. Eckey, S. Faust and D. Malinowski, „Perun: Virtual Payment Hubs over Cryptocurrencies," 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2019, pp. 106-123, doi: 10.1109/SP.2019.00020 [Referenz 2].
  • Bei weiteren beispielhaften Ausführungsformen können über den Zustandskanal, beispielsweise signierte, Transkationen und/oder Statusinformationen und/oder Statusaktualisierungen übertragen werden, z.B. zwischen einem prospektiven Konsumenten einer Ressource und einer Vorrichtung, die die Ressource bereitstellt, insbesondere einer Vorrichtung gemäß beispielhaften Ausführungsformen.
  • Bei weiteren beispielhaften Ausführungsformen können über den Zustandskanal vergleichsweise viele (beispielsweise signierte) Transaktionen pro Zeit übertragen werden, sodass eine Anforderung und/oder Bereitstellung von Ressourcen entsprechend dynamisch erfolgen kann.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass die Anforderung einen digitalen Vertrag aufweist, wobei der digitale Vertrag wenigstens eine Signatur aufweist, wobei das Validieren das Überprüfen der wenigstens einen Signatur aufweist.
  • Bei weiteren beispielhaften Ausführungsformen weist der digitale Vertrag wenigstens eines der folgenden Elemente auf:
    1. a) eine digitale Signatur einer ersten Partei, z.B. eines prospektiven Konsumenten der Ressource,
    2. b) eine digitale Signatur einer zweiten Partei, z.B. einer die Ressource bereitstellenden Vorrichtung,
    3. c) eine digitale Identität der ersten Partei (beispielsweise eine dezentralisierte Kennung, decentralised identifier, DID, der ersten Partei),
    4. d) eine digitale Identität der zweiten Partei (beispielsweise eine dezentralisierte Kennung, decentralised identifier, DID, der zweiten Partei),
    5. e) Nutzungsbedingungen, z.B. für eine Bereitstellung der Ressource,
    6. f) einen Preis pro Einheit der Ressource,
    7. g) eine die bzw. einen Typ der Einheit der Ressource charakterisierende Information (z.B. Kilowattstunde, im Falle von elektrischer Energie als Ressource),
    8. h) eine eine Währung bzw. einen Typ einer Währung charakterisierende Information (z.B. Angabe, dass als Währung eine digitale, z.B. Blockchain-basierte, Währung verwendet wird),
    9. i) einen Umfang der Ressource (z.B. eine Anzahl von Einheiten),
    10. j) ein Zeitraum für eine Nutzung der Ressource.
  • Bei weiteren beispielhaften Ausführungsformen ist der digitale Vertrag z.B. als Ricardian Contract ausgebildet, vgl. http://iang.org/papers/ricardian_contract.html.
  • Bei weiteren beispielhaften Ausführungsformen kann alternativ oder ergänzend zu der die Währung bzw. den Typ einer Währung charakterisierenden Information auch eine Information in dem digitalen Vertrag enthalten sein, die wenigstens eines der folgenden Elemente charakterisiert: Asset bzw. Vermögen oder Vermögenswert, Kosten, Geld, Crypto-Währung, Schuldscheine, Voucher, usw.
  • Bei weiteren beispielhaften Ausführungsformen kann ein zu etablierender Zustandskanal bzw. ein Typ eines zu etablierenden Zustandskanals beispielsweise basierend auf dem Typ der Währung ermittelt werden.
  • Bei weiteren beispielhaften Ausführungsformen weist das Etablieren des Zustandskanals wenigstens eines der folgenden Elemente auf: a) Verwenden eines Smart Contracts, der beispielsweise mittels eines Distributed-Ledger-Technologie, DLT, -Systems verwaltet wird, insbesondere zum Verankern des Zustandskanals, b) Verwenden eines Hubs, der dazu ausgebildet ist, die Anforderung von einer weiteren Einheit, insbesondere einem prospektiven Konsumenten der Ressource, zu empfangen und weiterzuleiten.
  • Bei weiteren beispielhaften Ausführungsformen kann der Zustandskanal z.B. ein sog. Ledger Kanal (Ledger Channel) sein, der z.B. mittels eines DLT-Systems realisierbar ist.
  • Bei weiteren beispielhaften Ausführungsformen kann der Zustandskanal z.B. mittels eines bzw. des Hubs realisiert werden.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das DLT-System wenigstens eine Blockchain und/oder wenigstens einen gerichteten azyklischen Graphen (englisch: directed acyclic graph, DAG) aufweist.
  • Bei weiteren beispielhaften Ausführungsformen kann die Blockchain als verkettete Liste von Datenblöcken aufgefasst werden, die unter Verwendung kryptografischer Verfahren (z.B. Bildung eines Hashwerts des jeweiligen Datenblocks) miteinander verknüpft werden, beispielsweise gemäß dem Prinzip des Merkle-Baums. Dadurch ist eine fälschungssichere Speicherung von Daten in der Blockchain möglich.
  • Bei weiteren beispielhaften Ausführungsformen kann die Blockchain in Form einer verteilten bzw. dezentralen Datenbank realisiert werden, wobei mehrere Netzwerkelemente („Nodes“) eines Blockchain-Netzwerks jeweils Datenblöcke der Blockchain speichern. Grundlegende Aspekte der Blockchain-Technologie sind z.B. in der folgenden Publikation beschrieben: Nakamoto, Satoshi. (2009). Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf.
  • Bei weiteren bevorzugten Ausführungsformen kann eine DLT bzw. die Blockchain ein oder mehrere Smart Contracts speichern, die beispielsweise das Speichern von Informationen ermöglichen, beispielsweise auch im Zusammenhang mit dem Etablieren des Zustandskanals gemäß beispielhaften Ausführungsformen, aber auch das Ausführen von Abfragen und weiteren Programmfunktionen, ähnlich einer Programmiersprache, z.B. basierend auf in der Blockchain gespeicherten Informationen und/oder bezüglich der Blockchain ausgeführten Transaktionen. Dadurch können bei weiteren beispielhaften Ausführungsformen vertraglichen Regelungen entsprechende Logische Verknüpfungen und/oder eine Nutzung der Ressource charakterisierende Informationen usw. in der Blockchain mittels einem oder mehrerer Smart Contracts gespeichert werden.
  • Bei weiteren beispielhaften Ausführungsformen kann der Hub beispielsweise dazu ausgebildet sein, zumindest zeitweise eine, vorzugsweise bidirektionale, Datenverbindung mit der die Anforderung sendenden Vorrichtung (z.B. prospektiver Konsument der Ressource) und/oder mit der die Anforderung empfangenden Vorrichtung herzustellen, beispielsweise, um die Anforderung zu übertragen und/oder mit der Anforderung assoziierte Informationen wie z.B. eine Bestätigung oder Ablehnung und/oder eine Nutzung der Ressource charakterisierende Informationen oder dergleichen zu empfangen und/oder weiterzuleiten.
  • Bei weiteren beispielhaften Ausführungsformen erfolgt ein Informationsaustausch über den Hub gemäß weiteren beispielhaften Ausführungsformen zumindest überwiegend außerhalb eines ggf. vorhandenen, optionalen DLT-Systems, also z.B. „off-chain“, d.h., ohne dass Elemente des Informationsaustauschs über den Hub, insbesondere zeitgleich, in einer Blockchain (oder einem DAG) des DLT-Systems gespeichert werden. Dadurch kann der Informationsaustausch über den Hub bei weiteren beispielhaften Ausführungsformen besonders effizient erfolgen.
  • Bei weiteren beispielhaften Ausführungsformen kann als Hub beispielsweise eine der in den folgenden Dokumenten beschriebene Konfiguration verwendet werden: [Referenz 1], [Referenz 2].
  • Bei weiteren beispielhaften Ausführungsformen weist das Verfahren weiter auf: Freigeben einer Nutzung der Ressource, beispielsweise durch den prospektiven Konsumenten. Mit anderen Worten kann eine die Ressource bereitstellende Vorrichtung die Ressource bereitstellen, und der prospektive Konsument kann die Ressource nach der genannten Freigabe seitens der die Ressource bereitstellenden Vorrichtung nutzen.
  • Bei weiteren beispielhaften Ausführungsformen weist das Verfahren weiter auf: Empfangen von wenigstens einer, beispielsweise signierten, Statusaktualisierung, insbesondere von einem bzw. dem Konsumenten, Validieren eines durch die Statusaktualisierung charakterisierten, insbesondere aktualisierten, Status.
  • Bei weiteren beispielhaften Ausführungsformen kann die Statusaktualisierung, die z.B. durch den Konsumenten signiert sein kann, eine Anforderung, z.B. weitere Anforderung, der Ressource charakterisieren. Mit anderen Worten kann der Konsument mittels der Statusaktualisierung bei weiteren beispielhaften Ausführungsformen eine weitergehende und/oder erneute Nutzung der Ressource anfordern bzw. einfordern.
  • Bei weiteren beispielhaften Ausführungsformen kann das Validieren des durch die Statusaktualisierung charakterisierten, insbesondere aktualisierten, Status, beispielsweise aufweisen: Überprüfen, ob der Status den vereinbarten Konditionen, beispielsweise charakterisiert durch den digitalen Vertrag, entspricht.
  • Bei weiteren beispielhaften Ausführungsformen weist das Verfahren weiter auf: Signieren des, insbesondere aktualisierten Status, Senden des, insbesondere aktualisierten Status, insbesondere an den Konsumenten. Bei weiteren beispielhaften Ausführungsformen signiert die die Ressource bereitstellende Vorrichtung ihrerseits den aktualisierten Status, bevor sie ihn an den Konsumenten sendet.
  • Bei weiteren beispielhaften Ausführungsformen weist das Verfahren weiter auf: Ermitteln, ob Bedingungen für eine Nutzung der Ressource, insbesondere noch, gegeben sind, und, optional, insbesondere dann, wenn die Bedingungen für die Nutzung der Ressource nicht mehr gegeben sind, Beenden einer möglichen Nutzung der Ressource, und, optional, Schließen des Zustandskanals.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf eine Vorrichtung zur Verwaltung der Bereitstellung einer Ressource, wobei die Vorrichtung zur Ausführung des Verfahrens gemäß den Ausführungsformen ausgebildet ist.
  • Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass die Vorrichtung aufweist: eine wenigstens einen Rechenkern aufweisende Recheneinrichtung („Computer“), eine der Recheneinrichtung zugeordnete Speichereinrichtung zur zumindest zeitweisen Speicherung wenigstens eines der folgenden Elemente: a) Daten, b) Computerprogramm, insbesondere zur Ausführung des Verfahrens gemäß den Ausführungsformen.
  • Bei weiteren bevorzugten Ausführungsformen können die Daten zumindest zeitweise und/oder teilweise empfangene Anforderungen und/oder Statusaktualisierungen und/oder Regelungen für die Bereitstellung, z.B. ableitbar aus dem digitalen Vertrag, aufweisen.
  • Bei weiteren bevorzugten Ausführungsformen weist die Speichereinrichtung einen flüchtigen Speicher (z.B. Arbeitsspeicher (RAM)) auf, und/oder einen nichtflüchtigen Speicher (z.B. Flash-EEPROM).
  • Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung wenigstens eines der folgenden Elemente aufweisen: Mikroprozessor (µP), Mikrocontroller (µC), anwendungsspezifischer integrierter Schaltkreis (ASIC), System on Chip (SoC), programmierbarer Logikbaustein (z.B. FPGA, field programmable gate array), Hardwareschaltung, Grafikprozessor (GPU, graphics processing unit), oder beliebige Kombinationen hieraus.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf ein Verfahren zum Anfordern einer Ressource, aufweisend die folgenden Schritte: Senden einer Anforderung bezüglich einer Nutzung der Ressource, insbesondere an eine Vorrichtung gemäß den Ausführungsformen, und, optional, Etablieren eines bzw. des Zustandskanals, und, optional, Empfangen der Ressource.
  • Bei weiteren beispielhaften Ausführungsformen weist das Verfahren weiter auf: Senden einer Statusaktualisierung, z.B. um eine erneute Nutzung der Ressource anzufordern, und, optional, weiteres Empfangen der Ressource, insbesondere basierend auf der Statusaktualisierung.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf eine Vorrichtung zur Anforderung einer Ressource, wobei die Vorrichtung zur Ausführung des Verfahrens gemäß den Ausführungsformen ausgebildet ist.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf ein System zur Bereitstellung von wenigstens einer Ressource, aufweisend wenigstens eine Vorrichtung zur Bereitstellung der wenigstens einen Ressource gemäß den Ausführungsformen und wenigstens eine Vorrichtung zur Anforderung einer Ressource gemäß den Ausführungsformen.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das System weiter wenigstens einen Hub aufweist, der dazu ausgebildet ist, die Anforderung zu empfangen und an die Vorrichtung zur Bereitstellung der Ressource weiterzuleiten.
  • Weitere bevorzugte Ausführungsformen beziehen sich auf ein computerlesbares Speichermedium, umfassend Befehle, die bei der Ausführung durch einen Computer diesen veranlassen, das Verfahren gemäß den Ausführungsformen auszuführen.
  • Weitere bevorzugte Ausführungsformen beziehen sich auf ein Computerprogramm, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das Verfahren gemäß den Ausführungsformen auszuführen.
  • Weitere bevorzugte Ausführungsformen beziehen sich auf ein Datenträgersignal, das das Computerprogramm gemäß den Ausführungsformen charakterisiert und/oder überträgt. Das Datenträgersignal ist beispielsweise über eine optionale Datenschnittstelle der Vorrichtung empfangbar.
  • Weitere bevorzugte Ausführungsformen beziehen sich auf eine Verwendung des Verfahrens gemäß den Ausführungsformen und/oder der Vorrichtung gemäß den Ausführungsformen und/oder des Systems gemäß den Ausführungsformen und/oder des computerlesbaren Speichermediums gemäß den Ausführungsformen und/oder des Computerprogramms gemäß den Ausführungsformen und/oder des Datenträgersignals gemäß den Ausführungsformen für wenigstens eines der folgenden Elemente: a) Bereitstellen wenigstens einer Ressource, b) Verwalten der Bereitstellung der wenigstens einen Ressource, c) Übertragen der Anforderung über einen Zustandskanal, d) Ermöglichen einer, insbesondere feingranularen, Bezahlung, insbesondere zumindest nahezu in Echtzeit, für eine Bereitstellung von wenigstens einer Ressource, e) Aufbauen und/oder Abbauen und/oder Nutzen eines Zustandskanals, insbesondere Nutzen des Zustandskanals zur Bezahlung einer, insbesondere angeforderten, Ressource, f) geteilte Nutzung eines Fahrzeugs, insbesondere Kraftfahrzeugs, z.B. Car-Sharing, g) Bereitstellen elektrischer Energie, insbesondere zum Aufladen wenigstens einer Vorrichtung zur zumindest zeitweisen Speicherung von, insbesondere arbeitsfähiger, elektrischer Ladung, h) Nutzung eines Werkzeugs, beispielsweise Handwerkzeugs, beispielsweise in Form eines Shareconomy-Prinzips, i) Nutzung einer Schnittstelle, beispielsweise Programmierschnittstelle (API).
  • Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen der Erfindung, die in den Figuren der Zeichnung dargestellt sind. Dabei bilden alle beschriebenen oder dargestellten Merkmale für sich oder in beliebiger Kombination den Gegenstand der Erfindung, unabhängig von ihrer Zusammenfassung in den Ansprüchen oder deren Rückbeziehung sowie unabhängig von ihrer Formulierung bzw. Darstellung in der Beschreibung bzw. in der Zeichnung.
  • In der Zeichnung zeigt:
    • 1 schematisch ein vereinfachtes Blockdiagramm gemäß beispielhaften Ausführungsformen,
    • 2A schematisch ein vereinfachtes Flussdiagramm von Verfahren gemäß weiteren beispielhaften Ausführungsformen,
    • 2B schematisch ein vereinfachtes Flussdiagramm von Verfahren gemäß weiteren beispielhaften Ausführungsformen,
    • 2C schematisch ein vereinfachtes Flussdiagramm von Verfahren gemäß weiteren beispielhaften Ausführungsformen,
    • 2D schematisch ein vereinfachtes Flussdiagramm von Verfahren gemäß weiteren beispielhaften Ausführungsformen,
    • 3A schematisch ein vereinfachtes Flussdiagramm von Verfahren gemäß weiteren beispielhaften Ausführungsformen,
    • 3B schematisch ein vereinfachtes Flussdiagramm von Verfahren gemäß weiteren beispielhaften Ausführungsformen,
    • 4 schematisch ein vereinfachtes Blockdiagramm gemäß weiteren beispielhaften Ausführungsformen,
    • 5 schematisch ein vereinfachtes Blockdiagramm gemäß weiteren beispielhaften Ausführungsformen,
    • 6A schematisch ein vereinfachtes Blockdiagramm gemäß weiteren beispielhaften Ausführungsformen,
    • 6B schematisch ein vereinfachtes Blockdiagramm gemäß weiteren beispielhaften Ausführungsformen,
    • 7 schematisch ein vereinfachtes Flussdiagramm gemäß weiteren beispielhaften Ausführungsformen, und
    • 8 schematisch ein vereinfachtes Blockdiagramm gemäß weiteren beispielhaften Ausführungsformen.
  • 1 zeigt schematisch ein vereinfachtes Blockdiagramm gemäß beispielhaften Ausführungsformen, wobei eine Vorrichtung 200 zur Bereitstellung einer Ressource R, z.B. von elektrischer Energie, vorgesehen ist. Weitere beispielhafte Ausführungsformen, vgl. 2A, beziehen sich auf ein Verfahren, insbesondere ein computerimplementiertes Verfahren, zum Verwalten einer Bereitstellung der Ressource R.
  • Das Verfahren kann bei weiteren beispielhaften Ausführungsformen z.B. zumindest zeitweise durch die Vorrichtung 200 (1) ausgeführt werden und weist die folgenden Schritte auf, vgl. 2A: Empfangen 100 einer Anforderung A bezüglich einer Nutzung der Ressource R, Validieren 110 der Anforderung A, und, basierend auf der Validierung 110 der Anforderung A, Etablieren 120 eines Zustandskanals (englisch: state channel) SC. Bei manchen beispielhaften Ausführungsformen ist dadurch eine dezentrale Nutzung von Ressourcen bzw. der Ressource R ermöglicht.
  • Bei weiteren beispielhaften Ausführungsformen kann wenigstens ein Zustandskanal, wie er z.B. in der nachfolgend genannten [Referenz 2] beschrieben ist, z.B. für das Empfangen 110 (und/oder das Senden, z.B. durch die Vorrichtung 300, Details s.u.) der Anforderung A verwendet werden, und/oder für eine weitere Kommunikation bezüglich der Bereitstellung der Ressource R.
  • Die nachfolgend aufgeführten Dokumente [Referenz 1] und [Referenz 2] werden hiermit ausdrücklich in die vorliegende Beschreibung aufgenommen.
  • Stefan Dziembowski, Sebastian Faust, and Kristina Hostäkovä. 2018. General State Channel Networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS '18). Association for Computing Machinery, New York, NY, USA, 949-966. DOI:https://doi.org/10.1145/3243734.3243856 [Referenz 1].
  • S. Dziembowski, L. Eckey, S. Faust and D. Malinowski, „Perun: Virtual Payment Hubs over Cryptocurrencies," 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2019, pp. 106-123, doi: 10.1109/SP.2019.00020 [Referenz 2].
  • Bei weiteren beispielhaften Ausführungsformen können über den Zustandskanal SC, beispielsweise (digital) signierte, Transkationen und/oder Statusinformationen und/oder Statusaktualisierungen übertragen werden, z.B. zwischen einem prospektiven Konsumenten 300 (1) einer Ressource und einer Vorrichtung 200, die die Ressource R bereitstellt, insbesondere einer Vorrichtung 200 gemäß beispielhaften Ausführungsformen.
  • Bei weiteren beispielhaften Ausführungsformen bezeichnet das Bezugszeichen 300 eine Vorrichtung zur Anforderung von Ressourcen R. Bei weiteren beispielhaften Ausführungsformen kann die Vorrichtung 300 z.B. einem Konsumenten der Ressource zugeordnet sein. Insoweit wird nachfolgend das Bezugszeichen 300 beispielhaft sowohl für die Vorrichtung 300 also auch für einen ggf. der Vorrichtung 300 zugeordneten Konsumenten (im Sinne z.B. einer natürlichen Person) verwendet.
  • Bei weiteren beispielhaften Ausführungsformen können über den Zustandskanal vergleichsweise viele (beispielsweise signierte) Transaktionen pro Zeit übertragen werden, sodass eine Anforderung und/oder Bereitstellung von Ressourcen entsprechend dynamisch erfolgen kann.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass die Anforderung A einen digitalen Vertrag DV, vgl. auch 4, aufweist oder charakterisiert, wobei der digitale Vertrag DV wenigstens eine Signatur SIG-1 aufweist, wobei das Validieren 110 (2A) das Überprüfen der wenigstens einen Signatur SIG-1 aufweist. Auf diese Weise kann z.B. festgestellt werden, ob eine Manipulation des digitalen Vertrags DV erfolgt ist.
  • Bei weiteren beispielhaften Ausführungsformen weist der digitale Vertrag DV wenigstens eines der folgenden Elemente auf:
    1. a) eine digitale Signatur SIG-1 einer ersten Partei, z.B. eines bzw. des prospektiven Konsumenten 300 (1) der Ressource,
    2. b) eine digitale Signatur SIG-2 einer zweiten Partei, z.B. einer die Ressource bereitstellenden Vorrichtung 200,
    3. c) eine digitale Identität ID-1 der ersten Partei (beispielsweise eine dezentralisierte Kennung, decentralised identifier, DID, der ersten Partei),
    4. d) eine digitale Identität ID-2 der zweiten Partei (beispielsweise eine dezentralisierte Kennung, decentralised identifier, DID, der zweiten Partei),
    5. e) Nutzungsbedingungen NB, z.B. für eine Bereitstellung der Ressource R,
    6. f) einen Preis pro Einheit PPE der Ressource R,
    7. g) eine die bzw. einen Typ der Einheit der Ressource charakterisierende Information T-E (z.B. Kilowattstunde, im Falle von elektrischer Energie als Ressource R),
    8. h) eine eine Währung bzw. einen Typ einer Währung charakterisierende Information T-W (z.B. Angabe, dass als Währung eine digitale, z.B. Blockchain-basierte, Währung verwendet wird),
    9. i) einen Umfang RES-U der Ressource (z.B. eine Anzahl von Einheiten),
    10. j) ein Zeitraum T-NUTZ für eine Nutzung der Ressource.
  • Bei weiteren beispielhaften Ausführungsformen ist der digitale Vertrag DV z.B. als Ricardian Contract ausgebildet, s. http://iang.org/papers/ricardian_contract.html.
  • Bei weiteren beispielhaften Ausführungsformen kann ein zu etablierender Zustandskanal SC bzw. ein Typ eines zu etablierenden Zustandskanals SC beispielsweise basierend auf dem Typ der Währung T-W des digitalen Vertrags DV ermittelt werden.
  • Bei weiteren beispielhaften Ausführungsformen kann die Nutzung eines optionalen SSI (self-sovereign identity, „selbstsouveräne Identität“)-Systems SSI vorgesehen sein, das z.B. zur Speicherung kryptografischer Schlüssel K-1, K-2 der Parteien 200, 300 ausgebildet ist.
  • Bei weiteren beispielhaften Ausführungsformen weist das Etablieren 120 ( 2A) des Zustandskanals wenigstens eines der folgenden Elemente auf, vgl. 2B: a) Verwenden 120a eines Smart Contracts 14 (1), der beispielsweise mittels eines optionalen Distributed-Ledger-Technologie, DLT, -Systems 10 verwaltet wird, insbesondere zum Verankern des Zustandskanals SC, b) Verwenden 120b eines Hubs 400 (1), der dazu ausgebildet ist, die Anforderung A von einer weiteren Einheit 300, insbesondere einem prospektiven Konsumenten 300 der Ressource R, zu empfangen und weiterzuleiten.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das optionale DLT-System 10 (1) wenigstens eine Blockchain 12 und/oder wenigstens einen gerichteten azyklischen Graphen (englisch: directed acyclic graph, DAG, nicht gezeigt) aufweist.
  • Bei weiteren beispielhaften Ausführungsformen kann die Blockchain 12 als verkettete Liste von Datenblöcken aufgefasst werden, die unter Verwendung kryptografischer Verfahren (z.B. Bildung eines Hashwerts des jeweiligen Datenblocks) miteinander verknüpft werden, beispielsweise gemäß dem Prinzip des Merkle-Baums. Dadurch ist eine fälschungssichere Speicherung von Daten in der Blockchain 12 möglich.
  • Bei weiteren beispielhaften Ausführungsformen kann die Blockchain 12 in Form einer verteilten bzw. dezentralen Datenbank realisiert werden, wobei mehrere Netzwerkelemente („Nodes“) eines Blockchain-Netzwerks jeweils Datenblöcke der Blockchain 12 speichern. Grundlegende Aspekte der Blockchain-Technologie sind z.B. in der folgenden Publikation beschrieben: Nakamoto, Satoshi. (2009). Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf.
  • Bei weiteren bevorzugten Ausführungsformen kann eine DLT bzw. die Blockchain 12 ein oder mehrere Smart Contracts 14 speichern, die beispielsweise das Speichern von Informationen ermöglichen, beispielsweise auch im Zusammenhang mit dem Etablieren 110 (2A) des Zustandskanals SC gemäß beispielhaften Ausführungsformen, aber auch das Ausführen von Abfragen und weiteren Programmfunktionen, ähnlich einer Programmiersprache, z.B. basierend auf in der Blockchain 12 gespeicherten Informationen und/oder bezüglich der Blockchain 12 ausgeführten Transaktionen. Dadurch können bei weiteren beispielhaften Ausführungsformen vertraglichen Regelungen entsprechende logische Verknüpfungen und/oder eine Nutzung der Ressource R charakterisierende Informationen usw. in der Blockchain 12 mittels einem oder mehrerer Smart Contracts 14 gespeichert werden.
  • Bei weiteren beispielhaften Ausführungsformen kann der Zustandskanal SC z.B. ein sog. Ledger Kanal (Ledger Channel) sein, der z.B. mittels des DLT-Systems 10 realisierbar ist.
  • Bei weiteren beispielhaften Ausführungsformen kann der Zustandskanal SC z.B. mittels eines bzw. des Hubs 400 realisiert werden.
  • Bei weiteren beispielhaften Ausführungsformen kann der Hub 400 beispielsweise dazu ausgebildet sein, zumindest zeitweise eine, vorzugsweise bidirektionale, Datenverbindung mit der die Anforderung A sendenden Vorrichtung 300 und/oder mit der die Anforderung A empfangenden Vorrichtung 200 herzustellen, beispielsweise, um die Anforderung A zu übertragen und/oder mit der Anforderung A assoziierte Informationen wie z.B. eine Bestätigung oder Ablehnung und/oder eine Nutzung der Ressource R charakterisierende Informationen oder dergleichen zu empfangen und/oder weiterzuleiten.
  • Bei weiteren beispielhaften Ausführungsformen erfolgt ein Informationsaustausch über den Hub gemäß weiteren beispielhaften Ausführungsformen zumindest überwiegend außerhalb eines ggf. vorhandenen, optionalen DLT-Systems 10, also z.B. „off-chain“, d.h., ohne dass Elemente des Informationsaustauschs über den Hub 400, insbesondere zeitgleich, in einer Blockchain 12 (oder einem DAG) des DLT-Systems 10 gespeichert werden. Dadurch kann der Informationsaustausch über den Hub 400 bei weiteren beispielhaften Ausführungsformen besonders effizient erfolgen.
  • Bei weiteren beispielhaften Ausführungsformen kann als Hub beispielsweise eine der in den folgenden Dokumenten beschriebene Konfiguration verwendet werden: [Referenz 1], [Referenz 2].
  • Bei weiteren beispielhaften Ausführungsformen weist das Verfahren weiter auf, vgl. 2A: Freigeben 122 einer Nutzung der Ressource R, beispielsweise durch den prospektiven Konsumenten. Mit anderen Worten kann eine die Ressource R bereitstellende Vorrichtung 200 (1) die Ressource R bereitstellen, und der prospektive Konsument 300 kann die Ressource R nach der genannten Freigabe 122 seitens der die Ressource R bereitstellenden Vorrichtung 200 nutzen.
  • Bei weiteren beispielhaften Ausführungsformen, vgl. 2C, weist das Verfahren weiter auf: Empfangen 130 von wenigstens einer, beispielsweise signierten, Statusaktualisierung SA, insbesondere von einem bzw. dem Konsumenten 300, Validieren 132 eines durch die Statusaktualisierung SA charakterisierten, insbesondere aktualisierten, Status.
  • Bei weiteren beispielhaften Ausführungsformen kann die Statusaktualisierung SA, die z.B. durch den Konsumenten 300 signiert sein kann, eine Anforderung, z.B. weitere Anforderung, der Ressource R charakterisieren. Mit anderen Worten kann der Konsument 300 mittels der Statusaktualisierung SA bei weiteren beispielhaften Ausführungsformen eine weitergehende und/oder erneute Nutzung der Ressource R anfordern bzw. einfordern.
  • Bei weiteren beispielhaften Ausführungsformen kann das Validieren 132 des durch die Statusaktualisierung SA charakterisierten, insbesondere aktualisierten, Status, beispielsweise aufweisen: Überprüfen, ob der Status den vereinbarten Konditionen, beispielsweise charakterisiert durch den digitalen Vertrag DV ( 4), entspricht.
  • Bei weiteren beispielhaften Ausführungsformen weist das Verfahren weiter auf, vgl. 2C: Signieren 134 des aktualisierten Status, Senden 136 des aktualisierten Status, insbesondere an den Konsumenten 300. Bei weiteren beispielhaften Ausführungsformen signiert die die Ressource bereitstellende Vorrichtung 200 somit ihrerseits den aktualisierten Status, bevor sie ihn an den Konsumenten 300 sendet.
  • Bei weiteren beispielhaften Ausführungsformen, vgl. 2D, weist das Verfahren weiter auf: Ermitteln 140, ob Bedingungen für eine Nutzung der Ressource R, insbesondere noch, gegeben sind, und, optional, insbesondere dann, wenn die Bedingungen für die Nutzung der Ressource R nicht mehr gegeben sind, Beenden 142 einer möglichen Nutzung der Ressource R, und, optional, Schließen 144 des Zustandskanals SC.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf eine Vorrichtung 200 (1) zur Verwaltung der Bereitstellung einer Ressource R, wobei die Vorrichtung 200 zur Ausführung des Verfahrens gemäß den Ausführungsformen ausgebildet ist.
  • Bei weiteren bevorzugten Ausführungsformen, vgl. 5, ist vorgesehen, dass die Vorrichtung 200 aufweist: eine wenigstens einen Rechenkern 202a aufweisende Recheneinrichtung 202 („Computer“), eine der Recheneinrichtung 202 zugeordnete Speichereinrichtung 204 zur zumindest zeitweisen Speicherung wenigstens eines der folgenden Elemente: a) Daten DAT, b) Computerprogramm PRG, insbesondere zur Ausführung des Verfahrens gemäß den Ausführungsformen.
  • Bei weiteren bevorzugten Ausführungsformen können die Daten DAT zumindest zeitweise und/oder teilweise empfangene Anforderungen A und/oder Statusaktualisierungen SA und/oder Regelungen für die Bereitstellung, z.B. ableitbar aus dem digitalen Vertrag DV (4), aufweisen.
  • Bei weiteren bevorzugten Ausführungsformen weist die Speichereinrichtung einen flüchtigen Speicher 204a (z.B. Arbeitsspeicher (RAM)) auf, und/oder einen nichtflüchtigen Speicher 204b (z.B. Flash-EEPROM).
  • Bei weiteren beispielhaften Ausführungsformen kann die Recheneinrichtung 202 wenigstens eines der folgenden Elemente aufweisen: Mikroprozessor (µP), Mikrocontroller (µC), anwendungsspezifischer integrierter Schaltkreis (ASIC), System on Chip (SoC), programmierbarer Logikbaustein (z.B. FPGA, field programmable gate array), Hardwareschaltung, Grafikprozessor (GPU, graphics processing unit), oder beliebige Kombinationen hieraus.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf ein computerlesbares Speichermedium SM, umfassend Befehle PRG, die bei der Ausführung durch einen Computer 202 diesen veranlassen, das Verfahren gemäß den Ausführungsformen auszuführen.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf ein Computerprogramm PRG, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer 202 diesen veranlassen, das Verfahren gemäß den Ausführungsformen auszuführen.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf ein Datenträgersignal DCS, das das Computerprogramm PRG gemäß den Ausführungsformen charakterisiert und/oder überträgt. Das Datenträgersignal DCS ist beispielsweise über eine optionale Datenschnittstelle 206 der Vorrichtung 200 empfangbar, über die bei weiteren beispielhaften Ausführungsformen z.B. auch die Anforderung A empfangbar ist, und/oder sonstige z.B. über den Zustandskanal SC übermittelbare bzw. zu übermittelnde Informationen.
  • Bei weiteren bevorzugten Ausführungsformen weist die Vorrichtung 200 eine optionale, Ressourcenschnittstelle 208 zur Bereitstellung der Ressource(n) R auf. Im Falle von elektrischer Energie als Ressource kann die Ressourcenschnittstelle 208 z.B. dazu ausgebildet sein, arbeitsfähige elektrische Ladung vorzuhalten.
  • Weitere beispielhafte Ausführungsformen, vgl. 3A, beziehen sich auf ein Verfahren zum Anfordern einer Ressource R, aufweisend die folgenden Schritte: Senden 150 einer Anforderung A bezüglich einer Nutzung der Ressource R, insbesondere an eine Vorrichtung 200 gemäß den Ausführungsformen, und, optional, Etablieren 152 eines bzw. des Zustandskanals SC, und, optional, Empfangen 154 der Ressource R.
  • Bei weiteren beispielhaften Ausführungsformen, vgl. 3B, weist das Verfahren weiter auf: Senden 156 einer Statusaktualisierung SA, insbesondere über den Zustandskanal SC, an die Vorrichtung 200, z.B. um eine erneute Nutzung der Ressource R anzufordern, und, optional, weiteres Empfangen 158 der Ressource, insbesondere basierend auf der Statusaktualisierung SA.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf eine Vorrichtung 300 (1) zur Anforderung einer Ressource R, wobei die Vorrichtung 300 zur Ausführung des Verfahrens gemäß den Ausführungsformen (z.B. gemäß 3A, 3B) ausgebildet ist.
  • Bei weiteren beispielhaften Ausführungsformen kann die Vorrichtung 300 eine zu der Konfiguration 200 gemäß 5 vergleichbare Konfiguration aufweisen.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf ein System 1000 (1) zur Bereitstellung von wenigstens einer Ressource R, aufweisend wenigstens eine Vorrichtung 200 zur Bereitstellung der wenigstens einen Ressource R gemäß den Ausführungsformen und wenigstens eine Vorrichtung 300 zur Anforderung einer Ressource R gemäß den Ausführungsformen.
  • Bei weiteren beispielhaften Ausführungsformen ist vorgesehen, dass das System 1000 weiter wenigstens einen Hub 400 aufweist, der dazu ausgebildet ist, die Anforderung A zu empfangen und an die Vorrichtung 200 zur Bereitstellung der Ressource R weiterzuleiten bzw. den Zustandskanal SC zu realisieren.
  • 6A zeigt beispielhaft eine Konfiguration, bei der ein Zustandskanal SC ( 2A), z.B. auch ein virtueller Zustandskanal VC im Sinne der [Referenz 1] (vgl. dort z.B. 4, „Virtual state channel creation“) zwischen der die Ressource bereitstellenden Vorrichtung 200 und dem prospektiven Konsumenten 300 etabliert ist. Eine Etablierung des virtuellen Zustandskanals VC kann bei weiteren bevorzugten Ausführungsformen z.B. unter Verwendung des Hubs 400 erfolgen, wobei die Vorrichtungen 200, 300 z.B. jeweils eine Verbindung V1, V2 zu dem Hub 400 aufnehmen und dann die Etablierung des virtuellen Zustandskanals VC initiiert wird.
  • Bei weiteren beispielhaften Ausführungsformen kann ein Austausch von Informationen und/oder Ressourcen als eine Art „Strom“ aufgefasst werden, vgl. 6B, wobei auf der einen Seite z.B. Geld oder einen entsprechenden Wert charakterisierende Informationen in Richtung der die Ressource bereitstellenden Vorrichtung 200 fließt bzw. fließen, s. Pfeil A1 aus 6B, z.B. im Rahmen von Mikrotransaktionen, und wobei auf der anderen Seite die angeforderte bzw. vereinbarte Ressource, z.B. elektrische Energie, von der bereitstellenden Vorrichtung 200 in Richtung Konsument 300 fließt, s. Pfeil A2, z.B. jeweils nach Freischaltung zur Nutzung der Ressource, z.B. in definierten zeitlichen Abständen.
  • 7 zeigt schematisch ein vereinfachtes Flussdiagramm gemäß weiteren beispielhaften Ausführungsformen. Element e1 symbolisiert das Senden eines digitalen Vertrags DV (4), z.B. ausgebildet als Ricardian Contract, von dem Konsumenten 300 an die die Ressource R bereitstellende Vorrichtung 200. Mit dem Senden e1 des digitalen Vertrags DV fordert der Konsument 300 demnach gemäß weiteren beispielhaften Ausführungsformen die Nutzung der Ressource R an.
  • Element e2 symbolisiert eine Validierung wenigstens einer mit dem digitalen Vertrag DV assoziierten und/oder darin enthaltenen digitalen Signatur SIG-1, z.B. anhand einer dezentralisierten Kennung (DID), z.B. um sicherzustellen, dass die wenigstens eine Signatur SIG-1 nicht manipuliert worden ist.
  • Element e3 aus Block B1 symbolisiert eine fehlgeschlagene Validierung. In diesem Fall kann der Ablauf z.B. abgebrochen werden, und es wird beispielsweise kein Zustandskanal SC oder virtueller Zustandskanal VC etabliert, und es wird beispielsweise die angeforderte Ressource R nicht bereitgestellt.
  • Andernfalls, d.h., falls die Validierung e2 erfolgreich war, wird zu Block B2 übergegangen, wobei z.B. ein (virtueller) Zustandskanal etabliert wird, vgl. das Element e4. Beispielsweise kann die Vorrichtung 200 eine Aufforderung bzw. Anfrage e4 an den Konsumenten 300 senden, um den (virtuellen) Zustandskanal zu etablieren bzw. den Konsumenten 300 dazu aufzufordern, den (virtuellen) Zustandskanal zu etablieren bzw. an der Etablierung des (virtuellen) Zustandskanals mitzuwirken. Ein bei weiteren beispielhaften Ausführungsformen nutzbares Funding und/oder für die Etablierung des (virtuellen) Zustandskanals genutztes System bzw. Protokoll, z.B. Zustandskanalprotokoll (state channel protocol), kann z.B. basierend auf dem digitalen Vertrag DV ermittelt werden.
  • Element e5 symbolisiert die Initiierung des (virtuellen) Zustandskanals SC, VC, beispielsweise unter Einbeziehung des Konsumenten 300, s. z.B. auch die Bezugszeichen V1, V2, VC gemäß 6A.
  • Nach erfolgreicher Initiierung des (virtuellen) Zustandskanals bekommt der Konsument 300 Zugriff auf die angeforderte Ressource R, wobei Element e6 aus 7 z.B. die Freigabe der Ressource R symbolisiert. Bei weiteren bevorzugten Ausführungsformen kann die Ressource R beispielsweise über eine entsprechende optionale Schnittstelle 208 (5) der Vorrichtung 200 selbst bereitgestellt werden (und z.B. über eine entsprechende bzw. komplementäre Ressourcenschnittstelle (nicht gezeigt) der Vorrichtung 300 entgegengenommen werden). Bei weiteren bevorzugten Ausführungsformen kann die Vorrichtung 200 die Freigabe e6 der Ressource R z.B. auch einer anderen (nicht gezeigten) Einheit, die zur Bereitstellung der Ressource R ausgebildet ist, signalisieren.
  • Element e7 aus 7 symbolisiert einen Zustand, in dem der Zugriff durch den Konsumenten 300 auf die angeforderte Ressource R möglich ist.
  • In Block B3 sendet der Konsument 300, beispielsweise mit seinem Schlüssel K-1 (4) digital signierte, Statusaktualisierungen e8, z.B. zu beispielsweise mittels des digitalen Vertrags DV vereinbarten Zeiträumen bzw. Zeitpunkten an die die Ressource R bereitstellende Vorrichtung 200, z.B. um eine erneuerte Nutzung einzufordern.
  • Die Vorrichtung 200 validiert den aktualisierten Status, vgl. Element e9, und wenn dieser aktualisierte Status den vereinbarten Konditionen entspricht, aktualisiert die Vorrichtung 200 die Nutzung, vgl. Element e11, und signiert die ihrerseits den Status und sendet den nun auch von ihr signierten Status mit der vereinbarten Nutzung an den Konsumenten 300, vgl. Element e12. Andernfalls, d.h. sofern die Validierung e9 nicht erfolgreich war, wird der Ablauf abgebrochen, vgl. Element e10.
  • Sind die Bedingungen für die weitere Nutzung nicht mehr gegeben, entweder durch den Verbrauch des vereinbarten Zahlungsmittels oder den Ablauf eines Zeitraums, beendet die Vorrichtung 200 die mögliche Nutzung, vgl. Element e13 gemäß 7, und vollzieht z.B. eine definierte Endroutine, vgl. auch den beispielhaften Ablauf gemäß 2D.
  • Bei weiteren beispielhaften Ausführungsformen initiiert, vgl. Element e13, eine der Parteien (Konsument 300/Vorrichtung 200) die Schließung des (virtuellen) Zustandskanals, vgl. Block B4.
  • Weitere beispielhafte Ausführungsformen, vgl. 8, beziehen sich auf eine Verwendung 500 des Verfahrens gemäß den Ausführungsformen und/oder der Vorrichtung 200, 300 gemäß den Ausführungsformen und/oder des Systems 1000 gemäß den Ausführungsformen und/oder des computerlesbaren Speichermediums SM gemäß den Ausführungsformen und/oder des Computerprogramms PRG gemäß den Ausführungsformen und/oder des Datenträgersignals DCS gemäß den Ausführungsformen für wenigstens eines der folgenden Elemente: a) Bereitstellen 502 wenigstens einer Ressource R, b) Verwalten 504 der Bereitstellung der wenigstens einen Ressource, c) Übertragen 506 der Anforderung A über einen Zustandskanal SC, d) Ermöglichen 508 einer, insbesondere feingranularen, Bezahlung, insbesondere zumindest nahezu in Echtzeit, für eine Bereitstellung von wenigstens einer Ressource R, e) Aufbauen 501a und/oder Abbauen 510b und/oder Nutzen 510c eines Zustandskanals SC, insbesondere Nutzen des Zustandskanals SC zur Bezahlung einer, insbesondere angeforderten, Ressource R, f) geteilte Nutzung 512 eines Fahrzeugs, insbesondere Kraftfahrzeugs, z.B. Car-Sharing, g) Bereitstellen 514 elektrischer Energie, insbesondere zum Aufladen wenigstens einer Vorrichtung zur zumindest zeitweisen Speicherung von, insbesondere arbeitsfähiger, elektrischer Ladung, h) Nutzung 516 eines Werkzeugs, beispielsweise Handwerkzeugs, beispielsweise in Form eines Shareconomy-Prinzips, i) Nutzung 518 einer Schnittstelle, beispielsweise Programmierschnittstelle (API).
  • Weitere beispielhafte Ausführungsformen beziehen sich auf die Anwendung eines Car Sharing - Prinzips unter Verwendung des Prinzips gemäß den vorstehend beschriebenen beispielhaften Ausführungsformen: Ein Nutzer vereinbart mit einem Car Sharing - Anbieter die Nutzung eines Autos zu ausgehandelten Konditionen, z.B. direkt oder über einen Marktplatz. Die Konditionen wie z.B. Preis / Minute und/oder DID des Nutzers und des Anbieters, evtl. eine spezifische Auto DID wenn vereinbart, und/oder eine Verlinkung zu allgemeinen Geschäftsbedingungen (AGB), und/oder DLT System 10, und/oder Währung wie z.B. Payment Token und eine ID/Timestamp sind z.B. in einem Ricardian Contract DV (4) enthalten und z.B. von beiden Parteien signiert. Die Signatur wird z.B. anhand der vereinbarten Konditionen erstellt, z.B. damit diese nicht veränderbar sind.
  • Der Nutzer bzw. Konsument, dem z.B. die Vorrichtung 300 gemäß den Ausführungsformen zugeordnet ist, macht nun das Auto ausfindig und schickt diesem vor Ort über eine Datenverbindung (z.B. direkt, drahtlos oder drahtgebunden, über eine Cloud, oder auf sonstige Weise) den Ricardian Contract DV, vgl. auch das Element e1 gemäß 7. Das Auto, dem z.B. die Vorrichtung 200 gemäß den Ausführungsformen zugeordnet ist, validiert den Ricardian Contract DV, vgl. auch das Element e2 gemäß 7. Bei erfolgreicher Validierung bekommt der Nutzer bzw. die Vorrichtung 300 die Antwort e4 (7) zum Initiieren eines Zustandskanals SC. Das beispielhaft definierte Protokoll für die Initialisierung e5 (7) wird z.B. von beiden Parteien 200, 300 ausgeführt. Nach erfolgreicher Initiierung e5 gibt das Auto (bzw. die ihm zugeordnete Vorrichtung 200) den Zugriff frei für den Nutzer (bzw. die ihm zugeordnete Vorrichtung 300) und entsperrt sich, vgl. Element e6. Der Nutzer (bzw. die ihm zugeordnete Vorrichtung 300) überträgt nun z.B. jede Minute einen neuen Status e8, der z.B. einen Transfer der vereinbarten Kosten von dem Nutzerkonto auf das vereinbarte Konto der Vorrichtung 200 bzw. einer mit der Vorrichtung 200 assoziierten Partei (z.B. Anbieter des Car Sharing Autos) enthält. Der neue Status wird von beiden Parteien 200, 300 signiert. Als Gegenleistung erlaubt das Auto (bzw. die ihm zugeordnete Vorrichtung 200) die Nutzung für z.B. eine weitere Minute. Sobald z.B. das Ziel (z.B. Fahrtende) erreicht ist, wird eine beispielhaft definierte Shutdown Routine ausgeführt, und beide Parteien 200, 300 haben z.B. die Möglichkeit, den Zustandskanal SC zu schließen. Im Falle eines vorigen Verbrauchs des beim Öffnen des Zustandskanals hinterlegten Geldes führt das Auto (bzw. die ihm zugeordnete Vorrichtung 200) eine definierte Exit Routine aus, wie z.B. bei der nächsten Möglichkeit anzuhalten und die Weiterfahrt zu sperren.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf die Anwendung eines Prinzips zum Laden eines elektrischen Verbrauchers und/oder Speichers (z.B. Batterie (nicht gezeigt)) mit elektrischer Energie unter Verwendung des Prinzips gemäß den vorstehend beschriebenen beispielhaften Ausführungsformen: Ein Nutzer (dem beispielsweise die Vorrichtung 300 und eine Batterie zugeordnet ist) vereinbart mit einem Ladesäulen-Anbieter oder - Betreiber (dem beispielsweise die Vorrichtung 200 zugeordnet ist) die Nutzung einer Ladesäule zu ausgehandelten Konditionen, z.B. direkt oder über einen Marktplatz. Die Konditionen wie z.B. Preis / kWh, DID's des Nutzers und des Anbieters, evtl. spezifische Ladesäule DID wenn vereinbart, Verlinkung zu AGB, DLT System, Währung wie z.B. Payment Token und eine ID/Timestamp sind z.B. in einem Ricardian Contract DV (4) enthalten und z.B. von beiden Parteien 200, 300 digital signiert. Die digitale Signatur wird z.B. anhand der vereinbarten Konditionen erstellt, z.B. damit diese nicht veränderbar sind. Der Nutzer 300 macht nun die Ladesäule 200 ausfindig und schickt dieser vor Ort über eine Verbindung (z.B. direkt, drahtlos oder drahtgebunden, über eine Cloud, oder auf sonstige Weise) den Ricardian Contract DV. Die Ladesäule 200 validiert den Ricardian Contract DV. Bei erfolgreicher Validierung bekommt der Nutzer 300 die Antwort e4 (7) zum Initiieren des Zustandskanals. Das Protokoll für die Initialisierung des Zustandskanals SC wird z.B. von beiden Parteien 200, 300 ausgeführt. Nach erfolgreicher Initiierung gibt die Ladesäule 200 den Zugriff frei für den Nutzer 300 und entsperrt sich. Der Nutzer überträgt nun z.B. jede Minute einen neuen Status, der einen Transfer der vereinbarten Kosten von dem Nutzerkonto auf das vereinbarte Konto der Ladesäule 200 bzw. ihres Betreibers enthält. Der neue Status wird von beiden Parteien signiert. Als Gegenstück transferiert die Ladesäule 200 ein weiteres Quantum elektrischer Energie an den Nutzer 300. Sobald z.B. die Batterie vollständig geladen ist, wird eine Shutdown Routine ausgeführt, die es den Parteien 200, 300 ermöglicht, den Zustandskanal SC zu schließen. Im Falle eines vorigen Verbrauchs des beim Öffnen des Zustandskanals hinterlegten Geldes führt die Ladesäule z.B. eine definierte Exit Routine aus, wie z.B. den Abbruch des Ladevorganges.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf die Anwendung eines Shareconomy - Prinzips zum zeitweisen Nutzen z.B. eines Elektrowerkzeugs wie z.B. einer Bohrmaschine unter Verwendung des Prinzips gemäß den vorstehend beschriebenen beispielhaften Ausführungsformen, wobei z.B. der vorstehend beispielhaft unter Bezugnahme auf 7 beschriebene Ablauf zumindest teilweise nutzbar ist: Ein Nutzer (dem beispielsweise die Vorrichtung 300 zugeordnet ist) vereinbart mit einem Werkzeug-Anbieter (dem bzw. dessen Werkzeugen beispielsweise die Vorrichtung 200 zugeordnet ist) die Nutzung eines Werkzeugs, z.B. Bohrmaschine, zu ausgehandelten Konditionen, z.B. direkt oder über einen Marktplatz. Die Konditionen wie z.B. Preis / Minute, DID's des Nutzers und des Anbieters, evtl. spezifische Maschinen DID wenn vereinbart, Verlinkung zu AGB, DLT System, Währung wie z.B. Payment Token und eine ID/Timestamp sind z.B. in einem Ricardian Contract DV enthalten und von beiden Parteien signiert. Die Signatur wird z.B. anhand der vereinbarten Konditionen erstellt, damit diese nicht veränderbar sind. Der Nutzer macht nun das Werkzeug ausfindig und schickt diesem vor Ort über eine Verbindung (z.B. direkt, Cloud, ...) den Ricardian Contract DV. Das Werkzeug validiert diesen. Bei erfolgreicher Validierung (vgl. z.B. Element e2 aus 7) bekommt der Nutzer die Antwort zum Initiieren des Zustandskanals SC (vgl. z.B. Element e4 aus 7). Das Protokoll für die Initialisierung wird von beiden Parteien ausgeführt. Nach erfolgreicher Initiierung gibt das Werkzeug den Zugriff frei für den Nutzer und entsperrt sich (vgl. z.B. Element e6 aus 7). Der Nutzer überträgt nun z.B. jede Minute einen neuen Status (vgl. z.B. Element e8 aus 7), der einen Transfer der vereinbarten Kosten von dem Nutzerkonto auf das vereinbarte Konto des Werkzeug-Anbieters enthält, über den Zustandskanal SC. Dieser neue Status wird von beiden Parteien signiert. Als Gegenstück erlaubt das Werkzeug die Nutzung für eine weitere Minute (vgl. z.B. Element e12 aus 7). Sollte das Ziel erreicht sein, wird eine Shutdown Routine ausgeführt und z.B. beide Parteien 200, 300 haben die Möglichkeit, den Zustandskanal SC zu schließen. Im Falle eines vorigen Verbrauchs des gesperrten Geldes führt das Werkzeug bzw. der Anbieter mittels der Vorrichtung 200 eine Exit Routine aus, wie z.B. die Sperrung der weiteren Nutzung.
  • Weitere beispielhafte Ausführungsformen beziehen sich auf eine Nutzung einer Programmierschnittstelle (API) unter Verwendung des Prinzips gemäß den vorstehend beschriebenen beispielhaften Ausführungsformen, wobei z.B. der vorstehend beispielhaft unter Bezugnahme auf 7 beschriebene Ablauf zumindest teilweise nutzbar ist: Ein Nutzer (dem beispielsweise die Vorrichtung 300 zugeordnet ist) vereinbart mit einem API Anbieter die Nutzung einer definierten API (z.B. Wetterdaten) zu ausgehandelten Konditionen, z.B. direkt oder über einen Marktplatz. Die Konditionen wie z.B. Preis / Datensatz, DID's des Nutzers und des Anbieters, evtl. spezifische API Identifikatoren (z.B. URI, uniform ressource identifier) wenn vereinbart, Verlinkung zu AGB, DLT System 10, Währung wie z.B. Payment Token und eine ID/Timestamp sind z.B. in einem Ricardian Contract DV (4) enthalten und z.B. von beiden Parteien 200, 300 signiert. Die Signatur wird z.B. anhand der vereinbarten Konditionen erstellt, z.B. damit diese nicht veränderbar sind. Der Nutzer schickt nun dem API den Ricardian Contract DV um die Nutzung des API zu beantragen, vgl. z.B. das Element e1 aus 7. Der API Anbieter bzw. die ihm zugeordnete Vorrichtung 200 validiert diesen, vgl. z.B. das Element e2 aus 7. Bei erfolgreicher Validierung bekommt der Nutzer die Antwort zum initiieren des Zustandskanals SC. Das Protokoll für die Initialisierung wird von beiden Parteien ausgeführt. Nach erfolgreicher Initiierung gibt der API Service den Zugriff frei für den Nutzer und entsperrt sich. Der Nutzer überträgt nun bei jedem Request e8 (7) eines Datensatzes einen neuen Status, der einen Transfer der vereinbarten Kosten von dem Nutzerkonto auf das vereinbarte Konto der Ressource enthält. Dieser wird von beiden Parteien signiert. Als Gegenstück transferiert der API Service 200 einen weiteren Datensatz, vgl. Element e12. Sollte das Ziel erreicht sein, wird eine definierte Shutdown Routine ausgeführt und z.B. beide Parteien haben die Möglichkeit, den Zustandskanal SC zu schließen. Im Falle eines vorigen Verbrauchs des gesperrten Geldes führt der API Service eine definierte Exit Routine aus, wie z.B. das Sperren des Zugriffs für den Nutzer.
  • Weitere beispielhafte Ausführungsformen ermöglichen die Schaffung eines dezentralen Prinzips, welches es ermöglicht, z.B. eine feingranulare Bezahlung für die Nutzung einer Ressource R zu erreichen, z.B. unter Nutzung von Mikrotransaktionen. Zudem kann diese Bezahlung bei weiteren beispielhaften Ausführungsformen vergleichsweise schnell, beispielsweise nahezu in Echtzeit, vollzogen werden, was z.B. auch das Vertrauen zwischen zwei unbekannten Entitäten (z.B. Nutzer der Vorrichtungen 200, 300) erhöht.
  • Durch den dezentralen Mechanismus wird bei weiteren beispielhaften Ausführungsformen sichergestellt, dass keine zentrale Partei alleinig Daten sammeln kann, z.B. in Bezug auf die Durchführung einer ökonomischen Transaktion. Zudem wird die Anzahl der Transaktionen auf einem optionalen Drittsystem (z.B. DLT-System 10) reduziert und damit ein wichtiger Beitrag zur Skalierbarkeit gemacht.
  • Bei weiteren beispielhaften Ausführungsformen ermöglichen Smart Contracts oder digitale Verträge DV sich z.B. gegenseitig misstrauenden, individuell rational handelnden Parteien, optional z.B. mit Hilfe von Distributed Ledger Technology (DLT), zuverlässig und fair Verträge zu schließen und ggf. durchzusetzen. Dabei definiert der Smart Contract bei weiteren beispielhaften Ausführungsformen den Vertragsinhalt als Programmcode, während das optionale DLT-System 10 eine dezentrale Plattform stellt, die diesen Programmcode zuverlässig korrekt und verifizierbar ausführt und somit als „dezentraler Notarservice“ betrachtet werden kann.
  • Bei weiteren beispielhaften Ausführungsformen ist es mithilfe von wenigstens einem Zustandskanal SC möglich, Smart Contracts bzw. digitale Verträge ohne Kommunikation mit einem Ledger auszuführen und trotzdem die zugesicherten Eigenschaften zu behalten. Sobald bei weiteren beispielhaften Ausführungsformen ein Zustandskanal erstellt ist, können Smart Contracts bzw. digitale Verträge DV effizient (bestenfalls in Echtzeit) zwischen den erstellenden Parteien geschlossen und ausgeführt werden. Bei weiteren beispielhaften Ausführungsformen kann die Vernetzung mehrerer Zustandskanäle zu einem Netzwerk von Zustandskanälen eine sog. off-chain Ausführung der Verträge auch über mehrere Zustandskanäle hinweg ermöglichen, sodass die vertragschließenden Parteien bei weiteren beispielhaften Ausführungsformen nicht notwendigerweise einen eigenen Zustandskanal eröffnen müssen.
  • Sind bei weiteren beispielhaften Ausführungsformen Parteien über ein Netzwerk von Zustandskanälen verbunden, ohne z.B. selbst direkt durch einen Zustandskanal („base channel“) verbunden zu sein, haben sie bei weiteren beispielhaften Ausführungsformen z.B. die Möglichkeit, in Echtzeit einen virtuellen Zustandskanal zu erstellen, insbesondere ohne mit dem Ledger zu kommunizieren.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • Stefan Dziembowski, Sebastian Faust, and Kristina Hostäkovä. 2018. General State Channel Networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS '18). Association for Computing Machinery, New York, NY, USA, 949-966 [0006, 0051]
    • S. Dziembowski, L. Eckey, S. Faust and D. Malinowski, „Perun: Virtual Payment Hubs over Cryptocurrencies,“ 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2019, pp. 106-123 [0007, 0052]

Claims (17)

  1. Verfahren, insbesondere computerimplementiertes Verfahren, zum Verwalten einer Bereitstellung einer Ressource (R), aufweisend die folgenden Schritte: Empfangen (100) einer Anforderung (A) bezüglich einer Nutzung der Ressource, Validieren (110) der Anforderung (A), und, basierend auf der Validierung (110) der Anforderung (A), Etablieren (120) eines Zustandskanals (SC).
  2. Verfahren nach Anspruch 1, wobei die Anforderung (A) einen digitalen Vertrag (DV), beispielsweise einen Ricardian Contract, aufweist, wobei der digitale Vertrag (DV) wenigstens eine Signatur (SIG-1, SIG-2) aufweist, wobei das Validieren (110) das Überprüfen der wenigstens einen Signatur (SIG-1, SIG-2) aufweist.
  3. Verfahren nach wenigstens einem der vorstehenden Ansprüche, wobei das Etablieren (120) des Zustandskanals wenigstens eines der folgenden Elemente aufweist: a) Verwenden (120a) eines Smart Contracts (14), der beispielsweise mittels eines Distributed-Ledger-Technologie, DLT, -Systems (10) verwaltet wird, insbesondere zum Verankern des Zustandskanals (SC), b) Verwenden (120b) eines Hubs (400), der dazu ausgebildet ist, die Anforderung (A) von einer weiteren Einheit (300), insbesondere einem prospektiven Konsumenten (300) der Ressource (R), zu empfangen und weiterzuleiten.
  4. Verfahren nach wenigstens einem der vorstehenden Ansprüche, weiter aufweisend: Freigeben (122) einer Nutzung der Ressource (R).
  5. Verfahren nach wenigstens einem der vorstehenden Ansprüche, weiter aufweisend: Empfangen (130) von wenigstens einer, beispielsweise signierten, Statusaktualisierung (SA), insbesondere von einem Konsumenten (300), Validieren (132) eines durch die Statusaktualisierung (SA) charakterisierten, insbesondere aktualisierten, Status.
  6. Verfahren nach Anspruch 5, weiter aufweisend Signieren (134) des, insbesondere aktualisierten, Status, Senden (136) des, insbesondere aktualisierten, Status, insbesondere an den Konsumenten (300).
  7. Verfahren nach wenigstens einem der vorstehenden Ansprüche, weiter aufweisend: Ermitteln (140), ob Bedingungen für eine Nutzung der Ressource, insbesondere noch, gegeben sind, und, optional, Beenden (142) einer möglichen Nutzung der Ressource, und, optional, Schließen (144) des Zustandskanals (SC).
  8. Vorrichtung (200) zum Verwalten der Bereitstellung einer Ressource (R), wobei die Vorrichtung (200) zur Ausführung des Verfahrens nach wenigstens einem der vorstehenden Ansprüche ausgebildet ist.
  9. Verfahren zum Anfordern einer Ressource, aufweisend die folgenden Schritte: Senden (150) einer Anforderung (A) bezüglich einer Nutzung der Ressource, insbesondere an eine Vorrichtung (200) gemäß Anspruch 8, und, optional, Etablieren (152) eines bzw. des Zustandskanals (SC), und, optional, Empfangen (154) der Ressource.
  10. Verfahren nach Anspruch 9, weiter aufweisend: Senden (156) einer Statusaktualisierung (SA), und, optional, weiteres Empfangen (158) der Ressource, insbesondere basierend auf der Statusaktualisierung (SA).
  11. Vorrichtung (300) zur Anforderung einer Ressource, wobei die Vorrichtung (300) zur Ausführung des Verfahrens nach wenigstens einem der Ansprüche 9 bis 10 ausgebildet ist.
  12. System (1000) zur Bereitstellung von wenigstens einer Ressource, aufweisend wenigstens eine Vorrichtung (200) zur Bereitstellung der wenigstens einen Ressource gemäß Anspruch 8, und wenigstens eine Vorrichtung (300) zur Anforderung einer Ressource, insbesondere gemäß Anspruch 11.
  13. System (1000) nach Anspruch 12, weiter aufweisend wenigstens einen Hub (400), der dazu ausgebildet ist, die Anforderung (A) zu empfangen und an die Vorrichtung (200) zur Bereitstellung der Ressource weiterzuleiten.
  14. Computerlesbares Speichermedium (SM), umfassend Befehle (PRG), die bei der Ausführung durch einen Computer (202) diesen veranlassen, das Verfahren nach wenigstens einem der Ansprüche 1 bis 7 und/oder 9 bis 10 auszuführen.
  15. Computerprogramm (PRG), umfassend Befehle, die bei der Ausführung des Programms (PRG) durch einen Computer (202) diesen veranlassen, das Verfahren nach wenigstens einem der Ansprüche 1 bis 7 und/oder 9 bis 10 auszuführen.
  16. Datenträgersignal (DCS), das das Computerprogramm nach Anspruch 15 überträgt und/oder charakterisiert.
  17. Verwendung (500) des Verfahrens nach wenigstens einem der Ansprüche 1 bis 7 und/oder 9 bis 10 und/oder der Vorrichtung (200) nach Anspruch 8 und/oder der Vorrichtung (300) nach Anspruch 11 und/oder des Systems (1000) nach wenigstens einem der Ansprüche 12 bis 13 und/oder des computerlesbaren Speichermediums (SM) nach Anspruch 14 und/oder des Computerprogramms (PRG) nach Anspruch 15 und/oder des Datenträgersignals (DCS) nach Anspruch 16 für wenigstens eines der folgenden Elemente: a) Bereitstellen (502) wenigstens einer Ressource, b) Verwalten (504) der Bereitstellung der wenigstens einen Ressource, c) Übertragen (506) der Anforderung (A) über einen Zustandskanal (SC), d) Ermöglichen (508) einer, insbesondere feingranularen, Bezahlung, insbesondere zumindest nahezu in Echtzeit, für eine Bereitstellung von wenigstens einer Ressource, e) Aufbauen (510a) und/oder Abbauen (510b) und/oder Nutzen (510c) eines Zustandskanals (SC), insbesondere Nutzen des Zustandskanals (SC) zur Bezahlung einer, insbesondere angeforderten, Ressource, f) geteilte Nutzung (512) eines Fahrzeugs, insbesondere Kraftfahrzeugs, z.B. Car-Sharing, g) Bereitstellen (514) elektrischer Energie, insbesondere zum Aufladen wenigstens einer Vorrichtung zur zumindest zeitweisen Speicherung von, insbesondere arbeitsfähiger, elektrischer Ladung, h) Nutzung (516) eines Werkzeugs, beispielsweise Handwerkzeugs, i) Nutzung (518) einer Schnittstelle, beispielsweise Programmierschnittstelle.
DE102020207619.7A 2020-06-19 2020-06-19 Verfahren und Vorrichtung zur Bereitstellung einer Ressource Pending DE102020207619A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102020207619.7A DE102020207619A1 (de) 2020-06-19 2020-06-19 Verfahren und Vorrichtung zur Bereitstellung einer Ressource
US17/306,619 US11861559B2 (en) 2020-06-19 2021-05-03 Method and device for providing a resource
CN202110682464.5A CN113821562A (zh) 2020-06-19 2021-06-18 用于提供资源的方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102020207619.7A DE102020207619A1 (de) 2020-06-19 2020-06-19 Verfahren und Vorrichtung zur Bereitstellung einer Ressource

Publications (1)

Publication Number Publication Date
DE102020207619A1 true DE102020207619A1 (de) 2021-12-23

Family

ID=78822948

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020207619.7A Pending DE102020207619A1 (de) 2020-06-19 2020-06-19 Verfahren und Vorrichtung zur Bereitstellung einer Ressource

Country Status (3)

Country Link
US (1) US11861559B2 (de)
CN (1) CN113821562A (de)
DE (1) DE102020207619A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210314293A1 (en) * 2020-04-02 2021-10-07 Hewlett Packard Enterprise Development Lp Method and system for using tunnel extensible authentication protocol (teap) for self-sovereign identity based authentication
US11822701B2 (en) * 2021-04-09 2023-11-21 VIQ Solutions Inc. Securing and managing offline digital evidence with a smart data lease system

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100218108A1 (en) * 2009-02-26 2010-08-26 Jason Crabtree System and method for trading complex energy securities
WO2011109460A2 (en) * 2010-03-02 2011-09-09 Liberty Plug-Ins, Inc. Method and system for using a smart phone for electrical vehicle charging
WO2011124298A2 (de) * 2010-03-29 2011-10-13 Ifs Informationstechnik Gmbh Vorrichtung und verfahren zum kontrollierten energieaustausch zwischen einem stromnetz und einem verbraucher
US10861112B2 (en) * 2012-07-31 2020-12-08 Causam Energy, Inc. Systems and methods for advanced energy settlements, network-based messaging, and applications supporting the same on a blockchain platform
US11080665B1 (en) * 2015-06-08 2021-08-03 Blockstream Corporation Cryptographically concealing amounts and asset types for independently verifiable transactions
FR3060890B1 (fr) * 2016-12-19 2019-08-23 Electricite De France Transmission d'energie electrique entre entites usageres d'un reseau de distribution
CN107627867B (zh) * 2017-01-09 2020-12-08 上海蔚来汽车有限公司 待充电对象充电授权方法、充电设备自动授权方法和系统
WO2018160228A1 (en) * 2017-03-03 2018-09-07 General Electric Company Microgrid energy reservoir transaction verification via secure, distributed ledger
US11150271B2 (en) * 2018-05-15 2021-10-19 International Business Machines Corporation Method or system for management of a device for energy consumption by applying blockchain protocol
US10673273B2 (en) * 2018-05-18 2020-06-02 General Electric Company Distributed ledger based control of large-scale, power grid energy resources
GB2577853B (en) * 2018-06-22 2021-03-24 Moixa Energy Holdings Ltd Systems for machine learning, optimising and managing local multi-asset flexibility of distributed energy storage resources

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
S. Dziembowski, L. Eckey, S. Faust and D. Malinowski, „Perun: Virtual Payment Hubs over Cryptocurrencies," 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2019, pp. 106-123
Stefan Dziembowski, Sebastian Faust, and Kristina Hostäkovä. 2018. General State Channel Networks. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS '18). Association for Computing Machinery, New York, NY, USA, 949-966

Also Published As

Publication number Publication date
CN113821562A (zh) 2021-12-21
US20210398075A1 (en) 2021-12-23
US11861559B2 (en) 2024-01-02

Similar Documents

Publication Publication Date Title
WO2020212337A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten sowie bezahlsystem
EP3182318B1 (de) Signaturgenerierung durch ein sicherheitstoken
DE102020207619A1 (de) Verfahren und Vorrichtung zur Bereitstellung einer Ressource
DE102012221288A1 (de) Verfahren, Vorrichtung und Dienstleistungsmittel zur Authentifizierung eines Kunden für eine durch ein Dienstleistungsmittel zu erbringende Dienstleistung
EP2467839A1 (de) Verfahren und vorrichtung zur identifizierung eines elektrofahrzeugs gegenüber einer abrechnungszentrale
DE102019108891A1 (de) Verfahren und Vorrichtung zur Zuordnung eines von einer Ladestation erfassten Messwertes zu einem Nutzer
WO2021170645A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
Fridgen et al. Chancen und herausforderungen von dlt (blockchain) in mobilität und logistik
DE102015213180A1 (de) Verfahren und Vorrichtung zur Authentifizierung eines Dienstnutzers für eine zu erbringende Dienstleistung
DE102016103128A1 (de) Ein Verfahren zur Zugriffssteuerung an Kraftfahrzeugen
DE102020213017A1 (de) Verfahren zum Bereitstellen eines Zustandskanals
EP3254432B1 (de) Verfahren zur berechtigungsverwaltung in einer anordnung mit mehreren rechensystemen
WO2023036458A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
DE102012017826A1 (de) Verfahren zur Erstellung einer abgeleiteten Instanz eines Originaldatenträgers
EP3619885B1 (de) Verfahren zum blockchain basierten, asymmetrischen schlüsselmanagement und sicherheitsrelevante anlage
EP4072180A1 (de) Verfahren zur autorisierung eines ladevorgangs an einem ladepunkt
DE102020213240A1 (de) Verfahren und Vorrichtung zum Abwickeln einer Transaktion zwischen mehreren Partitionen einer Blockkette
WO2021110425A1 (de) Verfahren und messeinheit zur identitätsgesicherten bereitstellung eines messdatensatzes
DE102015204828A1 (de) Verfahren zur Erzeugung eines Zertifikats für einen Sicherheitstoken
EP3283999B1 (de) Elektronisches system zur erzeugung eines zertifikats
DE102020208342A1 (de) Vorrichtung zum Ausführen von Transaktionen und Betriebsverfahren hierfür
DE102020207617A1 (de) Verfahren und Vorrichtung zur Bereitstellung einer Ressource
DE102014014109A1 (de) Transaktionsverfahren
DE102020205529A1 (de) Verfahren und Vorrichtung zum Aushandeln intelligenter Verträge
DE102020210810A1 (de) Verfahren und Vorrichtung zum gegenseitigen Bewerten von Leistungserbringern und Leistungsempfänger mittels einer dezentralen Transaktionsdatenbank