DE102021207176A1

DE102021207176A1 - Dezentrale datenversorgungskettenherkunft

Info

Publication number: DE102021207176A1
Application number: DE102021207176.7A
Authority: DE
Inventors: Ned M. Smith; Kshitij Arun Doshi; Francesc Guim Bernat
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-09-25
Filing date: 2021-07-07
Publication date: 2022-03-31
Also published as: NL2029032B1; NL2029032A; US20210012282A1

Abstract

Es werden Einrichtungen, Systeme, Herstellungsartikel und Verfahren zum Erzeugen eines Datenversorgungskettenobjekts offenbart. Ein hier offenbartes beispielhaftes nichtflüchtiges computerlesbares Speichermedium beinhaltet Daten, die in ausführbare Anweisungen konfiguriert sein können, und die, wenn sie konfiguriert und ausgeführt werden, bewirken, dass ein oder mehrere Prozessoren mindestens Folgendes ausführen: Ableiten einer Herkunft eines ersten Datenversorgungskettenobjekts; Identifizieren eines ersten Stakeholders aus der Herkunft; Bestimmen, ob der erste Stakeholder verifiziert ist; Nutzen von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert ist; Aufbauen einer Tag-Wert-Struktur basierend auf der Nutzung der Daten; Aufbauen eines zweiten Datenversorgungkettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders; und Hinzufügen des zweiten Datenversorgungskettenobjekts zu der Datenversorgungskette.

Description

GEBIET DER OFFENBARUNG
Diese Offenbarung betrifft allgemein eine Datenverarbeitung und insbesondere eine dezentrale Datenversorgungskettenherkunft.
HINTERGRUND
Eine Blockchain ist eine Liste von Blöcken oder Aufzeichnungen, die unter Verwenden von Kryptographie verknüpft werden. Jeder Block in einer Blockchain kann einen Hash vorhergehender Blöcke, einen Zeitstempel und Transaktionsdaten beinhalten. Eine Blockchain kann von einem Peer-to-Peer-Netzwerk verwaltet werden, das ein Protokoll zur Internode-Kommunikation und Validierung neuer Blöcke in die Kette einhält. Eine Blockchain stellt einen dezentralen, verteilten und häufig öffentlichen digitalen Ledger bereit, um Transaktionen über viele Computer aufzuzeichnen.
Figurenliste
In den Zeichnungen, die nicht unbedingt maßstabsgetreu gezeichnet sind, können gleiche Bezugszeichen ähnliche Bauelemente in unterschiedlichen Ansichten beschreiben. Gleiche Bezugszeichen, die unterschiedliche Buchstaben-Suffixe aufweisen, können unterschiedliche Instanzen ähnlicher Bauelemente repräsentieren. Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der begleitenden Zeichnungen veranschaulicht, in welchen

1 einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing veranschaulicht.
2 Betriebsschichten unter Endpunkten, eine Edge-Cloud und Cloud-Rechenumgebungen veranschaulicht.
3 ein Blockdiagramm einer beispielhaften Umgebung für Networking und Dienste in einem Edge-Computing-System veranschaulicht.
4 den Einsatz einer virtuellen Edge-Konfiguration in einem Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird, veranschaulicht.
5 verschiedene Rechenanordnungen, die Container in einem Edge-Computing-System einsetzen, veranschaulicht.
6 einen beispielhaften Rechen- und Kommunikationsnutzungsfall, der Mobilzugriff auf Anwendungen in einem beispielhaften Edge-Computing-System involviert, veranschaulicht.
7 A ein Blockdiagramm einer beispielhaften Umsetzung eines beispielhaften Computerknotens ist, der in einem der in den 1 bis 4 und/oder6veranschaulichten Edge-Computersysteme eingesetzt werden kann.
7B ein anderes Blockdiagramm einer beispielhaften Umsetzung eines beispielhaften Rechenknotens ist, der in einem der in den 1 bis 4 und/oder 6 veranschaulichten Edge-Computing-Systeme eingesetzt werden kann.
8 eine beispielhafte Systemarchitektur einschließlich einer Gruppe von Datenversorgungskettenvorrichtungen, die zu einer Datenversorgungskette teilnehmen, gemäß Lehren dieser Offenbarung veranschaulicht.
9 ein Blockdiagramm einer beispielhaften Umsetzung eines Objektmanagers ist, der in der Systemarchitektur der 8 enthalten ist.
10A ein beispielhaftes Datenversorgungskettenobjekt veranschaulicht.
10B einen beispielhaften Blockchain-Merkle-Baum, der Datenversorgungskettenobjektaktualisierungen als Blockchain-Transaktionen akzeptiert, veranschaulicht.
11 A und 11 B ein Diagramm eines beispielhaften Attestierungsschemas sind.
11C und 11D ein Diagramm eines anderen beispielhaften AttestierungsSchemas sind.
12 ein Diagramm beispielhafter Attestierungsrollen und Workflow ist.
13 ein Diagramm beispielhafter Entitäten ist, die beispielhaften Attestierungsrollen und den Workflow der 12 umsetzen.
14 ein Diagramm ist, das eine beispielhafte Attestierungs-Kaskadierung in einer Datenversorgungskette zeigt.
15 ein Flussdiagramm ist, das beispielhafte maschinenlesbare Anweisungen repräsentiert, die ausgeführt werden können, um den beispielhaften Objektmanager der 8 und 9 umzusetzen, um die Herkunft geltend zu machen.
16 ein Flussdiagramm ist, das beispielhafte maschinenlesbare Anweisungen repräsentiert, die ausgeführt werden können, um den beispielhaften Objektmanager der 8 und 9 umzusetzen, um Herkunft und Dateneinschränkungen zu bestimmen.
17 ein Blockdiagramm einer beispielhaften Verarbeitungsplattform ist, die strukturiert ist, um die Anweisungen der 15 und 17, zum Umsetzen des beispielhaften Objektmanagers der 8 und 9 auszuführen.
18 ein Blockdiagramm einer beispielhaften Verarbeitungsplattform ist, die dazu strukturiert ist, den beispielhaften Blockchain- und/oder Objektüberwachungsdienst der 8 und 9 umzusetzen.

AUSFÜHRLICHE BESCHREIBUNG
Deskriptoren, wie etwa „erste“, „zweite“, „dritte“ usw., werden hier verwendet, wenn mehrere Elemente oder Bauelemente, auf die separat Bezug genommen werden kann, identifiziert werden. Sofern nichts Anderes basierend auf ihrem Verwendungskontext spezifiziert oder verstanden wird, bezwecken derartige Deskriptoren nicht, eine Bedeutung von Priorität, physischer Reihenfolge, Anordnung in einer Liste und/oder Reihenfolge auf irgendeine Weise zu implizieren oder anderswie anzugeben, sondern werden lediglich als Bezeichnungen und/oder willkürliche Namen verwendet, um Elemente zum einfachen Verstehen der offenbarten Beispiele zu unterscheiden. Bei einigen Beispielen kann der Deskriptor „erster“ verwendet werden, um auf ein Element in der ausführlichen Beschreibung zu verweisen, während auf dasselbe Element in einem Anspruch mit einem anderen Deskriptor wie etwa „zweiter“ oder „dritter“ verwiesen werden kann. In derartigen Fällen versteht es sich, dass derartige Deskriptoren lediglich zum eindeutigen Identifizieren jener Elemente verwendet werden, die zum Beispiel ansonsten einen gleichen Namen nutzen könnten. Wie hierin verwendet, verweisen „ungefähr“ und „etwa“ auf Abmessungen, die aufgrund von Herstellungstoleranzen und/oder anderer Realweltdefekten möglicherweise nicht exakt sind. Wie hierin verwendet, verweist „im Wesentlichen Echtzeit“ auf ein Auftreten auf eine nahezu augenblickliche Weise, die erkennt, dass es Realweltverzögerungen für Rechenzeit, Übertragung usw. geben kann. Sofern nichts anderes angegeben ist, verweist „im Wesentlichen Echtzeit“ somit auf Echtzeit +/-1 Sekunde.
Edge-Computing verweist auf einer allgemeine Ebene auf den Übergang von Cloud oder Cloud-ähnlichen Rechen- und Speicherressourcen näher an Endpunktvorrichtungen (zum Beispiel Verbraucherrechenvorrichtungen, Benutzergerät usw.), um Gesamtkosten der Eigentümerschaft zu optimieren, Anwendungslatenz zu reduzieren, Dienstfähigkeiten zu verbessern und die Einhaltung von Datenschutz oder Sicherheitsanforderungen zu verbessern. Edge-Computing kann bei einigen Szenarien einen Cloud-ähnlichen verteilten Dienst bereitstellen, der Orchestrierung und Verwaltung für Anwendungen unter vielen Arten von Speicherungs- und Rechenressourcen bietet. Infolgedessen wurden einige Umsetzungen des Edge-Computing als die „Edge-Cloud“ oder der „Fog“ bezeichnet, da leistungsstarke Rechenressourcen, die zuvor nur in großen entfernten Datenzentren verfügbar waren, näher an Endpunkte verlagert und zur Verwendung durch Verbraucher an dem „Edge“ des Netzwerks verfügbar gemacht werden.
Hierin sind beispielhafte Datenversorgungskettenobjekte (DSC-Objekte) offenbart, die einen Datenschutz, ein Durchsetzen von Rechten und/oder eine Kompensationskonformität ermöglichen. Zum Beispiel ermöglicht das Verwenden der hierin offenbarten beispielhaften DSC-Objekte, dass Künstler und/oder Inhaltserzeuger in der Lage sind, ihre Schutzrechte in einem verteilten und dezentralen Datenökosystem zu verfolgen. Bei einigen Beispielen erlaubt es die Verwendung der hierin offenbarten DSC-Objekte Medieneigentümern, Inferenzen, die von AI-getriebenen Entitäten erzeugt werden, unabhängig zu prüfen. Einige hierin offenbarte Beispiele erfordern keine zentralisierte Kontrollstelle, an der Mitglieder teilnehmen müssen, was zu einem flexiblen Governance-Model führt, das an lokale oder kommunale Bedürfnisse angepasst werden kann. Die hierin offenbarten Beispiele ermöglichen weiter Datenschutz in einer Edge-Umgebung.
1 ist ein Blockdiagramm 100, das einen Überblick über eine Konfiguration zum Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als eine „Edge-Cloud“ bezeichnet wird. Wie gezeigt, befindet sich die Edge-Cloud 110 gemeinsam an einem Edge-Ort, wie etwa mit einem Zugangspunkt oder einer Basisstation 140, einem lokalen Verarbeitungs-Hub 150 oder einer Zentralstelle 120, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 110 befindet sich viel näher an den Endpunktdatenquellen (Verbraucher und Erzeuger-Datenquellen 160 (zum Beispiel autonome Fahrzeuge 161, Benutzergerät 162, Geschäfts- und Industrieausstattung 163, Videoaufnahmevorrichtungen 164, Drohnen 165, intelligente Städten und Gebäudevorrichtungen 166, Sensoren und Vorrichtungen des Internets der Dinge (Internet of Things - loT) 167 usw.) als das Cloud-Datenzentrum 130. Rechen-, Speicher- und Speicherungsressourcen, die an den Edges in der Edge-Cloud 110 angeboten werden, sind für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die von den Endpunktdatenquellen 160 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 110 zu dem Cloud-Datenzentrum 130 kritisch, wodurch Energieverbrauch und Gesamtnetzwerknutzungen unter anderen Vorteilen verbessert werden.
Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit von dem Edge-Ort ab (wenn zum Beispiel weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen als an einer Basisstation als an einer Zentrale verfügbar sind). Je näher sich der Edge-Ort jedoch an dem Endpunkt (zum Beispiel UEs) befindet, desto mehr sind dieser Raum und diese Leistung häufig eingeschränkt. Somit versucht Edge-Computing, die Menge an Ressourcen, die für Netzwerkdienste benötigt wird, durch die Verteilung von mehr Ressourcen, die sich sowohl geografisch als auch in der Netzwerkzugriffszeit näher liegen, zu reduzieren. Auf diese Weise versucht Edge-Computing, die Rechenressourcen wo immer es zweckdienlich ist, zu den Workload-Daten zu bringen oder die Workload-Daten zu den Rechenressourcen zu bringen.
Im Folgenden sind Aspekte einer Edge-Cloud-Architektur beschrieben, die mehrere potenzielle Einsätze abdeckt und Einschränkungen behebt, die einige Netzbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese beinhalten Variation von Konfigurationen basierend auf dem Edge-Ort (weil Edges auf einer Basisstationsebene zum Beispiel stärker eingeschränkte Leistungsfähigkeit und Fähigkeiten in einem Multi-Mandanten-Szenario aufweisen können); Konfigurationen basierend auf der Art des Rechnens, des Speichers, der Speicherung, Fabric-, Beschleunigungs- oder ähnlichen Ressourcen, die an Edge-Orten, Ebenen von Orten oder Gruppen von Orten zur Verfügung stehen; Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und verwandte Zielsetzungen zum Erreichen der Nutzbarkeit und Leistungsfähigkeit von Enddiensten. Diese Einsätze können eine Verarbeitung in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Timing-Charakteristiken als „Nah-Edge“-, „Nähe-Edge“-, „Lokal-Edge“-, „Mittel-Edge“- oder „Fern-Edge“-Schichten betrachtet werden können.
Edge-Computing ist ein sich entwickelndes Paradigma, bei dem das Rechnen an oder näher an dem „Edge“ eines Netzwerks ausgeführt wird, typischerweise durch die Verwendung einer Rechenplattform (zum Beispiel x86- oder ARM-Rechenhardwarearchitektur), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen umgesetzt ist, die sich viel näher an Endpunktvorrichtungen, die Daten erzeugen und verbrauchen, befinden. Edge-Gateway-Server können zum Beispiel mit Pools von Speicher- und Speicherungsressourcen ausgestattet sein, um Rechnen in Echtzeit für Verwendungsfälle mit niedriger Latenz (zum Beispiel autonomes Fahren oder Videobeaufsichtigung) für verbundene Client-Vorrichtungen auszuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienst-Workloads für verbundene Nutzergeräte direkt zu verarbeiten, ohne weitere Daten über Backhaul-Netzwerke zu kommunizieren. Oder als ein anderes Beispiel kann Zentralstellen-Netzwerkverwaltungshardware durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen ausführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Vorrichtungen anbietet. Innerhalb von Edge-Computing-Netzwerken kann es in Diensten Szenarien geben, in denen die Rechenressource zu den Daten „bewegt“ wird, sowie Szenarien, in denen die Daten zu der Rechenressource „bewegt“ werden. Oder als ein Beispiel können Basisstations-Rechen-, Beschleunigungs- und Netzwerkressourcen Dienste bereitstellen, um die Workload-Anforderungen nach Bedarf durch Aktivieren ruhender Kapazität (Subskription, Capacity on Demand) zu skalieren, um Grenzfälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren umgesetzten Lebenszyklus bereitzustellen.
2 bildet Betriebsschichten unter Endpunkten, eine Edge-Cloud und Cloud-Rechenumgebungen ab. Insbesondere bildet 2 Beispiele für Rechennutzungsfälle 205 ab, die die Edge-Cloud 110 unter mehreren veranschaulichenden Schichten des Netzwerk-Computing nutzen. Die Schichten beginnen bei einer Endpunktschicht (Vorrichtungen- und Dinge-Schicht), die auf die Edge-Cloud 110 zugreift, um Dateneranlegungs-, Analyse- und Datenverbrauchsaktivitäten auszuführen. Die Edge-Cloud 110 kann mehrere Netzwerkschichten überspannen, wie etwa eine Edge-Geräte-Schicht 210, Gateways, Vor-Ort-Server oder Netzwerkgeräte (Knoten 215), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 220, einschließlich Basisstationen, Funkverarbeitungseinheiten, Netzwerk-Hubs, regionaler Datenzentren oder lokalem Netzwerkgerät (Gerät 225); und beliebige Geräte, Vorrichtungen oder Knoten, die dazwischen liegen (in Schicht 212, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 110 und zwischen den verschiedenen Schichten können über eine beliebige Anzahl verdrahteter oder drahtloser Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht abgebildet sind.
Beispiele für Latenz, die aus Netzwerkkommunikationsdistanz- und Verarbeitungszeitauflagen resultieren, können von weniger als einer Millisekunde (ms), wenn unter der Endpunktschicht 200, unter 5 ms an der Edge-Geräte-Schicht 210, bis sogar zwischen 10 und 40 ms, wenn mit Knoten an der Netzwerkzugangsschicht 220 kommuniziert wird, reichen. Jenseits der Edge-Cloud 110 befinden sich Schichten des Kernnetzwerks 230 und des Cloud-Datenzentrums 240, jeweils mit zunehmender Latenz (zum Beispiel zwischen 50 und 60 ms an der Kernnetzwerkschicht 230 bis 100 oder mehr ms an der Cloud-Datenzentrumsschicht. Infolgedessen werden Operationen in einem Kernnetzwerk-Datenzentrum 235 oder einem Cloud-Datenzentrum 245 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Verwendungsfälle 205 zu realisieren. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Kontrastzwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und -technologien die Latenzen weiter reduzieren kann. Bei einigen Beispielen können jeweilige Teile des Netzwerks in Bezug auf eine Netzwerkquelle und einen Netzwerkzielort als Schichten „nahe Edge“, „lokale Edge“, „Nähe-Edge“, „mittlere Edge“ oder „ferne Edge“ kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetzwerk-Datenzentrums 235 oder eines Cloud-Datenzentrums 245 ein Zentralstellen- oder Inhaltsdatennetzwerk als innerhalb einer „Nähe Edge“-Schicht ( „Nähe“ zu der Cloud, mit hohen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Nutzungsfälle 205 kommuniziert wird) befindlich betrachtet werden, wohingegen ein Zugangspunkt, eine Basisstation, ein Vor-Ort-Server oder ein Netzwerk-Gateway als innerhalb einer „fernen Edge“ -Schicht („fern“ von der Cloud, mit niedrigen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Nutzungsfälle 205 kommuniziert wird) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer besonderen Netzwerkschicht als eine „nahe“, „lokale“, „Nähe“, „mittlere“ oder „ferne“ Edge bildend auf Latenz, Distanz, Anzahl von Netzwerksprüngen oder anderen messbaren Merkmalen basieren können, wie sie von einer Quelle in einer beliebigen der Netzwerkschichten 200 bis 240 gemessen werden.
Die diversen Nutzungsfälle 205 können aufgrund mehrerer Dienste, die Edge-Cloud nutzen, unter Nutzungsdruck auf Ressourcen eingehender Ströme zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 110 ausgeführt werden, variierende Anforderungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (Quality of Service - QoS) (zum Beispiel kann Verkehr für ein autonomes Auto eine höhere Priorität als ein Temperatursensor hinsichtlich der Antwortzeitanforderung aufweisen; oder kann eine Leistungsfähigkeitsempfindlichkeit/ein Engpass an einer Rechen-/Beschleuniger-, Speicher-, Speicherungs- oder Netzwerkressource in Abhängigkeit von der Anwendung existieren); (b) Zuverlässigkeit und Ausfallsicherheit (zum Beispiel müssen einige Eingangsströme bearbeitet und der Verkehr mit missionskritischer Zuverlässigkeit geleitet werden, wobei einige anderen Eingangsströme je nach Anwendung einen gelegentlichen Ausfall tolerieren können); und (c) physikalische Beschränkungen (zum Beispiel Leistung, Kühlung und Formfaktor).
Die End-zu-End-Dienstansicht für diese Nutzungsfälle beinhaltet das Konzept eines Dienstflusses und ist mit einer Transaktion assoziiert. Die Transaktion gibt die Gesamtdienstanforderung für die Entität an, die den Dienst verbraucht, sowie die zugehörigen Dienste für die Ressourcen, Workloads, Arbeitsabläufe und Geschäftsfunktions- und Geschäftsniveauanforderungen. Die Dienste, die mit den beschriebenen „Klauseln“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, die sicherstellt, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt werden. Wenn ein Bauelement in der Transaktion seine vereinbarte SLA verfehlt, kann das System als Ganzes (Bauelement in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung des SLA-Verstoßes zu verstehen und (2) andere Bauelemente in dem System zur Wiederaufnahme der gesamten Transaktions-SLA erweitern und (3) Schritte zur Behebung umsetzen.
Somit kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge-Computing innerhalb der Edge-Cloud 110 die Fähigkeit bereitstellen, mehrere Anwendungen der Verwendungsfälle 205 (zum Beispiel Objektverfolgung, Videobeaufsichtigung, vernetzte Autos usw.) in Echtzeit oder nahezu Echtzeit zu bedienen und auf diese zu reagieren und Anforderungen an ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganze neue Klasse von Anwendungen (virtuelle Netzwerkfunktionen - Virtual Network Functions - ), FaaS (Function as a Service), Edge as a Service (EaaS), Standardprozesse usw.), die ein herkömmliches Cloud-Computing aufgrund von Latenz oder anderer Einschränkungen nicht nutzen können.
Die Vorteile des Edge-Computing sind jedoch mit den folgenden Vorbehalten behaftet. Die an dem Edge befindlichen Vorrichtungen sind häufig hinsichtlich der Ressource eingeschränkt, und daher unterliegt die Nutzung von Edge-Ressourcen höherem Druck. Typischerweise wird dem durch Pooling von Speicher- und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen begegnet. Das Edge kann hinsichtlich der Leistung und Kühlung eingeschränkt sein, so dass die Leistungsnutzung von den Anwendungen, die die meiste Leistung verbrauchen, belegt werden muss. Es kann inhärente Leistungsfähigkeitskompromisse in diesen gepoolten Speicherressourcen geben, da viele von ihnen wahrscheinlich neu entstehende Speichertechnologien verwenden, bei welchen mehr Leistung größere Speicherbandbreite erfordert. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdige Vertrauensankerfunktionen auch erforderlich, weil Edge-Orte unbemannt sein können und sogar zugelassenen Zugriff benötigen können (wenn sie zum Beispiel an einem Drittparteistandort untergebracht sind). Derartige Probleme werden in der Edge-Cloud 110 in einem Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriffsgefüge markanter, in dem Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Stakeholder, Verwendungsfälle und Dienste ändert.
Auf einem allgemeineren Niveau kann ein Edge-Computing-System derart beschrieben werden, dass es eine beliebige Anzahl von Einsätzen an den oben besprochenen Schichten umfasst, die in der Edge-Cloud 110 arbeiten (Netzwerkschichten 200 bis 240), die Koordination von Client- und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kerndatenzentren können über Schichten des Netzwerks verteilt sein, um eine Umsetzung des Edge-Datenverarbeitungssystems von oder im Auftrag eines Telekommunikationsdienstanbieters („telco“ oder „TSP"), Internet-der-Dinge-Dienstanbieter, Cloud-Dienstanbieter (CSP), Unternehmensentität oder eine beliebige andere Anzahl von Entitäten bereitzustellen. Verschiedene Umsetzungen und Konfigurationen des Edge-Computing-Systems können dynamisch bereitgestellt werden, wie etwa, wenn orchestriert, um Dienstzielsetzungen zu erfüllen.
Im Einklang mit den hierin bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktbauelement, -vorrichtung, -anwendung oder anderem Ding dazu in der Lage sein, als ein Erzeuger oder Verbraucher von Daten zu kommunizieren. Weiter bedeutet die Bezeichnung „Knoten“ oder „Gerät“, wie es in dem Edge-Computing-System verwendet wird, nicht notwendigerweise, dass ein derartiger Knoten oder diese Vorrichtung in einer Client- oder Agent-/Minion-/Folger-Rolle arbeitet; vielmehr können die Knoten oder Vorrichtungen in dem Edge-Computing-System auf einzelne Entitäten, Knoten oder Subsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Verwendung der Edge-Cloud 110 zu erleichtern oder zu verwenden, verweisen.
Daher ist die Edge-Cloud 110 aus Netzwerkbauelementen und funktionalen Merkmalen gebildet, die von und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Computing-Knoten unter den Netzwerkschichten 210 bis 230 betrieben werden. Die Edge-Cloud 110 kann somit als eine beliebige Art von Netzwerk verkörpert sein, das Edge-Computing- und/oder Speicherungsressourcen bereitstellt, die sich in der Nähe von Funkzugangsnetzwerk-fähigen (Radio Access Network - RAN-fähigen Endpunktvorrichtungen (zum Beispiel Mobilcomputervorrichtungen, loT-Vorrichtungen, Smart-Vorrichtungen usw.) befinden, die hier besprochen werden. Mit anderen Worten kann man sich die Edge-Cloud 110 als ein „Edge“ vorstellen, das die Endpunktvorrichtungen und traditionelle Netzwerkzugangspunkte verbindet, das als ein Eintrittspunkt in Dienstanbieter-Kernnetzwerke, einschließlich Mobilträgernetzwerken (zum Beispiel Global System for Mobile Communications-Netzwerke (GSM-Netzwerken, Long-Term Evolution-Netzwerken (LTE-Netzwerken), 5G/6G-Netzwerken usw.) dient, während auch Speicherungs- und/oder Rechenfähigkeiten bereitgestellt werden. Andere Arten und Formen von Netzwerkzugang (zum Beispiel WiFi, Long-Range-Wireless, verdrahtete Netzwerke, einschließlich optischer Netzwerke) können auch an Stelle von oder in Kombination mit derartigen 3GPP-Trägernetzwerken genutzt werden.
Die Netzwerk-Bauelemente der Edge-Cloud 110 können Server, Multi-Mandanten-Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Rechenvorrichtungen sein. Zum Beispiel kann die Edge-Cloud 110 eine Geräterechenvorrichtung beinhalten, die eine eigenständige elektronische Vorrichtung einschließlich eines Gehäuses, eines Chassis, eines Einschlusses oder einer Schale ist. Unter einigen Umständen kann das Gehäuse für Portabilität derart dimensioniert sein, dass es von einem Menschen getragen und/oder versandt werden kann. Beispielhafte Gehäuse können Materialien beinhalten, die eine oder mehrere Außenoberflächen bilden, die Inhalte des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz bei gefährlicher Umgebung (zum Beispiel EMI, Vibration, extreme Temperaturen) beinhalten kann und/oder Eintauchbarkeit ermöglichen kann. Beispielhafte Gehäuse können Leistungsschaltungen beinhalten, um Leistung für stationäre und/oder portable Umsetzungen bereitzustellen, wie etwa AC-Leistungseingänge, DC-Leistungseingänge, AC/DC- oder DC/AC-Wandler(n), Leistungsregler, Transformatoren, Ladeschaltungen, Batterien, verdrahtete Eingänge und/oder drahtlose Leistungseingänge. Beispielhafte Gehäuse und/oder ihre Oberflächen können Montagehardware beinhalten oder mit dieser verbunden sein, um eine Befestigung an Strukturen, wie etwa Gebäuden, Telekommunikationsstrukturen (zum Beispiel Masten, Antennenstrukturen usw.) und/oder Racks (zum Beispiel Server-Racks, Blade-Halterungen usw.), zu ermöglichen. Beispielhafte Gehäuse und/oder ihre Oberflächen können einen oder mehrere Sensoren (zum Beispiel Temperatursensoren, Vibrationssensoren, Lichtsensoren, akustische Sensoren, kapazitive Sensoren, Näherungssensoren usw.) stützen. Ein oder mehrere derartige Sensoren können in der Oberfläche enthalten, von dieser getragen oder anderswie eingebettet und/oder an der Oberfläche des Geräts montiert sein. Beispielhafte Gehäuse und/oder ihre Oberflächen können mechanische Konnektivität unterstützen, wie etwa Antriebshardware (zum Beispiel Räder, Propeller usw.) und/oder Anlenkhardware (zum Beispiel Roboterarme, schwenkbare Fortsätze usw.). Unter einigen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen beinhalten, wie etwa Benutzerschnittstellenhardware (zum Beispiel Tasten, Schalter, Wählscheiben, Schieber usw.). Unter einigen Umständen beinhalten beispielhafte Gehäuse Ausgabevorrichtungen, die darin getragen, eingebettet und/oder daran angebracht sind. Ausgabevorrichtungen können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Ports (zum Beispiel USB) usw. beinhalten. Unter einigen Umständen sind Edge-Vorrichtungen Vorrichtungen, die in dem Netzwerk für einen spezifischen Zweck (zum Beispiel eine Verkehrsampel) präsentiert werden, können aber Verarbeitungs- und/oder andere Kapazitäten, die für andere Zwecke genutzt werden können, aufweisen. Derartige Edge-Vorrichtungen können von anderen vernetzten Vorrichtungen unabhängig sein und können mit einem Gehäuse versehen sein, das einen Formfaktor aufweist, der für seinen Hauptzweck geeignet ist; aber dennoch für andere Rechenaufgaben, die seine Hauptaufgabe nicht stören, verfügbar ist. Edge-Vorrichtungen beinhalten Internet-der-Dinge-Vorrichtungen. Die Geräterechenvorrichtung kann Hardware- und Softwarebauelemente beinhalten, um lokale Probleme, wie etwa Vorrichtungstemperatur, Vibration, Ressourcennutzung, Aktualisierungen, Stromprobleme, physische und Netzwerksicherheit usw., zu verwalten. Beispielhafte Hardware zum Umsetzen einer Geräterechenvorrichtung ist in Verbindung mit 7B beschrieben. Die Edge-Cloud 110 kann auch einen oder mehrere Server und/oder einen oder mehrere Server mit mehreren Mandanten beinhalten. Ein derartiger Server kann ein Betriebssystem und eine virtuelle Computing-Umgebung beinhalten. Eine virtuelle Computing-Umgebung kann einen Hypervisor beinhalten, der (Spawning, Einsetzen, Zerstören usw.) eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet. Derartige virtuelle Computing-Umgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, Code oder Scripts laufen können, während sie von einer oder mehreren anderen Anwendungen, Software, Code oder Scripts isoliert sind.
3 veranschaulicht ein Blockdiagramm einer beispielhaften Umgebung 300, in der verschiedene Client-Endpunkte 310 (in der Form von Mobilgeräten, Computern, autonomen Fahrzeugen, Geschäftsrechenanlagen, industriellen Verarbeitungsgeräten) Anforderungen und Antworten mit der beispielhaften Edge-Cloud 110 austauschen. Beispielsweise können Computer, Geschäftsrechengeräte und Industrieverarbeitungsgeräte Netzwerkzugang über ein verdrahtetes Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 322 durch ein Vor-Ort-Netzwerksystem 332 ausgetauscht werden. Mobile Rechenvorrichtungen können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem sie Anfragen und Antworten 324 durch einen zellularen Netzwerkturm 334 austauschen. Autonome Fahrzeuge können Netzwerkzugang für Anfragen und Antworten 326 über ein drahtloses Fahrzeugnetzwerk durch ein Straßennetzwerksystem 336 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 342, 344 innerhalb der Edge-Cloud 110 einsetzen, um Verkehr und Anfragen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 110 verschiedene Rechen- und Speicherressourcen, wie etwa an Edge-Aggregationsknoten 340, einsetzen, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 340 und andere Systeme der Edge-Cloud 110 sind mit einer Cloud oder einem Datenzentrum 360 verbunden, die/das ein Backhaul-Netzwerk 350 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Datenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. (Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 340 und der Aggregationspunkte 342, 344, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt sind, können auch innerhalb der Edge-Cloud 110 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein).
4 veranschaulicht Einsatz und Orchestrierung für virtuelle Edge-Konfigurationen über ein Edge-Computing-System, das unter mehreren Edge-Knoten und Multi-Mandanten betrieben wird. Insbesondere stellt 4 eine Koordination eines ersten Edge-Knotens 422 und eines zweiten Edge-Knotens 424 in einem Edge-Computing-System 400 dar, um Anforderungen und Antworten für verschiedene Client-Endpunkte 410 (zum Beispiel Smart Cities / Gebäudesysteme, Mobilvorrichtungen, Rechenvorrichtungen, Geschäfts-/Logistiksysteme, Industriesysteme usw.), die auf verschiedene virtuelle Edge-Instanzen zugreifen, zu erfüllen. Hier stellen die virtuellen Edge-Instanzen Edge-Computingsfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugriff auf ein Cloud/Datenzentrum 440 für Anfragen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch eine Koordination der Verarbeitung unter mehreren Edge-Knoten für mehrere Mandanten oder Entitäten.
In dem Beispiel der 4 beinhalten diese virtuellen Edge-Instanzen: ein erstes virtuelles Edge 432, das einem ersten Mandant (Mandant 1) angeboten wird, das eine erste Kombination von Edge-Speicherung, Rechnen und Diensten anbietet; und ein zweites virtuelles Edge 434, das eine zweite Kombination von Edge-Speicherung, Rechnen und Diensten anbietet. Die virtuellen Edge-Instanzen 432, 434 sind unter den Edge-Knoten 422, 424 verteilt und können Szenarien beinhalten, in denen eine Anforderung und Antwort von demselben oder unterschiedlichen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 422, 424 zum Arbeiten auf eine verteilte aber koordinierte Weise findet basierend auf Edge-Bereitstellungsfunktionen 450 statt. Die Funktionalität der Edge-Knoten 422, 424 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten findet basierend auf Orchestrierungsfunktionen 460 statt.
Es versteht sich, dass einige der Vorrichtungen 410 Multi-Mandanten-Vorrichtungen sind, wobei Mandant 1 innerhalb eines Mandant 1 „Slice“ funktionieren kann, während ein Mandant 2 innerhalb eines Mandanten 2 „Slice“ funktionieren kann (und bei weiteren Beispielen können zusätzliche oder Unter-Mandanten existieren; und jeder Mandant kann sogar spezifisch berechtigt und transaktional an einen spezifischen Satz von Merkmalen bis hin zu spezifischen Hardwaremerkmalen gebunden sein). Eine vertrauenswürdige Multi-Mandanten-Vorrichtung kann weiter einen Mandantenspezifischen kryptografischen Schlüssel derart enthalten, dass die Kombination aus Schlüssel und Slice als ein „RoT-Anker“ (Root of Trust - RoT) oder Mandanten-spezifischer RoT angesehen werden kann. Ein RoT kann weiter dynamisch unter Verwenden einer DICE-Architektur (Device Identity Composition Engine) berechnet werden, so dass ein einzelner DICE-Hardwarebaustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zum Schichten von Vorrichtungsfähigkeiten (wie etwa ein feldprogrammierbares Gate-Array (FPGA)) zu konstruieren. Der RoT kann weiter für einen vertrauenswürdigen Rechenkontext verwendet werden, um ein „Fan-Out“ zu ermöglichen, das zum Unterstützen von Multi-Mandanten-Fähigkeit nützlich ist. Innerhalb einer Multi-Mandanten-Umgebung können die jeweiligen Edge-Knoten 422, 424 als Sicherheitsmerkmaldurchsetzungspunkte für lokale Ressourcen arbeiten, die mehreren Mandanten pro Knoten zugeordnet sind. Zusätzlich können Mandanten-Laufzeit- und - anwendungsausführung (zum Beispiel in den Fällen 432, 434) als ein Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen anlegt, die potenziell mehrere physische Hosting-Plattformen überspannen. Schließlich können die Orchestrierungsfunktionen 460 an einer Orchestrierungsentität als ein Sicherheitsmerkmaldurchsetzungspunkt zum Ordnen von Ressourcen entlang Mandanten-Grenzen arbeiten.
Edge-Computing-Knoten können Ressourcen (Speicher, CPU, GPU, Interruptsteuervorrichtung, E/A-Steuervorrichtung, Speichersteuervorrichtung, Bussteuervorrichtung usw.) partitionieren, wobei jeweilige Partitionen eine RoT-Fähigkeit enthalten können und wobei Fan-Out und Layering gemäß einem DICE-Modell weiter auf Edge-Knoten angewandt werden können. Cloud-Rechenknoten, die aus Containern, FaaS-Engines, Servlets, Servern oder einer anderen Berechnungsabstraktion bestehen, können gemäß einer DICE-Layering- und-Fan-Out-Struktur partitioniert werden, um jeweils einen RoT-Kontext zu unterstützen. Dementsprechend können die jeweiligen Vorrichtungen 410, 422 und 440, die RoTs überspannen, die Einrichtung einer verteilten vertrauenswürdigen Rechenbasis (DTCB) derart koordinieren, dass ein Mandanten-spezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente Ende an Ende verknüpft, eingerichtet werden kann.
Weiter versteht es sich, dass ein Container daten- oder workload-spezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorherigen Edge-Knoten schützen. Als Teil der Migration eines Containers kann eine Pod-Steuervorrichtung an einem Quell-Edge-Knoten einen Migrationsschlüssel von einer Ziel-Edge-Knoten-Pod-Steuervorrichtung erhalten, wobei der Migrationsschlüssel zum Umhüllen der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zu dem Ziel-Edge-Knoten migriert wird, wird der Entpackungsschlüssel der Pod-Steuervorrichtung, die dann die verpackten Schlüssel entschlüsselt, exponiert. Die Schlüssel können nun zur Ausführung von Operationen an Container-spezifischen Daten verwendet werden. Die Migrationsfunktionen können durch korrekt attestierte Edge-Knoten und Pod-Manager (wie oben beschrieben) Gate-gesteuert werden.
Bei weiteren Beispielen wird ein Edge-Computing-System erweitert, um Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer eigenständigen, einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Multi-Eigentümer-, Multi-Mandanten-Umgebung bereitzustellen. Ein Multi-Mandanten-Orchestrator kann verwendet werden, um Schlüsselverwaltung, Vertrauensanker-Verwaltung und andere Sicherheitsfunktionen im Zusammenhang mit der Bereitstellung und dem Lebenszyklus des vertrauenswürdigen „Slice-" Konzepts in 4 auszuführen. Beispielsweise kann ein Edge-Computing-System dazu konfiguriert sein, Anfragen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Datenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (zum Beispiel Augmented Reality (AR)/Virtual Reality (VR), Unternehmensanwendungen, Inhaltslieferung, Gaming, Rechen-Offload) gleichzeitig unterstützen. Weiter kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (zum Beispiel normale Anwendungen; latenzempfindliche Anwendungen; latenzkritische Anwendungen; Benutzerebenenanwendungen; Networking-Anwendungen usw.). Die virtuellen Edge-Instanzen können auch Systeme mehrerer Eigentümer an unterschiedlichen geografischen Orten (oder jeweiligen Computersystemen und Ressourcen, die mehrere Eigentümer gemeinsam besitzen oder gemeinsam verwalten) überspannen.
Beispielsweise kann jeder der Edge-Knoten 422, 424 die Verwendung von Containern umsetzen, wie etwa unter Verwenden eines Containers „Pod“ 426, 428, der eine Gruppe aus einem oder mehreren Containern bereitstellt. In einem Gefüge, das eine oder mehrere Container-Pods verwendet, ist eine Pod-Steuervorrichtung oder ein Orchestrator für die lokale Steuerung und Orchestrierung der Container in dem Pod verantwortlich. Verschiedene Edge-Knotenressourcen (zum Beispiel Speicherung, Rechnen, Dienste, abgebildet mit Sechsecken), die für die jeweiligen Edge-Slices 432, 434 bereitgestellt werden, werden gemäß den Erfordernissen jedes Containers partitioniert.
Bei der Verwendung von Container-Pods überwacht eine Pod-Steuervorrichtung die Partitionierung und Zuordnung von Containern und Ressourcen. Die Pod-Steuervorrichtung empfängt Anweisungen von einem Orchestrator (zum Beispiel dem Orchestrator 460), die die Steuervorrichtung darüber anweisen, wie physische Ressourcen am besten zu partitionieren sind und für welche Dauer, wie etwa durch Empfangen von KPI-Zielen (Key Performance Indicator-Zielen) basierend auf SLA-Verträgen. Die Pod-Steuervorrichtung bestimmt, welcher Container welche Ressourcen und wie lange benötigt, um die Workload zu vervollständigen und die SLA zu erfüllen. Die Pod-Steuervorrichtung verwaltet auch Containerlebenszyklusvorgänge, wie etwa: Anlegen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die gemeinsam auf einer verteilten Anwendung arbeiten, Abbauen von Containern, wenn die Workload beendet ist, und dergleichen. Zusätzlich kann eine Pod-Steuervorrichtung als eine Sicherheitsrolle dienen, die eine Zuweisung von Ressourcen verhindert, bis sich der richtige Mandant authentifiziert oder eine Bereitstellung von Daten oder einer Workload zu einem Container verhindert, bis ein Attestierungsresultat erfüllt ist.
Auch bei der Verwendung von Container-Pods können Mandanten-Grenzen immer noch existieren, aber in dem Kontext jedes Pods von Containern. Falls jeder Mandanten-spezifische Pod eine Mandanten-spezifische Pod-Steuervorrichtung aufweist, gibt es eine gemeinsam genutzte Pod-Steuervorrichtung, die Ressourcenzuordnungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um eine Attestierung und Vertrauenswürdigkeit des Pods und der Pod-Steuervorrichtung sicherzustellen. Beispielsweise kann der Orchestrator 460 lokalen Pod-Steuervorrichtungen, die eine Attestierungs-Prüfrichtlinie ausführen, eine Attestierungs-Prüfung bereitstellen. Falls eine Attestierung eine Richtlinie für eine erste Mandanten-Pod-Steuervorrichtung aber nicht eine zweite Mandanten-Pod-Steuervorrichtung erfüllt, dann könnte der zweite Pod zu einem anderen Edge-Knoten migriert werden, der sie erfüllt. Alternativ dazu kann es dem ersten Pod erlaubt werden, ausgeführt zu werden, und eine unterschiedliche gemeinsam genutzte Pod-Steuervorrichtung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
5 veranschaulicht zusätzliche Rechenanordnungen, die Container in einem Edge-Computing-System einsetzen. Als ein vereinfachtes Beispiel bilden die Systemanordnungen 510, 520 Gefüge ab, bei denen eine Pod-Steuervorrichtung (zum Beispiel der Container-Manager 511, 521 und ein Containerorchestrator 531) dazu ausgelegt ist,containerisierte Pods, Funktionen, und Funktions-als-ein-Service-Instanzen durch Ausführung über Rechenknoten (515 in Anordnung 510) oder separat containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten (523 in Anordnung 520) auszuführen. Diese Anordnung ist zur Verwendung mehrerer Mandanten in einer beispielhaften Systemanordnung 530 (unter Verwenden von Rechenknoten 537) angepasst, wobei containerisierte Pods (zum Beispiel Pods 512), Funktionen (zum Beispiel Funktionen 513, VNFs 522, 536), und Funktions-als-ein-Service-Instanzen (zum Beispiel FaaS-Instanz 515) innerhalb virtueller Maschinen (zum Beispiel VMs 534, 535 für Mandanten 532, 533) spezifisch für jeweilige Mandanten (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen) gestartet werden. Diese Anordnung ist weiter zur Verwendung in der Systemanordnung 540 angepasst, die Container 542, 543 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf den Rechenknoten 544 wie von einem containerbasierten Orchestrierungssystem 541 koordiniert, bereitstellt.
Die in 5 abgebildeten Systemanordnungen stellen eine Architektur bereit, die VMs, Container und Funktionen gleichermaßen hinsichtlich der Anwendungszusammensetzung behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleuniger-Bauelemente (FPGA, ASIC) als ein lokales Backend beinhalten. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer, die von einem Orchestrator koordiniert werden, aufgeteilt werden.
Im Kontext der 5 können die Pod-Steuervorrichtung/Container-Manager, der Containerorchestrator und die einzelnen Knoten einen Sicherheitsdurchsetzungspunkt bereitstellen. Die Mandanten-Isolierung kann jedoch orchestriert werden, wobei die Ressourcen, die einem Mandanten zugeordnet sind, von Ressourcen getrennt sind, die einem zweiten Mandanten zugeordnet sind, aber Edge-Eigentümer kooperieren, um sicherzustellen, dass Ressourcenzuordnungen nicht über Mandanten-Grenzen hinweg gemeinsam genutzt werden. Oder Ressourcenzuordnungen könnten über Mandanten-Grenzen hinweg isoliert werden, da Mandanten eine „Verwendung“ über eine Subskriptions- oder Transaktions-/Vertragsbasis erlauben könnten. In diesen Kontexten können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardware-Partitionierungssysteme von Edge-Eigentümern verwendet werden, um die Mandanten durchzusetzen. Andere Isolationsumgebungen können beinhalten: blanke Metall - Ausrüstung(dedizierte Ausrüstung), virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon.
Bei weiteren Beispielen können Aspekte von softwaredefinierter oder gesteuerter Siliziumhardware und anderer konfigurierbarer Hardware mit den Anwendungen, Funktionen und Diensten eines Edge-Computing-Systems integrieren. Softwaredefiniertes Silizium kann verwendet werden, um für einige Ressourcen- oder Hardwarebestandteile sicherzustellen, dass ein Vertrag oder eine Dienstleistungsvereinbarung, basierend auf der Fähigkeit des Bestandteils erfüllt wird, einen Teil von sich selbst oder die Workload nach zu besseren (zum Beispiel durch ein Upgrade, eine Umkonfiguration oder eine Bereitstellung neuer Merkmale innerhalb der Hardwarekonfiguration selbst).
Es versteht sich, dass die hierin besprochenen Edge-Computing-Systeme und -Anordnungen bei verschiedenen Lösungen, Diensten und/oder Verwendungsfällen, die Mobilität involvieren, anwendbar sein können. Als ein Beispiel zeigt 6 einen beispielhaften vereinfachten Fahrzeugberechnungs- und Kommunikationsnutzungsfall, der Mobilzugriff auf Anwendungen in einem beispielhaften Edge-Computing-System 600 involviert, das eine Edge-Cloud, wie etwa die Edge-Cloud 110 der 1, umsetzt. In diesem Verwendungsfall können die jeweiligen Client-Rechenknoten 610 als fahrzeuginterne Computing-Systeme (zum Beispiel fahrzeuginterne Navigations- und/oder Infotainment-Systeme) umgesetzt sein, die sich in entsprechenden Fahrzeugen befinden, die mit den beispielhaften Edge-Gateway-Knoten 620 während des Befahrens einer Straße kommunizieren. Beispielsweise können sich die Edge-Gateway-Knoten 620 in einem Schrank am Straßenrand oder einem anderen Gehäuse befinden, der (das) in eine Struktur eingebaut ist, die eine andere, separate, mechanisches Anlage aufweist, die entlang der Straße, an Kreuzungen der Straße oder anderen Orten nahe der Straße platziert werden kann. Während jeweilige Fahrzeuge entlang der Straße fahren, kann sich die Verbindung zwischen ihrem Client-Rechenknoten 610 und einem speziellen der Edge-Gateway-Knoten 620 propagieren, um eine konsistente Verbindung und einen konsistenten Kontext für den beispielhaften Client-Rechenknoten 610 aufrechtzuerhalten. Gleichermaßen können mobile Edge-Knoten an den Diensten mit hoher Priorität oder gemäß den Durchsatz- oder Latenzauflösungsanforderungen für den oder die zugrundeliegenden Dienste aggregieren (zum Beispiel im Fall von Drohnen). Die jeweiligen Edge-Gateway-Vorrichtungen 620 beinhalten eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, und daher können Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 610 auf einem oder mehreren der Edge-Gateway-Knoten 620 ausgeführt werden.
Die Edge-Gateway-Knoten 620 können mit einem oder mehreren Edge-Ressourcenknoten 640 kommunizieren, die veranschaulichend als Computing-Systemserver, -geräte oder -bauelemente, die sich an oder in einer Kommunikationsbasisstation 642 (zum Beispiel einer Basisstation eines zellularen Netzwerks) befinden, umgesetzt sind. Wie oben besprochen, beinhalten der der (die) jeweilige(n) Edge-Ressourcenknoten 640 eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, so dass einige Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 610 an dem oder den Edge-Ressourcenknoten 640 ausgeführt werden können. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, von dem (den) Edge-Ressourcenknoten 640 ausgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, von den Edge-Gateway-Vorrichtungen 620 ausgeführt werden (zum Beispiel in Abhängigkeit von den Fähigkeiten jedes Bauelements oder von Informationen in der Anforderung, die Dringlichkeit oder Wichtigkeit angeben). Basierend auf Datenzugriff, Datenort oder Latenz kann die Arbeit auf Edge-Ressourcenknoten fortgesetzt werden, wenn sich die Verarbeitungsprioritäten während der Verarbeitungsaktivität ändern. Gleichermaßen können konfigurierbare Systeme oder Hardwareressourcen selbst aktiviert werden (zum Beispiel von einem lokalen Orchestrator), um zusätzliche Ressourcen bereitzustellen, um den neuen Bedarf zu erfüllen (zum Beispiel Anpassen der Rechenressourcen an die Workload-Daten).
Der (die) Edge-Ressourcenknoten 640 kommunizieren auch mit dem Kerndatenzentrum 650, das Computing-Systemserver, Geräte und/oder andere Bauelemente, die sich an einem zentralen Ort (zum Beispiel einer Zentrale eines zellularen Kommunikationsnetzwerks) befinden, beinhalten kann. Das beispielhafte Kerndatenzentrum 650 stellt ein Gateway zu der globalen Netzwerk-Cloud 660 (zum Beispiel dem Internet) für die Operationen der Edge-Cloud 110 bereit, die von dem (den) Edge-Ressourcenknoten 640 und den Edge-Gateway-Vorrichtungen 620 gebildet werden. Zusätzlich kann das Kerndatenzentrum 650 bei einigen Beispielen eine Menge an Verarbeitungs- und Speicherungsfähigkeiten beinhalten, und somit kann etwas Verarbeitung und/oder Speicherung von Daten für die Client-Rechenvorrichtungen auf dem Kerndatenzentrum 650 ausgeführt werden (zum Beispiel Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität).
Die Edge-Gateway-Knoten 620 oder der (die) Edge-Ressourcenknoten 640 können die Verwendung zustandsorientierter Anwendungen 632 und einer geografischen verteilten Datenbank 634 anbieten. Obwohl die Anwendungen 632 und die Datenbank 634 als horizontal auf einer Schicht der Edge-Cloud verteilt veranschaulicht sind, versteht es sich, dass Ressourcen, Dienste, oder andere Bauelement der Anwendung vertikal in der gesamten Edge-Cloud verteilt sein können (einschließlich eines Teils der Anwendung, die an dem Client-Rechenknoten 610 ausgeführt wird, anderer Teile an den Edge-Gateway-Knoten 620 oder dem oder den Edge-Ressourcenknoten 640 usw.). Zusätzlich kann es, wie oben angegeben, Peer-Beziehungen auf einer beliebigen Ebene geben, um Dienstzielsetzungen und Verpflichtungen zu erfüllen. Weiter können sich die Daten für einen speziellen Client oder eine spezielle Anwendung basierend auf sich ändernden Bedingungen von Edge zu Edge bewegen (zum Beispiel basierend auf Beschleunigungsressourcenverfügbarkeit, Folgen der Autobewegung usw.). Beispielsweise kann basierend auf der „Abklingrate“ des Zugriffs eine Vorhersage gemacht werden, um den nächsten Eigentümer, der fortsetzen soll, zu identifizieren, oder wann die Daten oder der rechnerische Zugang nicht mehr sinnvoll sein werden. Dieser und andere Dienste können genutzt werden, um die Arbeit abzuschließen, die benötigt wird, um die Transaktion konform und verlustfrei zu halten.
In weiteren Szenarien kann ein Container 636 (oder ein Pod von Containern) flexibel von einem der Edge-Knoten 620 zu anderen Edge-Knoten (zum Beispiel einem anderen der Edge-Knoten 620, einem der Edge-Ressourcenknoten 640 usw.) migriert werden, so dass der Container mit einer Anwendung und Workload nicht rekonstituiert, rekompiliert, reinterpretiert werden muss, damit Migration funktioniert. Bei derartigen Gefügen werden jedoch eventuell einige Abhilfe oder „Swizzling“-Übersetzungsoperationen angewandt werden. Zum Beispiel kann sich die physische Hardware an dem (den) Edge-Ressourcenknoten 640 von der Hardware an dem (den) Edge-Ressourcenknoten 620 unterscheiden und daher wird die Hardware-Abstraktionsschicht (HAL), die das untere Edge des Containers bildet, erneut auf die physische Schicht des Ziel-Edge-Knotens abgebildet. Dies kann irgendeine Form einer Spätbindungstechnik beinhalten, wie etwa binäre Übersetzung der HAL von dem nativen Containerformat in das physische Hardwareformat, oder kann Abbildungsschnittstellen und Operationen involvieren. Eine Pod-Steuervorrichtung kann verwendet werden, um die Schnittstellenabbildung als Teil des Containerlebenszyklus anzusteuern, was Migration zu/von unterschiedlichen Hardwareumgebungen beinhaltet.
Die Szenarien, die in 6 enthalten sind, können verschiedene Arten von mobilen Edge-Knoten nutzen, wie etwa einen Edge-Knoten, der in einem Fahrzeug (PKW/Lastkraftwagen/Straßenbahn/Zug) gehostet ist, oder eine andere mobile Einheit, während sich der Edge-Knoten zu anderen geografischen Orten entlang der Plattform, die ihn hostet, bewegen wird. Bei Fahrzeug-zu-Fahrzeug-Kommunikationen können einzelne Fahrzeuge sogar als Netzwerk-Edge-Knoten für andere Autos fungieren (zum Beispiel um Caching, Reporting, Datenaggregation usw. auszuführen). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in statischen oder mobilen Gefügen verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an individuellen Endpunkteinrichtungen oder den Edge-Gateway-Knoten 620, einigen anderen an dem oder den Edge-Ressourcenknoten 640 und anderen in dem Kerndatenzentrum 650 oder der globalen Netzwerk-Cloud 660.
Bei weiteren Konfigurationen kann das Edge-Computing-System FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausführbarer Anwendungen und Funktionen umsetzen. Bei einem Beispiel schreibt ein Entwickler Funktionscode (hierin zum Beispiel „Computercode“), der eine oder mehrere Computerfunktionen repräsentiert, und der Funktionscode wird zu einer FaaS-Plattform hochgeladen, die zum Beispiel von einem Edge-Knoten oder einem Datenzentrum bereitgestellt wird. Ein Trigger, wie beispielsweise ein Service-Use-Fall oder ein Edge-Verarbeitungsereignis, initiiert die Ausführung des Funktionscodes mit der FaaS-Plattform.
Bei einem Beispiel für FaaS wird ein Container verwendet, um eine Umgebung bereitzustellen, in der Funktionscode (zum Beispiel eine Anwendung, die von einer Drittpartei bereitgestellt werden kann) ausgeführt wird. Der Container kann eine beliebige Entität mit isolierter Ausführung sein, wie etwa ein Prozess, ein Docker- oder Kubernetes-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Computing-Systems werden verschiedene Datenzentren-, Edge- und Endpunktvorrichtungen (einschließlich Mobilvorrichtungen) verwendet, um Funktionen „hochzudrehen“ (zum Beispiel Funktionsaktionen zu aktivieren und/oder zuzuordnen), die auf Anfrage skaliert werden. Der Funktionscode wird auf der physischen Infrastrukturvorrichtung (zum Beispiel dem Edge-Computing-Knoten) und darunterliegenden virtualisierten Containern ausgeführt. Schließlich wird der Container auf der Infrastruktur als Reaktion darauf, dass die Ausführung abgeschlossen ist, „heruntergedreht“ (zum Beispiel deaktiviert und/oder freigegeben).
Weitere Aspekte von FaaS können das Einsetzen von Edge-Funktionen auf eine Dienstart ermöglichen, die eine Unterstützung jeweiliger Funktionen beinhaltet, die Edge-Computing als einen Dienst unterstützen (Edge-as-a-Service oder „EaaS“). Zusätzliche Merkmale von FaaS können beinhalten: eine granulare Abrechnungskomponente, die es Kunden (zum Beispiel Computercodeentwickler) ermöglicht, nur zu bezahlen, wenn ihr Code ausgeführt wird; gemeinsame Datenspeicherung zum Speichern von Daten zur Wiederverwendung durch eine oder mehrere Funktionen; Orchestrierung und Verwaltung zwischen individuellen Funktionen; Funktionsausführungsveraltung, Parallelität und Konsolidierung; Verwaltung von Container- und Funktionsspeicherplätzen; Koordination von Beschleunigungsressourcen, die für Funktionen verfügbar sind; und Verteilung von Funktionen zwischen Containern (einschließlich „warmer“ Container, die bereits eingesetzt oder betrieben werden, versus „kalte“, die Initialisierung, Einsatz oder Konfiguration erfordern).
Das Edge-Computing-System 600 kann einen Edge-Bereitstellungsknoten 644 beinhalten oder mit diesem in Kommunikation stehen. Der Edge-Bereitstellungsknoten 644 kann Software, wie etwa die beispielhaften computerlesbaren Anweisungen 782 der 7B, zu verschiedenen Empfangsteilnehmern zum Umsetzen eines beliebigen der hierin beschriebenen Verfahren verteilen. Der beispielhafte Edge-Bereitstellungsknoten 644 kann von einem Computerserver, einen Heimserver, einem Inhaltsliefernetzwerk, einem virtuellen Server, einem Softwareverteilungssystem, einer zentralen Einrichtung, einer Speicherungsvorrichtung, einem Speicherungsknoten, einer Dateneinrichtung, Cloud-Dienst usw. umgesetzt werden, der in der Lage ist, Softwareanweisungen (zum Beispiel Code, Scripts, ausführbare Binär-Codes, Container, Pakete, komprimierte Dateien und/oder Ableitungen davon) zu speichern und/oder zu anderen Rechenvorrichtungen zu übertragen. Bauelemente des beispielhaften Edge-Bereitstellungsknotens 644 können sich in einer Cloud, in einem lokalen Netzwerk, in einem Edge-Netzwerk, in einem Weitverkehrsnetzwerk, im Internet und/oder an einem anderen Standort befinden, der kommunikativ mit der/den Empfangspartei(en) gekoppelt ist. Die Empfangsparteien können Kunden, Clients, Partner, Benutzer usw. der Entität sein, die den Edge-Bereitstellungsknoten 644 besitzen und/oder betreiben. Beispielsweise kann die Entität, die den Edge-Bereitstellungsknoten 644 besitzt und/oder betreibt, ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber (oder ein Kunde und/oder Verbraucher davon) von Softwareanweisungen, wie etwa den beispielhaften computerlesbaren Anweisungen 782 der 7B, sein. Die Empfangsteilnehmer können Verbraucher, Dienstanbieter, Benutzer, Einzelhändler, OEMs usw. sein, die die Softwareanweisungen zur Verwendung und/oder zur Lizenzerteilung und/oder zum Weiterverkauf und/oder zur Erteilung von Unterlizenzen erwerben.
Bei einem Beispiel beinhaltet der Edge-Bereitstellungsknoten 644 einen oder mehrere Server und eine oder mehrere Speichervorrichtungen. Die Speichervorrichtungen hosten computerlesbare Anweisungen, wie etwa die beispielhaften computerlesbaren Anweisungen 782 der 7B, wie unten beschrieben. Ähnlich den oben beschriebenen Edge-Gateway-Vorrichtungen 620 stehen der eine oder die mehreren Server des Edge-Bereitstellungsknotens 644 in Kommunikation mit einer Basisstation 642 oder einer anderen Netzwerkkommunikationsentität. Bei einigen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen zum Übertragen der Softwareanweisungen als Teil einer kommerziellen Transaktion zu einer anfordernden Partei. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Softwareanweisungen kann von dem einen oder den mehreren Servern der Softwareverteilungsplattform und/oder über eine Drittpartei-Zahlungsentität gehandhabt werden. Die Server ermöglichen es Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 782 von dem Edge-Bereitstellungsknoten 644 herunterzuladen. Zum Beispiel können die Softwareanweisungen, die den beispielhaften computerlesbaren Anweisungen 782 der 7B entsprechen können, zu der/den beispielhaften Prozessorplattform/en heruntergeladen werden, die die computerlesbaren Anweisungen 782 ausführen sollen, um die hier beschriebenen Verfahren umzusetzen.
Bei einigen Beispielen kann (können) sich die Prozessorplattform(en), die computerlesbare Anweisungen 782 ausführen, physisch an unterschiedlichen geografischen Standorten, gesetzlichen Zuständigkeit usw. befinden. Bei einigen Beispielen bieten ein oder mehrere Server des Edge-Bereitstellungsknotens 644 periodisch Aktualisierungen, übertragen und/oder erzwingen Aktualisierungen an den Softwareanweisungen (zum Beispiel an den beispielhaften computerlesbaren Anweisungen 782 der 7B), um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Softwareanweisungen, die an den Endbenutzervorrichtungen umgesetzt sind, angewandt werden. Bei einigen Beispielen können unterschiedliche Bauelemente der computerlesbaren Anweisungen 782 von unterschiedlichen Quellen und/oder zu unterschiedlichen Prozessorplattformen verteilt werden; zum Beispiel können unterschiedliche Bibliotheken, Plug-ins, Bauelemente und andere Typen von Rechenmodulen, ob kompiliert oder interpretiert, von unterschiedlichen Quellen und/oder zu unterschiedlichen Prozessorplattformen verteilt werden. Zum Beispiel kann ein Teil der Softwareanweisungen (zum Beispiel ein Script, das an sich nicht ausführbar ist) von einer ersten Quelle verteilt werden, während ein Interpreter (der in der Lage ist, das Script auszuführen) von einer zweiten Quelle verteilt werden kann.
Bei weiteren Beispielen können beliebige der Rechenknoten oder Vorrichtungen, die unter Bezugnahme auf die vorliegenden Edge-Computing-Systeme und die vorliegende Umgebung erörtert wurden, basierend auf den Komponenten, die in den 7A und 7B gezeigt sind, erfüllt werden. Jeweilige Edge-Computing-Knoten können als ein Typ von Vorrichtung, Gerät, Computer oder als ein anderes „Ding“ umgesetzt sein, der/das in der Lage ist, mit anderen Edge-, Networking- oder Endpunktbauelementen zu kommunizieren. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Personal Computer, Server, Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Computing-System (zum Beispiel ein Navigationssystem), eine eigenständige Vorrichtung mit einem Außengehäuse, einer Hülle usw. oder eine andere Vorrichtung oder ein anderes System, die/das in der Lage ist, die beschriebenen Funktionen auszuführen, verkörpert sein.
7A ist ein Blockdiagramm einer beispielhaften Umsetzung eines beispielhaften Edge-Computing-Knotens 700, der eine Rechen-Engine (hierin auch als „Computing-Systemschaltungen“ bezeichnet) 702, ein Eingabe/Ausgabe-Subsystem (E/A-Subsystem) 708, eine Datenspeicherung 710, ein Kommunikationsschaltungssubsystem 712 und optional eine oder mehrere Peripherievorrichtungen 714 beinhaltet. Bei anderen Beispielen können jeweilige Rechenvorrichtungen andere oder zusätzliche Bauelemente beinhalten, wie etwa jene, die man typischerweise in einem Computer antrifft (zum Beispiel eine Anzeige, Peripheriegeräte usw.). Zusätzlich können bei einigen Beispielen ein oder mehrere der veranschaulichenden Bauelemente in ein anders Bauelement integriert sein oder anderswie einen Teil davon bilden. Der beispielhafte Edge-Computing-Knoten 700 der 7 kann in einem der in den 1 bis 4 und/oder 6 veranschaulichten Edge-Computing-Systeme umgesetzt werden, um einen beliebigen Edge-Computing-Knoten der 1 bis 4 und/oder 6 umzusetzen.
Der Rechenknoten 700 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen verkörpert sein, die in der Lage sind, verschiedene Rechenfunktionen auszuführen. Bei einigen Beispielen kann der Rechenknoten 700 als eine einzelne Vorrichtung umgesetzt sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein feldprogrammierbares Gate-Array (FPGA), ein System-on-a-Chip (SOC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung. Bei dem veranschaulichenden Beispiel weist der Rechenknoten 700 einen Prozessor 704 und einen Speicher 706 auf oder ist als dieser ausgeführt. Der Prozessor 704 kann als eine beliebige Art von Prozessor verkörpert sein, der in der Lage ist, die hierin beschriebenen Funktionen (zum Beispiel Ausführen einer Anwendung) auszuführen. Der Prozessor 704 kann zum Beispiel als ein oder mehrere Mehrkernprozessor(en), ein Mikrocontroller, eine Verarbeitungseinheit, eine spezialisierte oder Sonderverarbeitungseinheit oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerschaltung verkörpert sein.
Bei einigen Beispielen kann der Prozessor 704 als FPGA, anwendungsspezifische integrierte Schaltung (ASIC), rekonfigurierbare Hardware oder Hardwareschaltungen oder andere spezialisierte Hardware umgesetzt sein, diese beinhalten oder mit diesen gekoppelt sein, um eine Leistungsfähigkeit der hierin beschriebenen Funktionen zu ermöglichen. Bei einigen Beispielen kann der Prozessor 704 auch als eine spezialisierte x-Verarbeitungseinheit (x-Processing Unit - xPU) verkörpert sein, die auch als eine Datenverarbeitungseinheit (Data Processing Unit - DPU), eine Infrastrukturverarbeitungseinheit (Infrastructure Processing Unit -IPU) oder eine Netzwerkverarbeitungseinheit (Network Processing Unit - NPU) bekannt ist. Eine derartige xPU kann als eine eigenständige Schaltung oder ein eigenständiges Schaltungspaket verkörpert sein, innerhalb eines SOC integriert sein oder mit Vernetzungsschaltungen (zum Beispiel in einem SmartNIC), Beschleunigungsschaltungen, Speichervorrichtungen oder AI-Hardware (zum Beispiel GPUs oder programmierte FPGAs) integriert sein. Eine derartige xPU kann dazu ausgelegt sein, eine Programmierung zu erhalten, um einen oder mehrere Datenströme zu verarbeiten und spezifische Aufgaben und Aktionen für die Datenströme auszuführen (wie etwa Hosten von Mikrodiensten, Ausführen von Dienstverwaltung oder Orchestrierung, Organisieren oder Managen von Server- oder Datenzentrum-Hardware, Managen von Dienst-Netzen oder Sammeln und Verteilen von Telemetrie), außerhalb der CPU oder Allzweckverarbeitungshardware. Es versteht sich jedoch, dass eine xPU, ein SOC, eine CPU und andere Variationen des Prozessors 704 koordiniert miteinander arbeiten können, um viele Arten von Operationen und Anweisungen innerhalb des und für den Computerknoten 700 auszuführen.
Der Hauptspeicher 706 kann als eine beliebige Art flüchtiger (zum Beispiel dynamischer Direktzugriffsspeicher (Dynamic Random Access Memory - DRAM) usw.) oder nichtflüchtiger Speicher oder nichtflüchtiger Datenspeicher umgesetzt sein, die zum Ausführen der hierin beschriebenen Funktionen in der Lage sind. Ein flüchtiger Speicher kann ein Speicherungsmedium sein, das Leistung zum Aufrechterhalten des Zustands der Daten, die von dem Medium gespeichert werden, benötigt. Nicht einschränkende Beispiele für flüchtigen Speicher können verschiedene Typen von Direktzugriffsspeicher (RAM), wie etwa DRAM oder statischen Direktzugriffsspeicher (SRAM), beinhalten. Ein bestimmter Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (Synchronous Dynamic Random Access Memory - SDRAM).
Bei einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung, wie etwa jene, die auf NAND- oder NOR-Technologien basieren. Eine Speichervorrichtung kann auch eine dreidimensionale Kreuzungspunktspeichervorrichtung (zum Beispiel Intel^®-3D-XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige Speichervorrichtungen zum Schreiben an Ort und Stelle beinhalten. Die Speichervorrichtung kann auf den Die selbst und/oder ein gekapseltes Speicherprodukt verweisen. Bei einigen Beispielen kann der 3D-Kreuzungspunktspeicher (zum Beispiel Intel^®-3D-XPoint™-Speicher) eine transistorlose stapelbare Kreuzungspunktarchitektur umfassen, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind, und bei der die Bitspeicherung auf einer Änderung des Bulkwiderstands basiert. Bei einigen Beispielen kann der gesamte Hauptspeicher 706 oder ein Teil davon in den Prozessor 704 integriert sein. Der Hauptspeicher 706 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die von der(den) Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
Die Computing-Systemschaltungen 702 sind kommunikativ mit anderen Bauelementen des Rechenknotens 700 über das E/A-Subsystem 708 gekoppelt, das als Schaltungen und/oder Bauelemente verkörpert sein kann, um Eingabe/Ausgabe-Operationen mit den Computing-Systemschaltungen 702 (zum Beispiel mit dem Prozessor 704 und/oder dem Hauptspeicher 706) und anderen Bauelementen der Computing-Systemschaltungen 702 zu ermöglichen. Das E/A-Subsystem 708 kann zum Beispiel als Speichersteuervorrichtungs-Hubs, Eingabe/Ausgabe-Steuer-Hubs, integrierte Sensor-Hubs, Firmwarevorrichtungen, Kommunikationslinks (zum Beispiel Punkt-zu-Punkt-Links, Bus-Links, Drähte, Kabel, Lichtleiter, Leiterplattenbahnen usw.) und/oder andere Bauelemente und Subsysteme umgesetzt sein oder diese anderswie beinhalten, um die Eingabe/Ausgabe-Operationen zu erleichtern. Bei einigen Beispielen kann das E/A-Subsystem 708 einen Teil eines System-on-a-Chip (SoC) bilden und gemeinsam mit dem Prozessor 704 und/oder dem Hauptspeicher 706 und/oder anderen Bauelementen der Computing-Systemschaltungen 702 in die Computing-Systemschaltungen 702 integriert sein.
Die eine oder die mehreren veranschaulichenden Datenspeicherungsvorrichtungen 710 können als eine beliebige Art von Vorrichtungen verkörpert sein, die zur Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert sind, wie etwa zum Beispiel Speichervorrichtungen und -schaltungen, Speicherkarten, Festplattenlaufwerke, Festkörperlaufwerke oder andere Datenspeicherungsvorrichtungen. Individuelle Datenspeicherungsvorrichtungen 710 können eine Systempartition, die Daten und Firmwarecode für die Datenspeicherungsvorrichtung 710 speichert, beinhalten. Individuelle Datenspeicherungsvorrichtungen 710 können auch eine oder mehrere Betriebssystempartitionen, die Dateien und ausführbare Dateien für Betriebssysteme in Abhängigkeit von zum Beispiel dem Typ des Computerknotens 700 speichern, beinhalten.
Die Kommunikationsschaltungen 712 können als eine beliebige Kommunikationsschaltung, -vorrichtung oder -sammlung davon verkörpert sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen den Computing-Systemschaltungen 702 und einer anderen Rechenvorrichtung (zum Beispiel einem Edge-Gateway eines umsetzenden Edge-Computing-Systems) zu ermöglichen. Die Kommunikationsschaltungen 712 können dazu konfiguriert sein, eine oder mehrere Kommunikationstechniken (zum Beispiel verdrahtete oder drahtlose Kommunikationen) und assoziierte Protokolle (zum Beispiel ein zellulares Networking-Protokoll, wie etwa einen 3GPP-4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/Wi-Fi^®, ein Wireless Wide Area Network Protocol, Ethernet, Bluetooth ^®, Bluetooth Low Energy, ein loT-Protokoll, wie etwa IEEE 802.15.4 oder ZigBee^®, Low-Power Wide Area Network-Protokolle (LPWAN-Protokolle) oder Low-Power Wide Area-Protokolle (LPWA-Protokolle) usw.) zu verwenden, um eine derartige Kommunikation zu bewirken.
Die veranschaulichenden Kommunikationsschaltungen 712 beinhalten eine Netzwerkschnittstellensteuervorrichtung (NIC) 720, die auch als eine Host-Fabric-Schnittstelle (Host Fabric Interface - HFI) bezeichnet werden kann. Die NIC 720 kann als eine oder mehrere Add-In-Boards, Tochterkarten, Netzwerkschnittstellenkarten, Controllerchips, Chipsätze oder andere Vorrichtungen verkörpert sein, die von dem Rechenknoten 700 verwendet werden können, um sich mit einer anderen Rechenvorrichtung (zum Beispiel einem Edge-Gateway-Knoten) zu verbinden. Bei einigen Beispielen kann die NIC 720 als Teil eines System-on-a-Chip (SoC) verkörpert sein, das einen oder mehrere Prozessoren beinhaltet, oder auf einem Multichip-Gehäuse enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. Bei einigen Beispielen kann die NIC 720 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) beinhalten, die beide für die NIC 720 lokal sind. Bei derartigen Beispielen kann der lokale Prozessor der NIC 720 dazu in der Lage sein, eine oder mehrere der Funktionen der hier beschriebenen Computing-Systemschaltungen 702 auszuführen. Zusätzlich oder alternativ kann bei derartigen Beispielen der lokale Speicher der NIC 720 in ein oder mehrere Bauelemente des Client-Rechenknotens auf Platinenebene, Sockelebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
Zusätzlich kann bei einigen Beispielen ein jeweiliger Computerknoten 700 eine oder mehrere Peripherievorrichtungen 714 beinhalten. Derartige Peripherievorrichtungen 714 können eine beliebige Art von Peripherievorrichtung beinhalten, die man in einer Rechenvorrichtung oder einem Server antrifft, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe-/Ausgabevorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 700. Bei weiteren Beispielen kann der Rechenknoten 700 durch einen jeweiligen Edge-Computing-Knoten (ob ein Client, Gateway oder Aggregationsknoten) in einem Edge-Computing-System oder ähnlichen Formen von Geräten, Computern, Subsystemen, Schaltungen oder anderen Komponenten verkörpert sein.
Bei einem ausführlicheren Beispiel veranschaulicht 7B ein Blockdiagramm eines Beispiels, das ein Edge-Computing-Knoten 750 sein kann, der strukturiert ist, um die Anweisungen der 15 und 16 auszuführen, um die Techniken (zum Beispiel Operationen, Prozesse, Verfahren und Methodologien), die hierin beschrieben sind, wie etwa die Einrichtung der 9, umzusetzen. Dieser Edge-Computing-Knoten 750 stellt eine nähere Ansicht der jeweiligen Bauelemente des Knotens 700 bereit, wenn er als oder als Teil einer Rechenvorrichtung (zum Beispiel als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) umgesetzt wird. Der Edge-Computing-Knoten 750 kann beliebige Kombinationen der hier referenzierten Hardware oder logischen Bauelemente beinhalten und kann eine beliebige Vorrichtung, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination derartiger Netzwerke verwendbar ist, beinhalten oder mit dieser koppeln. Die Bauelemente können als ICs, Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Anweisungssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die in dem Edge-Computing-Knoten 750 angepasst sind, oder als Bauelemente, die anderswie in einem Chassis eines größeren Systems integriert sind, umgesetzt sein. Zum Beispiel kann der Edge-Computing-Knoten 750 zum Beispiel ein Server, ein Personal Computer, eine Workstation, eine selbstlernende Maschine (zum Beispiel ein neuronales Netzwerk), eine Mobilvorrichtung (zum Beispiel ein Mobiltelefon, ein Smartphone, ein Tablet, wie etwa ein iPad™), ein Personal Digital Assistant (PDA) sein, ein Internet-Gerät, ein DVD-Player, ein CD-Player, ein digitaler Videorekorder, ein Blue-Ray-Player, eine Spielkonsole, ein persönlicher Videorekorder, eine Set-Top-Box, ein Headset oder eine andere anziehbare Vorrichtung, eine Vorrichtung des Internets der Dinge (loT) oder eine andere Art von Rechenvorrichtung sein.
Die Edge-Rechenvorrichtung 750 kann Verarbeitungsschaltungen in der Form eines Prozessors 752 beinhalten, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithread-Prozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor, eine xPU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 752 kann ein Teil eines System-on-Chip (SoC) sein, in dem der Prozessor 752 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Gehäuse gebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien. Als ein Beispiel kann der Prozessor 752 einen auf Intel^®-Architektur Core™ basierenden CPU-Prozessor, wie etwa einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-, einen i9- oder einen Prozessor der Klasse MCU oder einen anderen derartigen Prozessor, der bei Intel^® erhältlich ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie etwa von Advanced Micro Devices, Inc. erhältlich. (AMD^®) der Firma Sunnyvale, Kalifornien, ein MIPS^®-basiertes Design der Firma MIPS Technologies, Inc. der Firma Sunnyvale, Kalifornien, ein ARM^®-basiertes Design, unter Lizenz der ARM Holdings, Ltd. oder eines Kunden dieser, oder deren Lizenznehmer oder Adopter. Die Prozessoren können Einheiten beinhalten, wie etwa einen A5-A13-Prozessor von Apple^® Inc., einen Snapdragon™-Prozessor von QualCommon^® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. Der Prozessor 752 und die begleitenden Schaltungen können mit einem einzigen Sockelformfaktor, mehreren Sockelformfaktoren oder einer Vielfalt anderer Formate bereitgestellt sein, einschließlich in eingeschränkten Hardwarekonfigurationen oder Konfigurationen, die weniger als alle in 7B gezeigten Elemente beinhalten. Bei diesem Beispiel setzt der Prozessor 752 den Objekt-Manager 812a und seine Bauelemente, wie in 9 gezeigt, um.
Der Prozessor 752 kann über ein Interconnect 756 (zum Beispiel einen Bus) mit einem Systemspeicher 754 kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine gegebene Menge von Systemspeicher bereitzustellen. Als Beispiele kann der Speicher Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC: Joint Electron Devices Engineering Council) sein, wie etwa den DDR- oder mobilen DDDR-Standards (zum Beispiel LPDDR, LPDDR2, LPDDR3 oder LPDDR4). Bei bestimmten Beispielen kann ein Speicherbauelement einem von JEDEC vertriebenen DRAM-Standard entsprechen, wie etwa JESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Low Power DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Derartige Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speicherungseinrichtungen, die derartige Standards umsetzen, können als DDR-basierte Schnittstellen bezeichnet werden. Bei diversen Umsetzungen können die individuellen Speichervorrichtungen von einer beliebigen Anzahl von unterschiedlicher Gehäusetypen sein, wie etwa Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). Diese Vorrichtungen können bei einigen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum durch einen gegebenen Steckverbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherumsetzungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, zum Beispiel Dual Inline Memory Modules (DIMMs) unterschiedlicher Varianten, einschließlich unter anderem microDIMMs oder MiniDIMMs.
Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann eine Speicherung 758 auch über das Interconnect 756 mit dem Prozessor 752 koppeln. Bei einem Beispiel kann die Speicherung 758 über ein Festkörperplattenlaufwerk (SSDD) umgesetzt sein. Andere Vorrichtungen, die für die Speicherung 758 verwendet werden können, beinhalten Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, XD-Bildkarten und dergleichen, sowie USB-Flash-Laufwerke. Bei einem Beispiel kann die Speichervorrichtung eine Speichervorrichtung sein oder Speichervorrichtungen beinhalten, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenniveaus, NOR-Flash-Speicher, Phasenwechselspeicher mit einzelnen oder mehreren Niveaus (PCM) verwenden, einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM), antiferroelektrischen Speicher, magnetoresistiven Direktzugriffsspeicher-Speicher (MRAM-Speicher), der Memristortechnologie beinhaltet, resistiven Speicher, einschließlich der Metalloxid- Basis, der Sauerstoff-Vacancy-Basis und des Direktzugriffsspeichers mit leitender Brücke (CB-RAM) oder Spin-Transfer-Torque-MRAM (STT-MRAM), eines Spintronic-Magnetübergangsspeicher-basierten Vorrichtung, eine MTJ-Basierte (Magnetic Tunnel Junction - MTJ-basierte Vorrichtung), eine DW- (Domain Wall-) und SOT- (Spin Orbit Transfer-) -basierte Vorrichtung, eine Thyristor-basierte Speichervorrichtung oder eine Kombination beliebiger der Obigen oder eines anderen Speichers.
Bei Niedrigleistungsumsetzungen kann die Speicherung 758 ein On-Die-Speicher oder -Register sein, der (das) mit dem Prozessor 752 assoziiert ist. Bei einigen Beispielen kann die Speicherung 758 jedoch unter Verwenden eines Mikrofestplattenlaufwerks (HDD) umgesetzt werden. Weiter kann eine beliebige Anzahl neuer Technologien für die Speicherung 758 zusätzlich zu oder an Stelle der beschriebenen Technologien verwendet werden, wie unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher. 8922
Die Bauelemente können über das Interconnect 756 in Kommunikation stehen. Das Interconnect 756 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industriestandardarchitektur (ISA), erweiterte ISA (EISA), Peripheriekomponenten-Interconnect (PCI), erweitertes Peripheriekomponenten-Interconnect (PCIx), PCI-EXPRESS (PCle) oder eine beliebige Anzahl anderer Technologien. Das Interconnect 756 kann ein proprietärer Bus sein, der zum Beispiel in einem SoCbasierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
Das Interconnect756 kann den Prozessor 752 mit einem Transceiver 766 für Kommunikationen mit den verbundenen Edge-Vorrichtungen 762 koppeln. Der Transceiver 766 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa 2,4 Gigahertz-Übertragungen (2,4 GHz-Übertragungen) unter dem IEEE 802.15.4-Standard, unter Verwenden des Bluetooth^®-Niederenergie-Standards (BLE-Standards), wie unter anderem von der Bluetooth^® -Secial Interest Group definiert, oder des ZigBee^®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes drahtloses Kommunikationsprotokoll konfiguriert sind, kann für die Verbindungen zu den verbundenen Edge-Vorrichtungen 762 verwendet werden. Zum Beispiel kann eine WLAN-Einheit (Wireless Local Area NetworkEinheit) verwendet werden, um Wi-Fi^®-Kommunikationen gemäß dem IEEE-Standard (Standard des Institute of Electrical and Electronics Engineers) 802.11-umzusetzen. Zusätzlich können drahtlose Weitbereichskommunikationen, zum Beispiel gemäß einem zellularen oder anderen drahtlosen Weitbereichsprotokoll, über eine drahtlose Weitbereichsnetzwerk-Einheit (WWAN-Einheit) stattfinden.
Der drahtlose Netzwerk-Transceiver 766 (oder mehrere Transceiver) kann unter Verwenden mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Beispielsweise kann der Edge-Computing-Knoten 750 mit nahen Vorrichtungen, zum Beispiel innerhalb von etwa 10 Metern, unter Verwenden eines lokalen Transceivers basierend auf BLE oder eines anderen Niedrigleistungsfunks kommunizieren, um Leistung zu sparen. Weiter entfernte verbundene Edge-Vorrichtungen 762, zum Beispiel innerhalb von etwa 50 Metern, können über ZigBee^® oder andere Zwischenleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlichen Leistungsniveaus abgewickelt werden oder können über separate Transceiver laufen, zum Beispiel über einen lokalen Transceiver, der BLE verwendet, und einen separaten Mesh-Transceiver, der ZigBee^® verwendet.
Ein drahtloser Netzwerk-Transceiver 766 (zum Beispiel ein Funk-Transceiver) kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 790 über lokale oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der drahtlose Netzwerk-Transceiver 766 kann ein LPWA-Transceiver sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Computing-Knoten 750 kann über einen weiten Bereich unter Verwenden von LoRaWAN™ (Long Range Wide Area Network), das von Semtech und der LoRa Alliance entwickelt wird, kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, können aber mit einer Anzahl anderer Cloud-Transceiver, die Kommunikationen mit großer Reichweite, niedriger Bandbreite umsetzen, wie etwa Sigfox, und anderen Technologien verwendet werden. Weiter können andere Kommunikationstechniken, wie etwa Zeitschlitz-Kanalspung, die in der Spezifikation IEEE 802.15.4e beschrieben sind, verwendet werden.
Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den für den drahtlosen Netzwerk-Transceiver 766 erwähnten Systemen, wie hierin beschrieben, verwendet werden. Der Transceiver766 kann zum Beispiel einen zellularen Transceiver beinhalten, der Spreizspektrum-Kommunikationen (SPA/SAS-Kommunikationen) zum Umsetzen von Hochgeschwindigkeitskommunikationen verwendet. Weiter kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi^®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Der Transceiver 766 kann Funkgeräte beinhalten, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen (Third-Generation-Partnership-Project-Spezifikationen) kompatibel sind, wie etwa Long-Term-Evolution-Kommunikationssysteme (LTE-Kommunikationssysteme)- und 5th-Generation-Kommunikationssysteme (5G-Kommunikationssysteme), die am Ende der vorliegenden Offenbarung ausführlicher besprochen sind. Eine Netzwerkschnittstellensteuervorrichtung (NIC) 768 kann enthalten sein, um eine verdrahtete Kommunikation zu Knoten der Edge-Cloud 790 oder zu anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 762 (die zum Beispiel in einem Mesh arbeiten), bereitzustellen. Die verdrahtete Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie unter vielen anderen etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET. Eine zusätzliche NIC 768 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 768 Kommunikationen mit der Cloud über Ethernet bereitstellt und eine zweite NIC 768, die Kommunikationen mit anderen Vorrichtungen über einen anderen Typ von Netzwerk bereitstellt.
Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Vorrichtung zu einem anderen Bauelement oder einem anderen Netzwerk, können anwendbare Kommunikationsschaltungen, die von der Vorrichtung verwendet werden, ein beliebiges oder mehrere der Bauelemente 764, 766, 768 oder 770 beinhalten oder von diesen verkörpert werden. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (zum Beispiel Empfangen, Übertragen usw.) von derartigen Kommunikationsschaltungen umgesetzt werden.
Der Edge-Computing-Knoten 750 kann Beschleunigungsschaltungen 764 beinhalten oder mit diesen gekoppelt sein, die durch einen oder mehrere AI-Beschleuniger, einen neuronalen Computing-System-Stick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, eine Anordnung aus xPUs/DPUs/IPU/NPUs, einem oder mehreren SoCs, einem oder mehreren CPUs, einem oder mehreren digitalen Signalprozessoren, dedizierten ASICs oder anderen Formen spezialisierter Prozessoren oder Schaltungen, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben ausgelegt sind, verkörpert sind. Diese Aufgaben können AI-Verarbeitung (einschließlich Operationen für maschinelles Lernen-, Training, Inferenz und Klassifizierung), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objekterfassung, Regelanalyse oder dergleichen beinhalten. Diese Aufgaben können auch die an anderer Stelle in diesem Dokument diskutierten spezifischen Edge-Computing-Aufgaben für Dienstverwaltungs- und Dienstoperationen beinhalten.
Das Interconnect756 kann den Prozessor 752 mit einem Sensor-Hub oder einer externen Schnittstelle 770 koppeln, die zum Verbinden zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die Vorrichtungen können Sensoren 772, wie etwa Beschleunigungsmesser, Niveausensoren, Strömungssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Navigationssystems (zum Beispiel GPS), Drucksensoren, barometrische Drucksensoren und dergleichen beinhalten. Der Hub oder die Schnittstelle 770 kann weiter verwendet werden, um den Edge-Computing-Knoten 750 mit Aktuatoren 774, wie etwa Leistungsschaltern, Ventilaktuatoren, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen, zu verbinden.
Bei einigen optionalen Beispielen können verschiedene Eingabe/AusgabeVorrichtungen (E/A-Vorrichtungen) innerhalb des Edge-Computing-Knotens 750 vorhanden oder mit diesem verbunden sein. Beispielsweise kann eine Anzeige oder eine andere Ausgabevorrichtung 784 enthalten sein, um Informationen, wie etwa Sensorablesungen oder Aktuatorposition, zu zeigen. Eine Eingabevorrichtung 786, wie etwa ein Touchscreen oder eine Tastatur, kann enthalten sein, um eine Eingabe anzunehmen. Eine Ausgabevorrichtung 784 kann eine beliebige Anzahl von Formen einer Audio- oder visuellen Anzeige beinhalten, einschließlich einfacher visueller Ausgaben, wie etwa binärer Statusindikatoren (zum Beispiel LEDs) und visueller Mehrzeichenausgaben, oder komplexere Ausgaben, wie Bildschirme (zum Beispiel LCD-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb des Edge-Computing-Knotens 750 erzeugt oder produziert wird. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe bereitzustellen und eine Eingabe eines Edge-Computersystems zu empfangen; Bauelemente oder Dienste eines Edge-Computersystems zu verwalten; einen Zustand eines Edge-Computerbauelements oder eines Edge-Computerdienstes zu identifizieren; oder eine beliebige andere Anzahl von Management- oder Verwaltungsfunktionen oder Dienstnutzungsfällen auszuführen.
Eine Batterie 776 kann den Edge-Computing-Knoten 750 mit Strom versorgen, obwohl sie bei Beispielen, in denen der Edge-Computing-Knoten 750 an einem festen Ort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie als Backup oder für temporäre Fähigkeiten verwendet werden kann. Die Batterie 776 kann eine Lithium-Ion-Batterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
Eine Batterieüberwachungs-/Ladevorrichtung 778 kann in dem Edge-Computing-Knoten 750 enthalten sein, um den Ladezustand (SoCh) der Batterie 776, falls enthalten, zu verfolgen. Die Batterieüberwachungs-/Ladevorrichtung 778 kann verwendet werden, um andere Parameter der Batterie 776 zu überwachen, um Ausfallvorhersagen, wie etwa den Gesundheitszustand (SoH: State of Health) und den Funktionszustand (SoF: State of Function) der Batterie 776 bereitzustellen. Die Batterieüberwachungs-/Ladevorrichtung 778 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa eine LTC4020 oder einen LTC2990 von Linear Technologies, eine ADT7488A von ON Semiconductor, Phoenix Arizona, oder eine IC von der UCD90xxx-Familie von Texas Instruments, Dallas, TX. Die Batterieüberwachungs-/Ladevorrichtung 778 kann die Informationen über die Batterie 776 über das Interconnect 756 an den Prozessor 752 kommunizieren. Die Batterieüberwachungs-/Ladevorrichtung 778 kann auch einen Analog-Digital-Wandler (ADC) beinhalten, der es dem Prozessor 752 ermöglicht, die Spannung der Batterie 776 oder den Stromfluss von der Batterie 776 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Handlungen zu bestimmen, die der Edge-Computing-Knoten 750 ausführen kann, wie etwa Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Abtastfrequenz und dergleichen.
Ein Leistungsblock 780 oder eine andere Leistungsversorgung, die mit einem Stromnetz gekoppelt ist, kann mit der Batterieüberwachungs-/Ladevorrichtung 778 gekoppelt sein, um die Batterie 776 zu laden. Bei einigen Beispielen kann der Leistungsblock 780 mit einem drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel durch eine Ringantenne in dem Edge-Computing-Knoten 750, zu erhalten. Eine drahtlose Batterieladeschaltung, wie etwa unter anderem ein LTC4020-Chip von Linear Technologies in Milpitas, Kalifornien, kann in der Batterieüberwachungs-/Ladevorrichtung 778 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 776 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwenden des von der Airfuel Alliance vertriebenen Airfuel Standards, des von dem Wireless Power Consortium vertriebenen Qi-Drahtlosladestandards oder des von der Alliance für Wireless Power vertriebenen Rezence-Ladestandards ausgeführt werden.
Die Speicherung 758 kann Anweisungen 782 in der Form von Software, Firmware oder Hardwarebefehlen zum Umsetzen der hierin beschriebenen Techniken beinhalten. Obwohl derartige Anweisungen 782 als Codeblöcke gezeigt sind, die in dem Speicher 754 und der Speicherung 758 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch fest verdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC: Application Specific Integrated Circuit) eingebaut sind.
Bei einem Beispiel können die Anweisungen 782, die über den Speicher 754, die Speicherung 758 oder den Prozessor 752 bereitgestellt werden, als ein nichtflüchtiges maschinenlesbares Medium 760 umgesetzt werden, das Code beinhaltet, um den Prozessor 752 anzuweisen, elektronische Operationen in dem Edge-Computing-Knoten 750 auszuführen. Der Prozessor 752 kann über das Interconnect 756 auf das nichtflüchtige maschinenlesbare Medium 760 zugreifen. Beispielsweise kann das nichtflüchtige maschinenlesbare Medium 760 durch Vorrichtungen verkörpert sein, die für die Speicherung 758 beschrieben sind, oder kann spezifische Speichereinheiten, wie etwa optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwarevorrichtungen, beinhalten. Das nichtflüchtige, maschinenlesbare Medium 760 kann Anweisungen beinhalten, um den Prozessor 752 anzuweisen, eine spezifische Sequenz oder einen spezifischen Fluss von Aktionen auszuführen, wie zum Beispiel mit Bezug auf das Flussdiagramm bzw. die Flussdiagramme und Blockdiagramme von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Wie hierin verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
Bei weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch ein beliebiges konkretes Medium, das in der Lage ist, Anweisungen zum Ausführen durch eine Maschine zu speichern, zu codieren oder zu tragen, und die bewirken, dass die Maschine eines oder mehrere der Verfahren der vorliegenden Offenbarung ausführt, oder das in der Lage ist, Datenstrukturen zu speichern, zu codieren oder zu tragen, die von derartigen Anweisungen genutzt werden oder mit diesen assoziiert sind. Ein „maschinenlesbares Medium“ kann dementsprechend unter anderem Festkörperspeicher und optische und magnetische Medien beinhalten. Spezifische Beispiele für maschinenlesbare Medien beinhalten nichtflüchtigen Speicher, wie zum Beispiel Halbleiterspeichervorrichtungen (zum Beispiel elektrisch programmierbarer Nur-Lese-Speicher (Electrically Programmable Read-Only Memory - EPROM), elektrisch löschbarer programmierbarer Nur-Lese-Speicher (Electrically Erasable Programmable Read-Only Memory - EEPROM)) und Flash-Speichervorrichtungen, Magnetplatten, wie zum Beispiel interne Festplatten und austauschbare Speicherplatten, magnetooptische Speicherplatten und CD-ROM- und DVD-ROM-Speicherplatten. Die Anweisungen, die von einem maschinenlesbaren Medium verkörpert sind, können weiter über ein Kommunikationsnetzwerk unter Nutzen eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung, die ein beliebiges einer Anzahl von Übertragungsprotokollen (zum Beispiel HTTP) nutzt, übertragen oder empfangen werden.
Ein maschinenlesbares Medium kann von einer Speicherungsvorrichtung oder einer anderen Einrichtung, die in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten, bereitgestellt werden. Bei einem Beispiel können Informationen, die auf einem maschinenlesbaren Medium gespeichert oder anderswie bereitgestellt werden, Anweisungen, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können, repräsentieren. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (zum Beispiel in komprimierter oder verschlüsselter Form), verpackte Anweisungen (zum Beispiel aufgeteilt in mehrere Pakete) oder dergleichen beinhalten. Die Informationen, die Anweisungen in dem maschinenlesbaren Medium repräsentieren, können von Verarbeitungsschaltungen in die Anweisungen verarbeitet werden, um beliebige der hierin besprochenen Operationen umzusetzen. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (zum Beispiel Verarbeiten durch die Verarbeitungsschaltungen) Folgendes beinhalten: Kompilieren (zum Beispiel aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (zum Beispiel dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderswie Manipulieren der Informationen in die Anweisungen.
Bei einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (zum Beispiel durch die Verarbeitungsschaltungen) beinhalten, um die Anweisungen aus einem Zwischenformat oder einem vorverarbeiteten Format, das von dem maschinenlesbare Medium bereitgestellt wird, anzulegen. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen anzulegen. Die Informationen können sich zum Beispiel in mehreren komprimierten Quellcodepaketen (oder Objektcode oder ausführbarem Binär-Code usw.) auf einem oder mehreren Fernservern befinden. Die Quellcodepakete können beim Transit über ein Netzwerk verschlüsselt sein, und, falls notwendig, entschlüsselt, unkomprimiert, zusammengesetzt (zum Beispiel verknüpft) und an einer lokalen Maschine kompiliert oder interpretiert (zum Beispiel in eine Bibliothek, eigenständiges ausführbares Programm usw.) unddurch die lokale Maschine ausgeführt werden.
Die maschinenausführbaren Anweisungen 1500, 1600 der 15 und 16 können in der Massenspeicherungsvorrichtung 1028, in dem flüchtigen Speicher 1014, in dem nichtflüchtigen Speicher 1016 und/oder auf einem entfernbaren nichtflüchtigen computerlesbaren Speichermedium, wie etwa einer CD oder DVD, gespeichert sein.
Edge-Computing-Verwendungsfälle in Mobilnetzwerkgefügen wurden zur Integration mit MEC-Ansätzen (Multi-Access Edge Computing - MEC-Ansätzen) entwickelt, die auch als „Mobiles Edge-Computing“ bekannt sind. MEC-Ansätze sind dazu ausgelegt, es Anwendungsentwicklern und Inhaltsanbietern zu erlauben, auf Rechenfähigkeiten und eine Informationstechnologie-Service-Umgebung (IT-Service-Umgebung) in dynamischen Mobilnetzwerkgefügen am Rand des Netzwerks zuzugreifen. Begrenzte Standards wurden von der Industriespezifikationsgruppe (ISG) des European Telecommunications Standards Institute (ETSI) bei einem Versuch entwickelt, gemeinsame Schnittstellen für den Betrieb von MEC-Systemen, Plattformen, Hosts, Diensten und Anwendungen zu definieren.
Edge-Computing, MEC, und verwandte Technologien versuchen, reduzierte Latenz, erhöhte Reaktionsfähigkeit und mehr verfügbare Rechenleistung bereitzustellen als sie in herkömmlichen Cloud-Netzwerkdiensten und Weitverkehrsnetzwerk-Verbindungen angeboten werden. Die Integration von Mobilität und dynamisch gestarteten Diensten in einige mobile Nutzungen und Vorrichtungsverarbeitungsnutzungsfälle hat jedoch zu Einschränkungen und Bedenken hinsichtlich Orchestrierung, funktioneller Koordination und Ressourcenverwaltung geführt, insbesondere bei komplexen Mobilitätsgefügen, in denen viele Teilnehmer (zum Beispiel Vorrichtungen, Hosts, Mandanten, Dienstanbieter, Betreiber usw.) involviert sind.
Auf eine ähnliche Weise sind loT-Netzwerke und -Vorrichtungen dazu ausgelegt, eine verteilte Rechenanordnung von einer Vielfalt von Endpunkten anzubieten. loT-Vorrichtungen können physische oder virtualisierte Objekte sein, die in einem Netzwerk kommunizieren können, und können Sensoren, Aktoren und andere Eingabe-/Ausgabebauelemente beinhalten, die verwendet werden können, um Daten zu sammeln oder Aktionen in einer Realweltumgebung auszuführen. loT-Vorrichtungen können zum Beispiel Endpunktvorrichtungen mit niedriger Leistung beinhalten, die eingebettet oder an alltäglichen Dingen angebracht sind, wie etwa an Gebäuden, Fahrzeugen, Paketen usw., um ein zusätzliches Niveau künstlicher Sinneswahrnehmung dieser Dinge bereitzustellen. loT-Vorrichtungen wurden beliebter und daher haben sich Anwendungen, die diese Vorrichtungen verwenden, stark vermehrt.
Bei einigen Beispielen kann eine Edge-Umgebung einen Unternehmens-Edge beinhalten, bei dem Kommunikation mit und/oder Kommunikation innerhalb des Unternehmens-Edge über drahtlose und/oder verdrahtete Konnektivität erleichtert werden kann. Der Einsatz verschiedener Edge-, Fog-, MEC- und loT-Netzwerke, -Vorrichtungen und - Dienste hat eine Anzahl fortgeschrittener Verwendungsfälle und -szenarien eingeführt, die am und in Richtung des Randes des Netzwerks auftreten. Diese fortgeschrittenen Nutzungsfälle haben jedoch unter vielen anderen Problemen auch eine Reihe entsprechender technischer Herausforderungen im Zusammenhang mit Sicherheits-, Verarbeitungs- und Netzwerkressourcen, Dienstverfügbarkeit und Effizienz eingeführt. Eine derartige Herausforderung betrifft Edge-, Fog-, MEC- und loT-Netzwerke, -Vorrichtungen und -Dienste, die Workloads im Auftrag von Endpunktvorrichtungen ausführen, einschließlich Einrichten einer Herkunft zum Bestimmen von Datenintegrität und/oder Dateneinschränkungen.
Die vorliegenden Techniken und Konfigurationen können in Verbindung mit vielen Aspekten aktueller Networking-Systeme genutzt werden, werden aber unter Bezugnahme auf Edge-Cloud, loT, MEC und andere verteilte Recheneinsätze bereitgestellt. Die folgenden Systeme und Techniken können in einer Vielfalt verteilter, virtualisierter oder verwalteter Edge-Datenverarbeitungssysteme umgesetzt werden oder diese ergänzen. Dazu zählen Umgebungen, in denen Netzwerkdienste unter Verwenden von MEC-, drahtloser Netzwerkkonfigurationen der vierten Generation (4G) oder fünfter Generation (5G) umgesetzt oder verwaltet werden; oder in verdrahteten Netzwerkkonfigurationen, die Faser-, Kupfer- und/oder andere Verbindungen involvieren. Weiter können Verarbeitungsaspekte durch die jeweiligen Computing-Bauelemente rechnerische Elemente involvieren, die sich in geografischer Nähe zu dem Benutzerendgerät oder anderen Endpunktstandorten befinden, wie ein Smartphone, ein Fahrzeugkommunikationsbauelement, ein loT-Gerät usw. Weiter können die vorliegend offenbarten Techniken andere Edge/MEC/loT-Netzwerkkommunikationsstandards und - konfigurationen und andere Zwischenverarbeitungsentitäten und Architekturen betreffen.
Wie hierin offenbart, beinhalten Edge-Umgebungen Netzwerke und/oder Teile von Netzwerken, die sich zwischen einer Cloud-Umgebung und einer Endpunktumgebung befinden. Edge-Umgebungen ermöglichen Berechnungen von Workloads an Rändern eines Netzwerks. Eine Endpunktvorrichtung kann zum Beispiel eine nahe Basisstation auffordern, eine Workload an Stelle eines zentralen Servers in einer Cloud-Umgebung zu berechnen. Edge-Umgebungen beinhalten Edge-Dienste, die Speicherpools, Speicherressourcen und Verarbeitungsressourcen beinhalten. Edge-Dienste führen Berechnungen, wie etwa eine Ausführung einer Workload, für andere Edge-Dienste und/oder Edge-Knoten aus. Edge-Umgebungen erleichtern Verbindungen zwischen Produzenten (zum Beispiel Workload-Ausführern, Edge-Diensten) und Verbrauchern (zum Beispiel anderen Edge-Diensten, Endpunktvorrichtungen).
Da Edge-Dienste in näherer Nähe von Endpunktvorrichtungen sein können als zentralisierte Server in Cloud-Umgebungen, ermöglichen Edge-Dienste Berechnungen von Workloads mit einer niedrigeren Latenz (zum Beispiel Reaktionszeit) als Cloud-Umgebungen. Edge-Dienste können auch eine lokalisierte Ausführung einer Workload basierend auf geografischen Standorten oder Netzwerktopographien ermöglichen. Eine Endpunktvorrichtung kann zum Beispiel erfordern, dass eine Workload in einer ersten geografischen Fläche ausgeführt wird, aber ein zentralisierter Server kann sich in einer zweiten geografischen Fläche befinden. Die Endpunktvorrichtung kann eine Workload-Ausführung durch einen Edge-Dienst anfordern, der sich in dem ersten geografischen Gebiet befindet, um Unternehmens- oder Vorschriftseinschränkungen zu erfüllen.
Beispiele für Workloads, die in einer Edge-Umgebung ausgeführt werden sollen, beinhalten autonome Fahrberechnungen, Videobeaufsichtigung, Maschinenlernmodellausführungen und Echtzeitdatenanalyse. Zusätzliche Beispiele für Workloads beinhalten Liefern und/oder Codieren von Medienströmen, Messen von Werbedruckraten, Objekterfassung in Medienströmen, Sprachanalyse, Asset- und/oder Inventarverwaltung und Verarbeitung erweiterter Realität.
Edge-Dienste ermöglichen sowohl die Ausführung von Workloads als auch ein Rücksenden eines Ergebnisses einer ausgeführten Workload zu Endpunktvorrichtungen mit einer Reaktionszeit, die niedriger als die Reaktionszeit eines Servers in einer Cloud-Umgebung ist. Falls sich zum Beispiel ein Edge-Dienst näher an einer Endpunktvorrichtung in einem Netzwerk befindet als ein Cloud-Server, kann der Edge-Dienst schneller als der Cloud-Server auf Workload-Ausführungsanfragen von dem Endgerät reagieren. Eine Endpunktvorrichtung kann eine Ausführung einer zeitbeschränkten Workload von einem Edge-Dienst an Stelle eines Cloud-Servers anfordern.
Zusätzlich ermöglichen Edge-Dienste die Verteilung und Dezentralisierung von Workload-Ausführungen. Eine Endpunkteinrichtung kann zum Beispiel eine erste Workload-Ausführung und eine zweite Workload-Ausführung anfordern. Bei einigen Beispielen kann ein Cloud-Server auf beide Workload-Ausführungsanfragen reagieren. Bei einer Edge-Umgebung kann jedoch ein erster Edge-Dienst die erste Workload-Ausführungsanforderung ausführen, und ein zweiter Edge-Dienst kann die zweite Workload-Ausführungsanforderung ausführen.
Zum Ausführen der Workloads greifen die Edge-Dienste und/oder Edge-Vorrichtungen auf Daten zu und verarbeiten sie. Wichtig ist, dass den Edge-Diensten und/oder Edge-Vorrichtungen die Herkunft oder Quelle der Daten bekannt ist und ob den Daten vertraut werden kann. Hierin offenbarte Beispiele erstellen genaue und sichere Datensammlungsprozesse durch Bereitstellen von Datenherkunft während des gesamten Workflow eines Edge-Dienstes von Vorrichtung zu Vorrichtung, während auf Daten und Mehrwertschaffung für diese Daten zugegriffen, verwendet, entwickelt und unter Vorrichtungen, Servern und/oder Netzwerken übertragen wird. Einzelheiten der Daten, einschließlich der Herkunft und Historie, werden in Datenversorgungsketten aufgezeichnet, einschließlich zum Beispiel in einer wachsenden Liste von Aufzeichnungen, wie etwa einer Blockchain.
Datenversorgungsketten entsprechen dem Lebenszyklus von Daten. Eine beispielhafte Datenversorgungskette für Mediendaten (auch Medien genannt) ist wie folgt. Wenn Medien angelegt werden, können die anfänglich angelegten Medien von einem Autor, Editor usw. zu verschiedenen Zeiten angepasst werden, bis endgültige Medien angelegt sind. Zum Beispiel kann ein Musiker eine Audiodatei anlegen und ein Soundtechniker kann die Audiodatei anpassen (zum Beispiel durch Mischen, Mastern und/oder anderswie Anpassen einer oder mehrerer Lautstärken, Audiospektren, Tonhöhen usw.), um eine endgültige Audiodatei anzulegen, die als ein Lied herausgegeben werden kann. Weiter können, sobald das Lied herausgegeben wird, Disk-Jockeys das Audio-Lied weiter anpassen, um neue Lieder anzulegen, mit anderer Musik zu mischen usw. Bei jeder Stufe wird das Audio angepasst und/oder manipuliert.
Datenlebenszyklen in Edge Computing-Umgebungen bewältigen mehrere Herausforderungen, einschließlich nichtlinearer Entwicklung von Autoren/Künstlern von Medien; verteilter Entwicklung; Integration mit Werkzeugen, die die Benutzerschnittstelle überbrücken und die Kreativität, Produktivität und Qualität verbessern; effizientes Handling von großen Datensätzen, Projekten und/oder Archiven; Integrität von Zwischen- und Endwerken; Authentizität von Zwischen- und Endwerken (zum Beispiel können Arbeiten mit ihrem rechtmäßigen Künstler assoziiert werden); Lizenzvergabe, Copyright, Nutzung und andere gesetzlich bindende Betrachtungen, die auf Daten, digitale Schöpfungen, digitale Darstellungen analoge Schöpfungen usw. angewandt werden können; Strategien zum Kombinieren, Zusammenführen, Modifizieren von Daten, Schöpfungen und/oder Arbeiten, wenn mehrere Änderungen für dieselben Daten, Schöpfungen oder Arbeit gelten; und/oder Führen einer historisch akkuraten Aufzeichnung von Änderungen an Daten oder Inferenzen, die aus Daten geschaffen wurden, ungeachtet der Änderung von Ökosystem-, Teilnehmer- und/oder Stakeholdern. Hierin offenbarte Beispiele integrieren Änderungssteuerverwaltungstechniken in Edge-Rechendienste und Edge-Daten-Pools, Edgeinformationszentrische Netzwerke (Information-Centric Networks - ICN) und Edge-Datenserialisierung für Video, Multimedia, strukturierte Daten, Metadaten, Softwareaktualisierungsdateien, Benutzerproduktivitätsdateien usw.
Hierin offenbarte Beispiele verknüpfen Daten (zum Beispiel Medien, Audio, Video, Text usw.) mit einem Datenversorgungskettenobjekt (Data Supply Chain - DSC-Objekt). Bei einigen hierin offenbarten Beispielen ist das DSC-Objekt eine Datenstruktur, die Entwicklung, Eigentum, Offenbarung und/oder Verwendung der Daten, mit denen das Objekt verknüpft ist, verfolgt. Ein hierin offenbartes beispielhaftes DSC-Objekt ermöglicht die Integration eines derartigen Verfolgens in einen offenen Ledger wie Blockchain und/oder einen beliebigen anderen verteilten Mechanismus. Bei einigen offenbarten Beispielen ermöglicht das DSC-Objekt eine deklarative Verwaltung von Übertragungen über Daten und Metadaten. Hierin offenbarte Beispiele beinhalten das Anlegen eines DSC-Objekts, das Änderungsverwaltungsmetadaten, die dem DSC-Datenobjekt entsprechen, anlegt und aktualisiert. Hierin offenbarte Beispiele beinhalten weiter das Verwenden einer Blockchain zum Verfolgen und/oder Aufzeichnen von Datenherkunft (zum Beispiel Eingaben, Entitäten, Systemen, Prozessen usw., die die mit dem DSC-Objekt verknüpften Daten beeinflussen), um einen Datenschutz durch eine Datenversorgungskette durchzusetzen und/oder zu prüfen. Eine Blockchain ist eine Liste von Aufzeichnungen (zum Beispiel Blöcken), die unter Verwenden von Kryptographie verknüpft sind, wobei jeder Block einen kryptografischen Hash des vorherigen Blocks, einen Zeitstempel und Transaktionsdaten (zum Beispiel Merkle-Baum) beinhalten kann. Ein Merkle-Baum ist ein Baum, der Blattknoten, die mit einem Hash eines Datenblocks gekennzeichnet sind, und Nicht-Blattknoten, die mit den kryptografischen Hash der Beschriftungen ihrer Kindknoten gekennzeichnet sind, beinhalten kann.
Hier offenbarte Beispiele beinhalten weiter das Aufbauen von Tools in ein DSC-Datenobjekt zum Managen von Änderungen und/oder Erforschen der Herkunft von Inferenzergebnissen, die aus Edge-Datenströmen genommen werden. Auf diese Weise kann, wenn die Medien von Vorrichtung zu Vorrichtung weitergegeben werden, jede Vorrichtung und/oder eine separate Objektüberkontrolldienstvorrichtung die Medien unter Verwenden der Werkzeuge manipulieren und/oder die Bauwerkzeuge erhalten, um die Historie der Daten zu analysieren. Hierin offenbarte Beispiele beinhalten weiter das Anwenden von Datenserialisierungsformaten, die kryptographische Operationen unterstützen, um den DSC-Objekten Sicherheit bereitzustellen. Hierin offenbarte Beispiele erlauben weiter die Ausführung von Daten-Mashups (zum Beispiel Datenzusammenführungen), die zu neuen Zusammensetzungen führen, die durch eine Datenversorgungskette verfolgt werden können.
Datenversorgungsketten antizipieren eine dynamische Anlegung von Mehrwert und/oder -erweiterung von Datenpools. Mashups, die mehrere Datenpools (zum Beispiel einen ersten und einen zweiten Datenpool) involvieren, können zum Beispiel in einem dritten Pool resultieren, der gemeinsam Eigentum eines ersten und eines zweiten Inhaltsanbieters ist und/oder von diesen gesteuert wird. Ein Mashup ist eine Kombination von zwei oder mehr Datenquellen in irgendeiner Weise. Zusätzlich dazu kann der Mashup-Algorithmus Eigentum einer vierten Entität sein und/oder von dieser gesteuert werden. Ein Mashup-Algorithmus ist die Art und Weise, wie die Datenquellen eines Mashup kombiniert werden. Die Datenquellen, die Dateneigentümer, die Inhaltsanbieter oder -schöpfer, die Algorithmusentwickler und/oder andere Entitäten mit einem Finanz-, Datenschutz- und/oder anderen Interesse an den Daten und/oder einem zu den Daten hinzugefügten Wert sind Stakeholder. Die Stakeholder in einer Datenlieferketteninteraktion wollen ihre Interessen durch herkunftserhaltende Instrumentierung darstellen und sichern. Herkunftsdaten beinhalten mindestens die Identität des Stakeholders und einen Anspruch auf den bereitgestellten Wert und/oder Eigentümerschaft und/oder Datenschutzrechte. Ein Anspruch kann eine Tag-Wertstruktur beinhalten, wobei das Tag den Typ des bereitgestellten Inhalts oder der bereitgestellten Transformation identifiziert. Der Wert beinhaltet einen spezifischen Verweis auf den enthaltenen Inhalt oder Algorithmus. Bei einigen hierin offenbarten Beispielen werden Herkunfts-Token digital durch den Schlüssel der Entität signiert, wobei der Schlüssel der Entität bei einer vertrauenswürdigen Gemeinschaftsverwaltungsorganisation oder Assoziation registriert ist. Bei einigen Beispielen ist der Schlüssel bei einem verteilten Ledger-System (Distributed Ledger System - DLS-System) registriert, das öffentlich oder halb öffentlich ist, so dass ein Konsensus von Prüfern in der Lage sein kann, Streitigkeiten im Zusammenhang mit Inhalt-Mashup-Ereignissen zu lösen.
Hierin offenbarte Beispiele ermöglichen auch eine selbstssouveräne digitale Identitätsauswahl, um es Stakeholdern zu ermöglichen, die Blockchain zu nutzen, um ihre eigenen Identitäten auf dezentrale Weise ohne Übersicht oder Erlaubnisanforderungen von einem zentralen Register anzulegen. Die Stakeholder können für eine dezentrale Herkunftsassertierung eine selbstsouveräne Identifikation auswählen und diese Identifikation und eine Tag-Wertstruktur zu einer Datenversorgungskette hinzufügen. Daher können die Stakeholder Kontext, beispielsweise in Form von Metadaten, zu Daten hinzufügen, um die Herkunft der Daten dezentral anzugeben.
8 veranschaulicht eine beispielhafte Systemarchitektur 800 einschließlich einer Gruppe von DSC-Vorrichtungen, die an einer Datenversorgungskette teilnehmen. Die beispielhafte Systemarchitektur 800 weist beispielhafte Endpunkt- oder Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, einen beispielhaften Objektmanager 812a bis e, ein beispielhaftes Netzwerk 814, beispielhafte Blockchain-Dienste 816 und einen beispielhaften Objektüberwachungsdienst 818 auf. Obwohl die beispielhafte Systemarchitektur 800 fünf Verarbeitungsvorrichtungen beinhaltet, könnte die Systemarchitektur 800 eine beliebige Anzahl von Verarbeitungsvorrichtungen beinhalten.
Die beispielhaften Verarbeitungsvorrichtungen 802, 804, 805, 808, 810 der 8 sind Computing-Vorrichtungen, die Daten (zum Beispiel eine Mediendatei) erzeugen, empfangen und/oder modifizieren. Die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 können Endbenutzervorrichtungen, intelligente Vorrichtungen, Edge-Vorrichtungen, Server und/oder eine beliebige andere Art von Computing-Vorrichtung sein. In dem Beispiel der 8 wirken die beispielhaften Verarbeitungsvorrichtungen 802 und 808 als DSC-Objektanlegungsvorrichtungen, die beispielhaften Verarbeitungsvorrichtungen 804 und 810 wirken als DSC-Objektverbrauchsvorrichtungen und die beispielhafte Verarbeitungsvorrichtung 806 wirkt als eine DSC-Objektsammelvorrichtung, wie unten weiter beschrieben. Eine beliebige der beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 kann jedoch als Anlegungsvorrichtungen, Verbrauchsvorrichtungen und/oder Aggregationsvorrichtungen arbeiten. Beispielsweise kann die beispielhafte Verarbeitungsvorrichtung 802 zu einem ersten Zeitpunkt als eine Anlegungsvorrichtung wirken und zu einem zweiten Zeitpunkt als eine Verbrauchs- und/oder Aggregationsvorrichtung wirken. Eine Anlegungsvorrichtung ist eine Vorrichtung, die mit einem DSC-Objekt verknüpfte Daten anlegt, eine Verbrauchsvorrichtung ist eine Vorrichtung, die mit einem DSC-Objekt verknüpfte Daten empfängt, modifiziert und/oder ansieht oder anderswie damit interagiert und/oder sie verbraucht, und eine Aggregationsvorrichtung ist eine Vorrichtung, die zwei oder mehr DSC-Objekte in ein einziges DSC-Objekt, das Daten von den zwei oder mehr DSC-Objekten beinhaltet aggregiert. Die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 können die Daten und/oder das entsprechende DSC-Objekt über das beispielhafte Netzwerk 814 zu anderen Vorrichtungen in dem System 800 übertragen. Somit können die Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 mehrere Rollen erfüllen und Daten durch das System 800 hindurch kaskadieren. Die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 beinhalten die beispielhaften Objektmanager 812a bis e.
Die beispielhaften Objektmanager 812a bis e der 8 sind Hardware und/oder Software (zum Beispiel eine Anwendung, ein Treiber usw.), die von den beispielhaften Verarbeitungsvorrichtungen 802bis 810 umgesetzt werden. Die beispielhaften Objektmanager 812a bis e erzeugen ein DSC-Objekt für erzeugte Daten und/oder modifizieren das DSC-Objekts, wenn auf die Daten zugegriffen wird, diese modifiziert, betrachtet, gelöscht usw. werden. Wenn zum Beispiel die Verarbeitungsvorrichtung 802 neue Daten erzeugt (zum Beispiel eine Edge-Vorrichtung, die neue Daten anlegt und/oder ein Benutzer, der Medien an der Verarbeitungsvorrichtung 802 anlegt), erzeugen die Objektmanager 812a bis e ein DSC-Objekt, das mit den neuen Daten verknüpft werden soll. Auf diese Weise überträgt der Objektmanager 812a der Übertragungsvorrichtung, wenn eine anfordernde Vorrichtung (zum Beispiel eine andere Verarbeitungsvorrichtung 804 bis 810) die Daten mit dem entsprechenden DSC-Objekt anfordert (zum Beispiel über eine verdrahtete oder drahtlose Verbindung). Wenn die anfordernde Vorrichtung auf die empfangenen Daten zugreift, diese bearbeitet usw., aktualisiert die anfordernde Vorrichtung das entsprechende DSC-Objekt, um den Zugriff, die Bearbeitungen usw. widerzuspiegeln. Bei dem veranschaulichten Beispiel beinhaltet das DSC-Objekt, das von einem oder mehreren der Manager 812a bis e angelegt wird, einen lokalen Merkle-Baum, lokale Datenobjekte (zum Beispiel Arbeitsdateien, die den Daten entsprechen), Objektmetadaten, ein Revisions-Protokoll und ein lokales Commit-Log, wie unten in Verbindung mit 3A weiter beschrieben. Das DSC-Objekt dient als Aufzeichnung der Verwendung und/oder Modifikation der Daten während seines Lebenszyklus. Wenn bei dem veranschaulichten Beispiel die Verarbeitungsvorrichtung 804 mit einem DSC-Objekt verknüpfte Daten erhält (zum Beispiel zum Betrachten der Daten und/oder zum Modifizieren der Daten), modifizieren die Objektmanager 812a bis e bei dem veranschaulichten Beispiel das verknüpfte DSC-Objekt entsprechend den ausgeführten Handlungen (zum Beispiel zum Betrachten, Modifizieren usw.) an den Daten. Zum Beispiel können die Objektgeneratormanager 812a bis e das DSC-Objekt modifizieren, um Ansichten der entsprechenden Daten für digitale Rechtsverwaltungszwecke zu verfolgen (zum Beispiel Verfolgen und/oder Bezahlen von verbrauchten und aufgezeichneten Daten). Bei einigen Beispielen können die Objektmanager 812a bis e ein oder mehrere DSC-Objekte zu einem neuen DSC-Objekt aggregieren, das Informationen des einen oder der mehreren DSC-Objekte kombiniert. Zum Beispiel kann die Verarbeitungsvorrichtung 806 ein erstes DSC-Objekt (das Objekt A in 8 entspricht), das mit ersten Daten assoziiert ist, von der beispielhaften Verarbeitungsvorrichtung 804 (zum Beispiel über das Netzwerk 814) empfangen und ein zweites DSC-Objekt (das Objekt B in 8 entspricht), das mit zweiten Daten assoziiert ist, von der beispielhaften Verarbeitungsvorrichtung 808 (zum Beispiel über das Netzwerk 814) empfangen. Bei einem derartigen Beispiel kann der Objektmanager 812c der beispielhaften Verarbeitungsvorrichtung 806 Informationen von Objekt A und/oder einigen oder allen der ersten Daten und/oder Objekt B und/oder einigen oder allen der zweiten Daten aggregieren (zum Beispiel kombinieren), um ein drittes DSC-Objekt (das Objekt C in 8 entspricht) zu erzeugen. Auf diese Weise wird Objekt A mit den ersten Daten verknüpft, Objekt B mit den zweiten Daten verknüpft und Objekt C wird (was zum Beispiel einer Generationsabhängigkeit entspricht) mit dritten Daten verknüpft, die einer Kombination/Aggregation der ersten und zweiten Daten entsprechen. Beispielsweise verbindet das Delta zwischen Objekt A und Objekt C die beiden Objekte. Bei einigen Beispielen kann Objekt A verschwinden, sobald Objekt B instanziiert ist. Es verbleiben jedoch ein Protokoll, eine Historie, Metadaten usw., die für die Existenz von Objekt A bürgen. Bei einigen Beispielen kann eine erste Version eines Datums in einem DSC (Objekt C1) mit mehreren anderen DSC-Objekten gemeinsam genutzt und/oder kloniert werden, die Änderungen an C1 vornehmen (Objekt C1', C1'', C1''' usw.). Bei derartigen Beispielen werden die Änderungen zurück zu C1 zusammengeführt, um C2 zu erzeugen, das einer Summe oder einem Aggregat der Änderungen entspricht. Bei einigen Beispielen legen einer oder mehrere der Objektmanager 812a bis e eine vertrauenswürdige Schichtkomponente (zum Beispiel einen Vertrauensanker) an, um einen modularen portablen Datenpool zu instanziieren. Auf diese Weise kann ein DSC-Objekt gesichert werden. Zum Beispiel kann das DSC-Objekt unter portable Datenpoolsteuerung gesetzt werden, das DSC-Objekt kann verschlüsselt und/oder zu einem Peer-Knoten unter Verwenden eines Attestierungsprotokolls attestiert werden. Der beispielhafte Objektmanager 812a ist unten in Verbindung mit 9 weiter beschrieben.
Das beispielhafte Netzwerk 814 der 8 ist ein System von miteinander verbundenen Systemen, die Daten austauschen. Das beispielhafte Netzwerk 814 kann unter Verwenden einer beliebigen Art von öffentlichem oder privatem Netzwerk umgesetzt werden, wie etwa unter anderem das Internet, ein Telefonnetzwerk, ein lokales Netzwerk (LAN), ein Kabelnetzwerk, ein Cloud-basiertes Netzwerk, ein Edge-Netzwerk, ein verdrahtetes Netzwerk, ein drahtloses Netzwerk und/oder ein beliebiges anderes hierin offenbartes Netzwerk. Um eine Kommunikation über das Netzwerk 814 zu ermöglichen, können die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 eine Kommunikationsschnittstelle beinhalten, die eine Verbindung zu einem Ethernet, einer digitalen Teilnehmerleitung (Digital Subscriber Line - DSL), einer Telefonleitung, einem Koaxialkabel, einer verdrahteten Verbindung, einer drahtlosen Verbindung usw. oder einer beliebigen Kombination davon ermöglicht.
Die beispielhafte Blockchain 816 der 8 ist ein dezentralisiertes Objektänderungsverwaltungsnetzwerk, das eine Datenherkunft für Daten durchsetzt, die mit DSC-Objekten verknüpft sind, wenn die Daten verbraucht und/oder modifiziert werden. Die beispielhafte Blockchain 816 der 8 verwendet intelligente Verträge (zum Beispiel ein Protokoll zum digitalen Erleichtern, Verifizieren und/oder Durchsetzen eines Vertrags, der Daten entspricht, die mit DSC-Objekten verknüpft sind). Andere Protokolle können jedoch verwendet werden, um Verträge durchzusetzen und/oder anderswie die Lebensdauer von Daten, die mit DSC-Objekten verknüpft sind, zu verwalten. Die beispielhafte Blockchain 816 zeichnet Revisionen von Daten, die mit DSC-Objekten verknüpft sind, in einem lokalen Protokoll als den Startpunkt einer nächsten Entwicklung der Daten und/oder eines entsprechenden DSC-Objekts auf, die anschließend angewandt werden können. Falls die Verarbeitungsvorrichtung 802 zum Beispiel Daten erzeugt, die mit einem neuen DSC-Objekt verknüpft sind, und die Verarbeitungsvorrichtung 802 eine Verbindung zu dem beispielhaften Netzwerk 814 herstellt, können die beispielhaften Blockchain-Miners der Blockchain 816 das Vorhandensein des DSC-Objekts erkennen und unter Verwenden eines verteilten Konsensusalgorithmus im Zusammenhang mit dem DSC-Objektnamen, lokalen Datenobjekten, Objektmetadaten, Revisionen und einer Commit-Datei übereinstimmen. Das DSC-Objekt kann mit (einem) kryptographischen Schlüssel(n) assoziiert sein, die Integrität, Vertraulichkeit und das DSC-Objekt, das sich in dem System 800 identifiziert, schützen. Falls die Daten, die mit einem DSC-Objekt verknüpft sind, einer Verwaltung digitaler Rechte entsprechen, zeichnet bei einigen Beispielen die beispielhafte Blockchain 816, Betrachten und/oder Modifizieren der Daten und/oder Zahlung für Datenverbrauch auf. Bei einigen Beispielen gibt die Blockchain 816 Zertifikate an die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 aus, um Proxy-Identitäten zu erzeugen.
Der beispielhafte Objektkontrolldienst 818 der 8 ist eine zentralisierte Objektänderungsverwaltungsvorrichtung (zum Beispiel ein oder mehrere Server, Prozessoren usw.), die Datenherkunft und Integrität für Daten und/oder die zugrundeliegende Infrastruktur, die mit DSC-Objekten verknüpft ist, verfolgt, überwacht und/oder durchsetzt, wenn die Daten auf eine ähnliche Weise wie die Blockchain 816 verbraucht und/oder modifiziert werden. Der beispielhafte Objektüberkontrolldienst 818 zeichnet Revisionen an Daten, die mit DSC-Objekten verknüpft sind, in einem lokalen Protokoll als den Startpunkt einer nächsten Entwicklung der Daten und/oder eines entsprechenden DSC-Objekts auf, die anschließend angewandt werden können. Falls die Verarbeitungsvorrichtung 802 zum Beispiel Daten erzeugt, die mit einem neuen DSC-Objekt verknüpft sind, und die Verarbeitungsvorrichtung 802 eine Verbindung zu dem beispielhaften Netzwerk 814 herstellt, kann der Objektkontrolldienst 818 das Vorhandensein des DSC-Objekts erkennen und unter Verwenden eines verteilten Konsensusalgorithmus im Zusammenhang mit dem DSC-Objektnamen, lokalen Datenobjekten, Objektmetadaten, Revisionen und einer Commit-Datei vereinbaren. Das DSC-Objekt kann mit (einem) kryptographischen Schlüssel(n) assoziiert sein, die Integrität, Vertraulichkeit und das DSC-Objekt, das sich in dem System 800 identifiziert, schützen. Falls die mit einem DSC-Objekt verknüpften Daten bei einigen Beispielen einer Verwaltung digitaler Rechte entsprechen, kann der Objektüberwachungsdienst 818 Betrachten und/oder Modifizieren der Daten und/oder Zahlung für Datenverbrauch aufzeichnen. Bei einigen Beispielen gibt der Objektüberwachungsdienst 818 Zertifikate an die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 aus, um Proxy-Identitäten zu erzeugen. Zusätzlich kann der beispielhafte Objektüberwachungsdienst 818 Aktualisierungen an der Blockchain 816 überwachen. Der Objektüberwachungsdienst 818 kann zum Beispiel eine faire Verwendung, lizenzierte und/oder unlizenzierte Verwendung von Medien, die in geeigneten Kompensationstransaktionen resultiert (zum Beispiel Berichten einer fairen Verwendung, Sammeln von Lizenziergebühren für eine lizenzierte Verwendung und/oder Benachrichtigen einer Rechtsdurchsetzung für eine unlizenzierte Verwendung) identifizieren. Zusätzlich oder alternativ dazu kann der Objektüberwachungsserver 818 einen Unternehmensrisikomanagement-Workflow (ERM-Workflow) einsetzen, um Zugriff auf empfindlichen Inhalt unter Verwenden eines Zugriffssteuerdienstes (zum Beispiel Open Authorization (OAuth2), Security Assertion Markup Language (SAML), eXtensible Access Control Markup Language (XACML), Radius usw.) zu steuern. Obwohl die beispielhafte Systemarchitektur 800 eine beispielhafte Blockchain 816 und einen beispielhaften Objektüberwachungsdienst 818 zum Verfolgen von Daten und eines entsprechenden DSC-Objekts beinhaltet, beinhaltet die beispielhafte Systemarchitektur 800 möglicherweise nur eines der Blockchain 816 oder des Objektüberwachungsdiensts 818 zum Verfolgen von Daten und entsprechenden DSC-Objekten. Weiter können, wie hier offenbart, die Stakeholder (die Verarbeitungsvorrichtungen 802, 804, 806, 808, 810) ihre Identitäten auf eine dezentrale Weise assertieren, ohne den Objektüberwachungsdienst 818 einzusetzen.
9 ist ein Blockdiagramm einer beispielhaften Umsetzung des Objektmanagers 812a der 8. Der beispielhafte Objektmanager 812a der 9 kann verwendet werden, um einen oder mehrere der Objektmanager 812a bis e der 8 umzusetzen. Der beispielhafte Objektmanager 812a der 9 beinhaltet eine beispielhafte Bauelementschnittstelle 900, eine beispielhafte Netzwerkschnittstelle 902, ein beispielhaftes Filter 904, einen beispielhaften Dateiprozessor 906, einen beispielhaften Verschlüsseler 908, einen beispielhaften Datenstrukturgenerator 910, einen beispielhaften Proxy-Generator 912, einen beispielhaften Codierer 916, einen beispielhaften Schlüsselgenerator 918, einen beispielhaften Objektaggregator 920, einen beispielhaften Vertrauensankergenerator 922, einen beispielhaften Objektprozessor 924 und einen beispielhaften Entschlüsseler 926.
Die beispielhafte Bauelementschnittstelle 900 der 9 bildet eine Schnittstelle mit Bauelementen der beispielhaften Verarbeitungsvorrichtung 802, 804, 806, 808, 810, um Daten zu erhalten, die in der beispielhaften Verarbeitungsvorrichtung 802, 804, 806, 808, 810 gespeichert, empfangen und/oder von dieser verwendet werden. Zum Beispiel kann die Bauelementschnittstelle 900 auf Dateien (zum Beispiel Medien und/oder Daten, die erzeugt, empfangen, betrachtet usw. wurden), Daten, die den Dateien entsprechen, Metadaten, Zertifikate, Vertrauensankern usw. zugreifen und/oder diese modifizieren. Bei einigen Beispielen bildet die Bauelementschnittstelle 900 mit Bauelementen anderer der Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 eine Schnittstelle, um Daten zu erhalten, die in den anderen Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 gespeichert, empfangen und/oder von diesen verwendet werden.
Die beispielhafte Netzwerkschnittstelle 902 der 9 greift auf das beispielhafte Netzwerk 814 zu, um DSC-Datenobjekte zu einer beliebigen der beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, der beispielhaften Blockchain 816 und/oder dem beispielhaften Objektüberwachungsdienst 818 zu übertragen (zum Beispiel über eine verdrahtete oder drahtlose Verbindung). Zusätzlich kann die beispielhafte Netzwerkschnittstelle 902 Digest-Werte, Attestierungsanforderungen, signierte Daten, Voucher, Zertifikate, Metadaten und/oder andere Daten von/zu einer beliebigen der beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, der beispielhaften Blockchain 816 und/oder dem beispielhaften Objektüberwachungsdienst 818 empfangen/übertragen. Bei einigen Beispielen sendet die Netzwerkschnittstelle 902 das DSC-Objekt für andere Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 und/oder den Objektüberwachungsdienst 818 aus, um mit der Semantik der Metadaten einschließlich der Stakeholder-Identität und der Wert-Tagstruktur übereinzustimmen.
Das beispielhafte Filter 904 der 9 filtert erhaltene Daten (zum Beispiel Medien, Dateien usw.). Falls der Objektmanager 812a zum Beispiel in einer loT-Vorrichtung umgesetzt wird, können die erhaltenen Daten ein hohes Volumen an maschinenerzeugten Daten und/oder Daten sein, die dem Maschinenbetrieb (zum Beispiel Leistungsfähigkeit, Zuverlässigkeit, Leistung, Rauschtelemetrie usw.) entsprechen. Dementsprechend kann das beispielhafte Filter 904 die hohe Menge an erhaltenen Daten in einen Bruchteil der Daten filtern, die für eine Langzeitverwendung beibehalten werden. Bei einem derartigen Beispiel kann der verbleibende Anteil für eine kurze Dauer für eine beliebige Problemerkundung oder Qualifikation gespeichert werden, bevor er verworfen wird. Das beispielhafte Filter 904 kann die erhaltenen Daten basierend auf Benutzer- und/oder Herstellerpräferenz darüber, wie gefiltert werden soll und/oder wie viel gefiltert werden soll, filtern.
Der beispielhafte Dateiprozessor 906 der 9 verarbeitet empfangene Datendateien, um Informationen, die der Datei entsprechen, für Zwecke der DSC-Objektanlegung zu identifizieren. Zum Beispiel kann der Dateiprozessor 906 bestimmen, ob die Datendatei sensible Daten beinhaltet (zum Beispiel falls die Daten als sensibel markiert wurden), ob das DSC-Objekt unter Verwenden einer selbstsouveränen Identität (SSI) gesteuert wird, ob eine Datei einem bestimmten Format oder einer bestimmten Struktur entspricht, die Art der zu verwendenden Verschlüsselung, ob die Daten auf (einer) bestimmte(n) Vorrichtung(en) basierend auf Benutzer- und/oder Herstellerpräferenzen eingeschränkt sein sollten, usw.
SSI ist ein Identitätsmanagmentsystem, bei dem der Benutzer die Elemente verwaltet, die die Identität bilden, und den Zugang zu den Berechtigungsnachweisen digital steuert. Ein Objekt kann anhand von Nutzer- und/oder Herstellerpräferenzen unter Verwenden einer selbstsouveränen Identität gesteuert werden. Selbstsouveräne Ansätze, wie beispielsweise W3C dezentralisierte ID (DID), erlauben es Stakeholdern, wie beispielsweise den Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, Identität bei anderen Stakeholdern zu assertieren und nachzuweisen und Vertrauen in Speicherressourcen und/oder Datenpools aufzubauen. Selbstsouveräne Ressourcenkennungen können der DID-Spezifikation folgen, können aber Datenressourcen an Stelle von Menschen oder Organisationen beschreiben. Namensdaten-Networking (NDN) und informationszentrisches Networking (ICN) können von selbstsouveränen Ressourcenidentitäten profitieren, bei denen Daten-Caches auf Datenbenennung und Metadatenbeschreibungen von Daten angewiesen sind. Ein selbstsouveräner Datenname erlaubt es einem Verbraucher festzustellen, welcher Datenpool der berechtigte Eigentümer des Namens (der selbstsouveränen Identität) gegenüber möglichen Betrügern ist. Bei hierin offenbarten Beispielen setzen die Edge-Architekturen ein dezentralisiertes und chaotisches Ökosystem von Stakeholdern um, die ohne überwachende Übersicht in das Ökosystem eintreten und daraus austreten. Der Wertaustausch basiert auf Vertrauen, und in einer dezentralen oder chaotischen Umgebung wird Vertrauen von jedem Stakeholder direkt aufgebaut. Bei der dezentralen Umsetzung verlässt man sich nicht auf eine Vermutung einer vertrauenswürdigen Drittpartei, die allen Stakeholdern gemeinsam ist.
Der beispielhafte Verschlüsseler 908 der 9 verschlüsselt ein DSC-Objekt. Bei einigen Beispielen führt der Verschlüsseler 908 eine homomorphe Verschlüsselung aus. Homografische Verschlüsselung ist eine Form oder Verschlüsselung, die eine Berechnung auf verschlüsselten Chiffretextdaten erlaubt, um ein verschlüsseltes Ergebnis zu erzeugen, das, wenn es entschlüsselt wird, mit dem Ergebnis der Operationen übereinstimmt, als ob sie an den unverschlüsselten Klartextdaten ausgeführt worden wären. Zum Beispiel kann additive homomorphe Verschlüsselung in Verbindung mit Datenschutzzählern verwendet werden, die für Verfolgungszwecke (um zum Beispiel Zugriffe auf Daten zu verfolgen, während die Werte der Daten geschützt werden) verwendet werden. Der beispielhafte Verschlüsseler 908 kann auch homomorphe Verschlüsselung beim Aggregieren von DSC-Objekten ohne Offenbarung des Inhalts zu der Entität, die die Aggregation ausführt, nutzen Zusätzlich oder alternativ kann der beispielhafte Verschlüsseler 908 ein DSC-Objekt unter Verwenden von Datenschutzschlüsseln verschlüsseln. Zum Beispiel kann der Verschlüsseler 908 ein Herkunfts-Token mit einem Entitätsschlüssel signieren. Bei einigen Beispielen kann der Verschlüsseler 908 auch ein DSC-Objekt mit einem Archivklassenschlüssel verschlüsseln, der auf einem Festplattenlaufwerk (HDD), einem Festkörperlaufwerk (SSD), einem Band usw. der Verarbeitungsvorrichtung gespeichert ist. Zusätzlich oder alternativ kann der beispielhafte Verschlüsseler 908 ein DSC-Objekt mit einem speicherinternen Verschlüsselungsschlüssel (zum Beispiel Multi-Key Total Memory Encryption, MKTME), INTEL™-Softwareschutzerweiterung (SGX) verschlüsseln, Vertrauenswürdige Domainerweiterungen (INTEL™ Trusted Domain Extensions - TFC) oder mit einem benutzereigenen Schlüssel unter Verwenden von INTEL™-Schnellassistenztechnologie (INTEL™ Quick Assistent Technology - QAT), INTEL™-Schlüsselschutztechnologie (INTEL™ Key Protection Technology - KPT) und/oder einer anderen Form eines Kryptographiebeschleunigers oder Schlüsselmanagers. Zusätzlich oder alternativ kann Integritätsschutz mit einem Message-Authentication-Coding-Schlüssel (MACing-Schlüssel) zur Speicherung im Speicher oder Isolierung in einer sicheren Ausführungsumgebung (zum Beispiel Vertrauensanker, Hypervisor einer virtuellen Maschine, Enklave, Coprozessor, FPGA-Design, Grafikprozessor, Mikrocontroller, Peripherievorrichtung usw.) ausgeführt werden. Bei einigen Beispielen kann der Verschlüsseler 208 lokale Datenobjekte hashen und/oder einen kryptografischen Hash von Labeln des lokalen Datenobjekts erzeugen. Ein lokales Datenobjekt ist eine Einheit von Daten (zum Beispiel ein Datenblock, ein Blob, eine Datei, ein Segment, eine Transaktionsaufzeichnung usw.), die einer neuen Datei entspricht.
Der beispielhafte Datenstrukturgenerator 910 der 9 erzeugt das DSC-Datenobjekt. Wenn zum Beispiel eine neue Datei erzeugt wird, erzeugt der beispielhafte Datenstrukturgenerator 910 ein lokales Datenobjekt und Objektmetadaten, die der neuen Datei entsprechen. Das lokale Datenobjekt entspricht den der Datei entsprechenden Arbeitsdateien. Das lokale Datenobjekt kann Dateiversionsnummern, Gewährungen des Zugriffs auf die Datei, Aufzeichnungen des Zugriffs auf die Datei und Revisionen, die an beiden ausgeführt werden, beinhalten. Bei einigen Beispielen entsprechen die Objektmetadaten der Herkunfts-Assertion. Bei derartigen Beispielen beinhalten die Objektmetadaten Metadaten, die einen Wert angeben, der zu den Daten hinzugefügt wird und/oder die Stakeholder-Identifikation angeben. Der Datenstrukturgenerator 910 fügt Tag-Wertstruktur und Stakeholder-Identität hinzu, um das Herkunfts-Token oder DSC-Datenobjekt aufzubauen. Bei einigen Beispielen fügt der Datenstrukturgenerator 910 das Herkunfts-Token zu der Blockchain hinzu. Zusätzlich dazu erzeugt der beispielhafte Datenstrukturgenerator 910 eine hierarchische Datenstruktur (zum Beispiel lokaler Merkle-Baum) für eine neue Datei, die einem Hash des lokalen Datenobjekts als einen Blattknoten und einem kryptographischen Hash der Ebene des lokalen Datenobjekts als die Zwischenknoten der hierarchischen Datenstruktur entspricht. Bei einigen Beispielen kann der Datenstrukturgenerator 910 ein lokales Commit-Log erzeugen, um Versionen für die neue Datei zu verfolgen. Wenn die Datei aktualisiert wird, kann der beispielhafte Datenstrukturgenerator 910 das lokale Commit-Log aktualisieren, um die unterschiedlichen Versionen der neuen Datei, die erzeugt wurden, zu identifizieren. Bei einigen Beispielen erzeugt der Datenstrukturgenerator 910 ein Revision(en)-Protokoll, um die Revision(en) der neuen Datei zu verfolgen. Wenn die Datei aktualisiert wird, kann der beispielhafte Datenstrukturgenerator 910 das Revisionsprotokoll aktualisieren, um die Revisionen, die auf der neuen Datei ausgeführt wurden, zu identifizieren. Bei einigen Beispielen packt der Datenstrukturgenerator 910 die hierarchische Datenstruktur, lokale Datenobjekte, Objektmetadaten, das Revisionsprotokoll und/oder lokale Commit-Log in ein lokales DSC-Objekt, das mit der neuen Datei verknüpft werden kann. Bei einigen Beispielen kann der Datenstrukturgenerator 910 Werkzeuge in dem DSC-Objekt zum Zugreifen auf und/oder Manipulieren der mit dem DSC-Objekt verknüpften Datendatei oder des DSC-Objekts selbst beinhalten.
Der beispielhafte Proxy-Generator 912 der 9 stellt eine Proxy-Identität unter Verwenden eines Zertifikats für eine selbstsouveräne Identität her, wodurch erlaubt wird, dass Individuen und/oder Entitäten Eigentum ihrer Kennungen und Kontrolle darüber haben, wie ihre Daten gemeinsam genutzt und/oder verwendet werden. Auf diese Weise kann der Identitätseigentümer nur die notwendigen Daten für eine beliebige Transaktion oder Interaktion offenbaren. Ein Blockchain-Teilnehmer kann die Zertifikate bereitstellen, die der beispielhafte Proxy-Generator 912 verwendet, um die Proxy-Identität zu ermitteln. Die Proxy-Identität, die mit dem Zertifikat gesichert ist, kann Elemente schützen, die für Zugriffsrechte identifiziert und nicht verdeckt sind, die den geschützten Elementen entsprechen (zum Beispiel eine digitale Kennung, die den Zugriff auf die eigenen medizinischen Aufzeichnungen offenbart und autorisiert, oder medizinische Aufzeichnungen, die mit Proxy-Identitäten assoziiert sind, die als Patienten unter Betreuung registriert sind). DSC-Objekte mit selbstsouveräner Identität zum Identifizieren der in sich geschlossenen DSC-Objekte bedeutet, dass das Objekt auch selbstsouverän ist.
Der Proxy-Generator 912 wählt die selbstsouveräne Identifikation (ID) aus und setzt die selbstsouveräne ID als Stakeholder-Identität zum Einbau in das Herkunfts-Token. Die selbstsouveräne ID hat kein spezifisches Format oder Standard zur Formatierung. Es kann jede Art von Nomenklatur verwendet werden. Der Schöpfer der selbstsouveränen ID kann einen eigenen Stil oder eigene Formatierung auswählen und muss nicht Englisch benutzen oder verstehen. Allerdings gibt es bei einigen Beispielen einige Standards zur Auswahl von Kennungen. Die Verwendung selbstsouveräner ID erleichtert eine dynamische Evolution der Metadaten.
Bei einigen Beispielen bestimmt der Proxy-Generator 912, ob ein Konflikt mit einer Stakeholder-Identität besteht. Falls zum Beispiel zwei Stakeholder versuchen, die gleiche selbstsouveräne ID zu verwenden, bestimmt der Proxy-Generator 912, welcher Stakeholder Priorität hat. Zum Beispiel kann der Proxy-Generator 912 Zeitstempel (UTC-Zeitstempel) koordinierte Weltzeit vergleichen, wann eine selbstsouveräne ID beansprucht wurde, um zu bestimmen, welcher Stakeholder den Anspruch zuerst gemacht hat. Falls der Proxy-Generator 912 bestimmt, dass die Verarbeitungsvorrichtung 812a, in die er integriert ist, keine Priorität gegenüber einer selbstsouveränen ID hat, wählt der Proxy-Generator 912 eine andere selbstsouveräne ID aus.
Der beispielhafte Codierer 916 der 9 codiert das DSC-Objekt. Datendateien entsprechen unterschiedlichen Datencodierformaten. Audiodateien sind zum Beispiel als MP3, M4A usw. codiert. Falls die Datendatei einem speziellen Codierungsformat entspricht, codiert der beispielhafte Codierer 916 dementsprechend das DSC-Objekt, um mit der Codierung der Datei übereinzustimmen. Der beispielhafte Verschlüsseler 908 kann weiter inhaltsspezifische Codierungen (zum Beispiel unter Verwenden kryptographischer Serialisierung) zur sicheren Übermittlung zwischen Verarbeitungsvorrichtungen (zum Beispiel unter Verwenden von COSE-, JOSE-, CMW-, CML-Signierung usw.) serialisieren. Bei einigen Beispielen kann der Codierer 916 einige Daten zur sicheren Verteilung codieren. Zum Beispiel kann der beispielhafte Codierer 916 Datenmanipulationssprache (zum Beispiel CDDL, JSON, XML, CBOR, ASN.1) verwenden, um Interoperabilität zu erlauben, weil die Serialisierungstechnik sowohl Codierern als auch Decodern bekannt ist.
Der beispielhafte Schlüsselgenerator 918 der 9 erzeugt Voucher und/oder Datenspeicherungsschlüssel. Der Schlüsselgenerator 918 kann zum Beispiel einen Voucher zum Einschränken des Zugriffs auf eine Datei für bestimmte Vorrichtungen erzeugen. Der Schlüsselgenerator 918 erzeugt einen Voucher, um den öffentlichen Schlüssel und/oder Vertrauensanker einer anderen Vorrichtung in der Systemarchitektur 800 der 8 aufzunehmen. Der Voucher legt fest, welche Peer-Knoten berechtigt sind, das DSC-Objekt in ihre Speichersysteme zu importieren. Der Schlüsselgenerator 918 kann die Voucher derart erzeugen, dass sie auch einen Schlüsselumhüllungsschlüssel (zum Beispiel öffentliche RSA-Schlüssel für vertrauenswürdige Entitäten) beinhalten. Voucher können einen Sicherheitslink zu einem PDP und/oder einem anderen zugehörigen Datenobjekt aufweisen. Ein DSC-Objekt kann zum Beispiel Edge-Hosting-Ressourcen identifizieren, in denen Daten physisch lokalisiert, repliziert, zwischengespeichert usw. sind. Jede Bewegung, Referenzzählinkrementierung/-dekrementierung und/oder Zugriffsgewährung kann von dem Vertrauensanker, der den Voucher interpretiert, torgesteuert werden. Bei einigen Beispielen kann der Schlüsselgenerator 918 Datenspeicherungsschlüssel erzeugen, die zum Authentifizieren und/oder Attestieren eines Datenpools verwendet werden.
Der beispielhafte Objektaggregator 920 der 9 aktualisiert die Datenversorgungskette. Zum Beispiel aggregiert der Objektaggregator 920 Daten von zwei oder mehr DSC-Objekten zu einem neuen DSC-Objekt, das den zwei DSC-Objekten entspricht. Der Objektaggregator 920 kann auch beliebige Daten erzeugen und signieren (zum Beispiel zum Verfolgen und/oder Auditieren), die von Kinder-Subbäumen unter einem DSC-Objekt abgeleitet sind. Derartige Daten können Informationen beinhalten, die verwendet werden können, um einen Satz von Transformationen wiederherzustellen, den Satz von Transformationen anzuwenden und/oder das Nettoergebnis der Transformationen zu verifizieren, um ein verifizierbares Ergebnis über die Daten zu erzeugen. Beispielsweise kann ein Bauelement des Systems 800 die betriebliche Abstimmung einer Datendatei, mit der die Transformationen der Datei ausgeführt wurden, einen Zeitstempel und Signaturen über die Zwischendaten aufzeichnen. Bei einem derartigen Beispiel können die Zwischendaten wiederhergestellt werden, obwohl die Zwischendaten vorübergehend sein und verloren gehen können, indem die Dokumenttransformationen ausgeführt und gegen die Signaturen verifiziert werden. Dies erlaubt es dem beispielhaften Objektaggregator 920, größeres Vertrauen in die Robustheit der Datenversorgungskette zu debuggen, zu inspizieren und/oder zu erzeugen. Wenn ein DSC-Objekt aktualisiert wird, fügt der beispielhafte Objektaggregator 920 einen Knoten zu dem Blatt eines Merkle-Baums, der Änderungen in der Datei entspricht, hinzu. Dementsprechend aktualisiert sich der Merkle-Baum mit jedem Zugriff, jeder Bearbeitung usw. auf die Daten, die dem DSC-Objekt entsprechen.
Beim Aggregieren von Daten von zwei DSC-Objekten kann der beispielhafte Objektaggregator 920 der 9 entsprechende Knoten zu dem Merkle-Baum hinzufügen, so dass der neue Merkle-Baum Knoten beinhaltet, die den Knoten der zwei DSC-Objekte, die aggregiert wurden, entsprechen. Falls zum Beispiel die Medien C1 und C2 Eingaben in ein DSC-Objekt sind, bei dem eine Matrixmultiplikation auf jedes Byte der Medien angewandt wird, würde der Objektaggregator 920 ein Protokoll/eine Historie erzeugen, das C1 und C2 identifiziert (zum Beispiel durch Erhalten einer SSI, durch Berechnen einer Zusammenfassung über ein Label, das C1 identifiziert, oder durch direktes Berechnen einer Zusammenfassung über die C1-Medien). Metadaten über die C1 und C2 können ihre Geolokalisierung beinhalten, die Urheberrechtsinhaberschaft usw. aufweist. Ein drittes Medium C3, das die Matrixmultiplikationstransformation über C1 und C2 anwendet, kann erzeugt werden. Die Metadaten für C2 können die Transformationsfunktion, die verwendet wurde, den Ort, an dem die Funktion verwendet wurde usw. beschreiben. Wenn eine Transformation angewandt wird, erzeugt der Aggregator 920 und/oder der beispielhafte Datenstrukturgenerator 910 eine Revision. Das resultierende Medienrevisionsobjekt für C3 wird gehasht (zum Beispiel unter Verwenden des Verschlüsselers 908), um einen Wert zu erzeugen, der in dem Merkle-Baum enthalten ist. Bei einigen Beispielen kann es zweckmäßig sein, mehrere Revisionen von C2 zuzulassen, bevor ein Endergebnis erzeugt und zu dem lokalen Merkle-Baum hinzugefügt wird, um zu erlauben, dass kreative oder zufällige Änderungen auftreten, ohne übermäßige Einträge in dem Merkle-Baum zu erzeugen. Der Merkle-Baum zeichnet Workflow-Schritte auf, die lokal angewandt werden (zum Beispiel empfangene Medien C1, empfangene Medien C2, angewandte Transformationsfunktion F1, angewandte Transformationsfunktion F2, erzeugte Medien C3 usw.). Der Verschlüsseler 908 hasht die Wurzel des Merkle-Baums, um einen Wert zu erzeugen, der für den aktuellen Zustand der DSC zu der aktuellen Zeit repräsentativ ist. Teilbaumknoten repräsentieren den Zustand zu einem früheren Zeitpunkt. Durch Hinzufügen einer lokalen Merkle-Baumwurzel zu der Blockchain ist es möglich, die Zustandsänderungen über mehrere DSC-Objekte hinweg zu serialisieren. Teilbäume lokaler Objekte können parallel auftreten. Somit ist eine Serialisierung von Teilbaumrevisionen möglicherweise nicht ohne Weiteres erreichbar. Revisionsdaten können jedoch einen sicheren Zeitstempel beinhalten, falls dieses Serialisierungsniveau benötigt wird.
Der beispielhafte Vertrauensankergenerators 922 führt Hardwareattestierung auf der Verarbeitungsvorrichtung aus, um eine sichere Ausführungsumgebung zum Erzeugen und/oder Modifizieren eines DSC-Objekts und Ableiten von Sicherheitsdeskriptoren und Herkunft von einem DSC-Objekt zu entwickeln. Beispielsweise kann der Vertrauensankergenerator 922 ein INTEL™-SGX-Protokoll umsetzen, um die Attestierung umzusetzen. Der beispielhafte Vertrauensankergenerator 922 erhält (zum Beispiel über die Netzwerkschnittstelle 902) einen Vertrauensanker von einer Übertragungsverarbeitungsvorrichtung, die (zum Beispiel über eine verdrahtete oder drahtlose Verbindung) ein DSC-Objekt (zum Beispiel die Verarbeitungsvorrichtung 804 bis 810, die ein erhaltenes DSC-Objekt übertragen hat) überträgt, bevor die Daten von der Übertragungsverarbeitungsvorrichtung verarbeitet werden. Die Attestierungsstruktur offenbart die Vertrauensankerarchitektur (die zum Beispiel auf dem INTEL™-SGX-Protokoll basieren könnte, wobei die SGX-Enclave die lokale DSC-Funktion (LDSC-Funktion) sowie die Kryptoserialisierung, Signierung und Verschlüsselung umsetzt). Der beispielhafte Vertrauensankergenerator 922 führt die Hardwareattestierung aus, indem er einen geeigneten Vertrauensanker basierend auf der empfangenen Attestierung findet, einen Bootvorgang in eine Speicherungsdatenpoolumgebung, die an den Vertrauensanker gebunden ist, und die Datenspeicherungsschlüssel verwendet, um das DSC-Objekt zu importieren (zum Beispiel zu verschlüsseln) und es unter portable Datenpoolsteuerung zu setzen. Wenn eine Verarbeitungsvorrichtung 802, 804, 806, 808, 810 als eine vertrauenswürdige Drittpartei arbeitet, berechnet der Vertrauensankergenerator 922 einer derartigen Verarbeitungsvorrichtung 802, 804, 806, 808, 810 Datenschutzfunktionen, um sensible Daten zu schützen.
Der beispielhafte Objektprozessor 924 der 9 verarbeitet DSC-Datenobjekte, die von dem Netzwerk 814 empfangen werden. Der Objektprozessor 924 kann zum Beispiel einen Stakeholder verifizieren und/oder einen Eigentümerzertifikatspfad mit einem öffentlichen Schlüssel in einem Voucher verifizieren, den Empfang und/oder die Modifikation des empfangenen DSC-Objekts protokollieren und Werkzeuge laden, die in dem DSC-Objekt enthalten sind. Bei einigen Beispielen bestimmt der Objektprozessor 924, ob die Änderungen eines DSC-Objekts in eine einzige monolithische Änderung kollabiert werden sollten und/oder ob Datentransformationen kompensiert werden müssen, um die Daten des DSC-Objekts zu debuggen.
Wenn ein Stakeholder nicht verifiziert ist, lassen der Objektprozessor 924 und/oder der Objektmanager 812a und die Verarbeitungsvorrichtung 802, 804, 806, 808, 810 allgemein die Daten außer Acht und/oder signalisieren eine Warnung, dass der Stakeholder nicht verifiziert ist. Wenn ein Stakeholder verifiziert wird, nutzen der Objektprozessor 924 und/oder der Objektmanager 812a und die Verarbeitungsvorrichtung 802, 804, 806, 808, 810 im Allgemeinen die Daten als unter den Sicherheitseinschränkungen verfügbar.
DSC-Objekte können unterschiedliche Typen von Dateneinschränkungen und/oder Sicherheitseinschränkungen beinhalten, die die Verwendung der entsprechenden Daten einschränken. Beispielsweise kann die Datenhaltung eingeschränkt sein. Bei einigen Beispielen werden sichere Verfahren zum Verhindern des Haltens derartiger Daten, die aus einem Datenpool verfügbar sind, in eine digitale Ende-zu-Ende Rechteverwaltungskette eingebaut, deren Integrität durch Verifizierung physischer Vorrichtungen, die zum Übertragen und Anzeigen von Daten verwendet werden, gesichert ist. Bei einigen Beispielen werden Daten nie in ihrer klaren (unverschlüsselten) Form offenbart, außer wenn auf sie zur Berechnung, Anzeige oder Übertragung von einer vertrauenswürdigen Plattform , die Inhaltsrechtsschutz umsetzt, zugegriffen wird.
Eine andere Maßnahme gegen Datendiebstahl oder illegale Datenhaltung besteht darin, als Teil von Versorgungskettenoperationen eine maximale Anzahl von Kopien zu begrenzen. Bei derartigen Beispielen kann jede Kopie ein Maß für Mehrdeutigkeit gegenüber Daten hinzufügen, das nur über Eingriff eines Masterdatenmanagers, der in einer Sicherheitsenklave arbeitet, entfernt werden kann. Eine beispielhafte Mehrdeutigkeit beinhaltet, dass nachgelagerte Benutzer nicht in der Lage sind, ein Mashup anzuwenden, falls ein vorgelagerter Dateneigentümer oder -Stakeholder später Daten löschen und/oder den Zugriff einschränken kann. Bei einigen Beispielen wird die maximale Anzahl von dem Stakeholder gesteuert, der Löschbefehle ausgeben und/oder ein Protokoll von Kopien und Löschungen führen kann, um die maximale Anzahl von Kopien zu verwalten.
Bei einem anderen Beispiel können Einschränkungen basierend auf der Nutzungszeit eingesetzt werden, einschließlich Einrichten von Zeitlichkeit und/oder automatischem Ablauf von Zeit für Datenzugriff und/oder -nutzung. Das zeitliche Konzept mit der Datenversorgungskette kann festlegen, wann auf Daten zugegriffen werden kann und/oder sie genutzt werden können, wie lange auf die Daten zugegriffen werden kann und/oder sie genutzt werden können usw. Andere Einschränkungen können auf Geografie, spezifischen Benutzern, Benutzerkategorien, Verwendungskategorien und/oder anderen Vertragsklauseln basieren.
Der beispielhafte Entschlüsseler 926 der 9 entschlüsselt ein empfangenes DSC-Objekt basierend auf dem Protokoll, das zum Verschlüsseln des DSC-Objekts verwendet wird. Falls beispielsweise das DSC-Objekt unter Verwenden homomorpher Verschlüsselung verschlüsselt ist, entschlüsselt der Entschlüsseler 926 unter Verwenden homomorpher Entschlüsselung. Falls das DSC-Objekt serialisiert ist, kann der beispielhafte Entschlüsseler 926 bei einem anderen Beispiel das DSC-Objekt basierend auf dem Serialisierungsprotokoll entschlüsseln.
Bei dem veranschaulichten Beispiel der 9 beinhaltet die Bauelementschnittstelle 900 Mittel zum Interagieren mit und/oder Zugreifen auf Daten von anderen Bauelementen einer Verarbeitungsvorrichtung. Bei diesem Beispiel wird das Zugriffsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, eine ASIC, einen Komparator, einen Operationsverstärker („op-amp“), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt die Bauelementschnittstelle 900 das Zugriffsmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet die Netzwerkschnittstelle 902 Mittel zum Übertragen von Daten, DSC-Objekten, selbstsouveräner Identifikation und/oder Tag-Wertstruktur. Bei diesem Beispiel wird das Übertragungsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, eine PLD, eine FPLD, eine ASIC, einen Komparator, einen Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt die Netzwerkschnittstelle 902 das Übertragungsmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet das Filter 904 Mittel zum Filtern von Rohdaten. Bei diesem Beispiel wird das Filtermittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, eine ASIC, einen Komparator, eine Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt das Filter 904 das Filtermittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Dateiprozessor 906 Mittel zum Bestimmen, ob eine neue Datei erzeugt wurde, Bestimmen, ob Daten aus der Datei gefiltert werden sollten, Bestimmen, ob die Daten in einer neuen Datei sensible Daten beinhalten, Bestimmen, ob ein DSC-Objekt unter Verwenden einer selbst Neuheit Identität gesteuert wird, Bestimmen, ob eine neue Datei einem bestimmten Format oder einer bestimmten Struktur entspricht, Verknüpfen eines DSC-Objekts mit einer neuen Datei, Bestimmen, dass ein DSC-Objekt und/oder eine DSC-Datei auf eine bestimmte Vorrichtung beschränkt ist. Bei diesem Beispiel wird das Bestimmungs- und/oder Verknüpfungsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, eine ASIC, einen Komparator, einen Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Dateiprozessor 906 das Bestimmungs- und/oder Verknüpfungsmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Verschlüsseler 908 Mittel zum Verschlüsseln von Daten, anonymisiert sensible Daten, Hashen lokaler Datenobjekte, Erzeugen eines kryptografischen Hashs eines Labels des lokalen Datenobjekts, Bestimmen, ob ein DSC-Objekt Daten zur vollständigen oder homomorphen Verschlüsselung beinhaltet, und/oder Ausführen einer vollständigen oder homomorphen Verschlüsselung. Bei diesem Beispiel wird das Verschlüsselungs-, Anonymisierungs-, Hashing-, Erzeugungs-, Bestimmungs- und/oder Ausführungsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, FPGA, PLD, FPLD, ASIC, Komparator, Operationsverstärker (Operationsverstärker), Logikschaltung usw.), die strukturiert sind, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Verschlüsseler 908 das Verschlüsselungs-, Anonymisierungs-, Hashing-, Erzeugungs-, Bestimmungs- und/oder Ausführungsmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Datenstrukturgenerator 910 Mittel zum Erzeugen eines lokalen Datenobjekts, Objektmetadaten, einer hierarchischen Datenstruktur, eines lokalen Commit-Logs und/oder eines Revision(en)-Protokolls, Einhüllen der Änderungsverwaltungsmetadaten, Aktualisieren von Metadaten, Hinzufügen von Datentransformationswerkzeugen, Protokollieren von DSC-Objekterfassung, Inkrementieren einer Zugriffszählung, Aktualisieren der hierarchischen Datenstruktur, des lokalen Commit-Logs und/oder des Revisionsprotokolls, Bestimmen, ob Änderungen kollabiert werden sollten, Kollabieren der Änderungen, Erzeugen von Daten aus Kind-Subbäumen, Aufbauen einer Tag-Wert Struktur, Aufbauen eines DSC-Objekts und/oder Hinzufügen eines DSC-Objekts zu einem DSC. Bei diesem Beispiel wird das Erzeugungs-, Addier-, Protokollier-, Aktualisierungs-, Bestimmungs-, Aufbau- und/oder Addiermittel von einem beliebigen Prozessor umgesetzt, der strukturiert ist, um die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, FPGA, PLD, FPLD, ASIC, Komparator, Operationsverstärker (Operationsverstärker), Logikschaltung usw.), die strukturiert sind, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Datenstrukturgenerator 910 das Erzeugungs-, Additions-, Protokollier-, Aktualisierungs-, Bestimmungs-, Aufbau- und/oder Additionsmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Proxy-Generator 912 Mittel zum Einrichten einer Proxy-Kennung, Auswählen eines Stakeholders und/oder einer selbstsouveränen Identität/Identifikation und/oder Verifizieren einer Priorität einer selbstsouveränen Identifikation. Bei diesem Beispiel wird das Erstellungs-, Auswahl- und/oder Verifizierungsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, ein ASIC, ein Komparator, ein Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Proxy-Generator 912 das Einrichten, Auswählen und/oder Verifizieren um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Codierer 916 Mittel zum Codieren eines DSC-Objekts und/oder Anwenden eines Datenserialisierungsformats auf ein DSC-Objekt. Bei diesem Beispiel wird das Codierungs- und/oder Anwendungsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, ein ASIC, ein Komparator, ein Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Codierer 916 das Codierungs- und/oder Anlegemittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Schlüsselgenerator 918 Mittel zum Erzeugen von Vouchern, Erzeugen von Datenspeicherungsschlüsseln und/oder Berechnen von Digest-Werten. Bei diesem Beispiel wird das Erzeugungs- und/oder Rechenmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, ein ASIC, ein Komparator, ein Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Schlüsselgenerator 918 das Erzeugungs- und/oder Rechenmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Objektaggregator 920 Mittel zum Debuggen von Daten eines DSC-Objekts, Bestimmen, ob ein erstes und ein zweites DSC-Objekt aggregiert werden sollten, und/oder Anwenden von Übergängen auf das erste und das zweite DSC-Objekt, um ein drittes DSC-Objekt zu erzeugen. Bei diesem Beispiel wird das Debugging-, Bestimmungs- und/oder Anwendungsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, ein ASIC, ein Komparator, ein Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Objektaggregator 920 das Debugging-, Bestimmungs- und/oder Anwendungsmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet Vertrauensankergenerator 922 Mittel zum Finden eines geeigneten Vertrauensankers, Booten einer Vertrauensankerumgebung, Platzieren eines verschlüsselten DSC-Objekts unter Steuerung einer Speicherungsdatenpoolumgebung, Ableiten einer Herkunft und/oder Identifizieren eines Stakeholders. Bei diesem Beispiel wird das Mittel zum Finden, Booten, Platzieren, Ableiten und/oder Identifizieren von einem beliebigen Prozessor umgesetzt, der strukturiert ist zum Ausführen der entsprechenden Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltkreise, FPGA, PLD, FPLD, ASIC, vertrauenswürdige Ausführungsumgebung, vertrauenswürdige Zone, domänenisolierter Speicher, einem domänenisolierten Prozessor, einem Komparator, einem Lese-Latch, einem Lese-Schreib-Latch, einem monotonen Zähler, einem Unique Device Secret (UDS), einer Sicherung, einer Physical Unclonable Fuse (PUF), einem Strap, einem Soft-Strap, einem Festwertspeicher (ROM), einem Operationsverstärker (Op-Amp), einer Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Vertrauensankergenerator 922 das Auffinden, Booten, Platzieren, Ableiten und/oder Identifikationsmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Objektprozessor 924 Mittel zum Verifizieren eines Eigentümerzertifikatpfades, Bestimmen, ob ein DSC-Objekt Datentransformationswerkzeuge beinhaltet, Laden der Werkzeuge, Bestimmen, ob eine Datei hochgeladen wurde, ob Änderungen in eine monolithische Änderung kollabiert werden sollten, Bestimmen, ob eine Datentransformation Kompensation benötigt, Bestimmen, ob Auditieren und/oder Verfolgen ausgeführt werden sollte, Bestimmen, ob ein Stakeholder verifiziert ist, und Nutzen von Daten, die mit einer DSC assoziiert sind. Bei diesem Beispiel wird das Bestimmungs-, Verifizierungs- und/oder Nutzungsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, ein ASIC, ein Komparator, ein Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Objektprozessor 924 das Bestimmungs-, Verifizierungs- und/oder Nutzungsmittel um.
Bei dem veranschaulichten Beispiel der 9 beinhaltet der Entschlüsseler 926 Mittel zum Entschlüsseln eines DSC-Objekts. Bei diesem Beispiel wird das Entschlüsselungsmittel von einem beliebigen Prozessor umgesetzt, der dazu strukturiert ist, die entsprechende Operation durch Ausführen von Software oder Firmware oder Hardwareschaltung (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein PLD, ein FPLD, ein ASIC, ein Komparator, ein Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.), die strukturiert ist, um die entsprechende Operation auszuführen, ohne Software oder Firmware auszuführen, aber andere Strukturen sind ebenfalls geeignet. Bei einigen Beispielen setzt der Entschlüsseler 926 die Entschlüsselungseinrichtung um.
Während eine beispielhafte Weise des Umsetzens des beispielhaften Systems 800, der beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, der beispielhaften Objektmanager 812a bis e, der beispielhaften Blockchain 816 und/oder des beispielhaften Objektüberwachungsdienstes 818 der 8 in den 8 und/oder 9 veranschaulicht ist, können eines oder mehrere der Elemente, Prozesse und/oder Vorrichtungen, die in 8 und/oder 9 veranschaulicht sind, kombiniert, geteilt, umgeordnet, weggelassen, eliminiert und/oder auf eine beliebige andere Weise umgesetzt werden. Weiter können die beispielhafte Bauelementschnittstelle 900, die beispielhafte Netzwerkschnittstelle 902, das beispielhafte Filter 904, der beispielhafte Dateiprozessor 906, der beispielhafte Verschlüsseler 908, der beispielhafte Datenstrukturgenerator 910, der beispielhafte Proxy-Generator 912, der beispielhafte Codierer 916, der beispielhafte Schlüsselgenerator 918, der beispielhafte Objektaggregator 920, der Vertrauensankergenerator 922, der beispielhafte Objektprozessor 924, der beispielhafte Entschlüsseler 926 und/oder allgemeiner die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, die beispielhaften Objektmanager 812a bis e, die beispielhafte Blockchain 816 und/oder der beispielhafte Objektüberwachungsdienst 818 der 8 und/oder 9 von Hardware, Software, Firmware und/oder einer beliebigen Kombination von Hardware, Software und/oder Firmware umgesetzt werden. Somit können zum Beispiel das beispielhafte Filter 904, der beispielhafte Dateiprozessor 906, der beispielhafte Verschlüsseler 908, der beispielhafte Datenstrukturgenerator 910, der beispielhafte Proxy-Generator 912, der beispielhafte Codierer 916, der beispielhafte Schlüsselgenerator 918, der beispielhafte Objektaggregator 920, der Vertrauensankergenerator 922, der beispielhafte Objektprozessor 924, der beispielhafte Entschlüsseler 926 und/oder allgemeiner die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, die beispielhaften Objektmanager 812a bis e, die beispielhafte Blockchain 816 und/oder der beispielhafte Objektüberwachungsdienst 818 der 8 und/oder 9 von einer oder mehreren analogen oder digitalen Schaltung(en), Logikschaltungen, programmierbaren Prozessor(en), programmierbaren Steuerung(en), Grafikverarbeitungseinheit(en) (GPU(en)), digitalen Signalprozessor(en) (DSP(en)), anwendungsspezifischen integrierten Schaltung(en) (ASIC(en)), programmierbaren Logikvorrichtung(en) (PLD(s)) und/oder feldprogrammierbaren Logikvorrichtung(en) (FPLD(s)) umgesetzt werden. Wenn beliebige der Vorrichtungs- oder Systemansprüche dieses Patents gelesen werden, um eine reine Software- und/oder Firmware-Umsetzung zu decken, ist/sind das beispielhafte Filter 904, der beispielhafte Dateiprozessor 906, der beispielhafte Verschlüsseler 908, der beispielhafte Datenstrukturgenerator 9910, der beispielhafte Proxy-Generator 912, der beispielhafte Codierer 916, der beispielhafte Schlüsselgenerator 918, der beispielhafte Objektaggregator 920, der Vertrauensankergenerator 922, der beispielhafte Objektprozessor 924, der beispielhafte Entschlüsseler 926 und/oder allgemeiner die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, die beispielhaften Objektmanager 812a bis e, die beispielhafte Blockchain 816 und/oder der beispielhafte Objektüberwachungsdienst 818 der 8 und/oder 9 hiermit ausdrücklich derart definiert, dass sie eine nichtflüchtige computerlesbare Speicherungsvorrichtung oder Speicherungsplatte, wie etwa einen Speicher, eine DVD (Digital Versatile Disk), eine CD (Compact Disk), eine Blu-Ray-Disk usw. einschließlich der Software und/oder Firmware beinhalten. Weiter kann/können das beispielhafte Videoverarbeitungssystem 800 und/oder die beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810, die beispielhaften Objektmanager 812a bis e, die beispielhafte Blockchain 816 und/oder der beispielhafte Objektüberwachungsdienst 818 der 8 und/oder 9 ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder an Stelle der in den 8 und/oder 9 und/oder veranschaulichten beinhalten, und/oder kann/können sie mehr als eines oder alle der veranschaulichten Elemente, Prozesse und Vorrichtungen beinhalten. Wie hierin verwendet, beinhaltet/beinhalten der Ausdruck „in Kommunikation“ einschließlich Variationen davon, eine direkte Kommunikation und/oder indirekte Kommunikation über eine oder mehrere zwischenliegende Bauelemente und erfordern keine direkte physische (zum Beispiel verdrahtete) Kommunikation und/oder konstante Kommunikation, sondern beinhalten stattdessen zusätzlich eine selektive Kommunikation mit periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder einmalige Ereignisse.
10A veranschaulicht ein beispielhaftes DSC-Objekt 1000, das von dem beispielhaften Objektmanager 812a der 9 (zum Beispiel oder von einem der beispielhaften Objektmanager 812b-e der 8) erzeugt und/oder modifiziert werden kann. Das beispielhafte DSC-Objekt 1000 weist einen beispielhaften lokalen Merkle-Baum 1002, beispielhafte lokale Datenobjekte 1004, beispielhafte Objektmetadaten 1006, ein beispielhaftes lokales Commit-Log 1008 und ein beispielhaftes Revisionsprotokoll 1010 auf.
Der beispielhafte lokale Merkle-Baum 1002 der 10A entspricht den Daten der Datei, mit der das DSC-Objekt 1000 verknüpft ist. Der Merkle-Baum vereinfacht die Überprüfung der Integrität gegenüber mutierenden Daten. Ein Blattknoten des lokalen Merkle-Baums 1002 ist ein Hash einer Einheit der Daten (zum Beispiel ein Datenblock, ein Blob, ein Segment, eine Transaktionsaufzeichnung usw.). Die Zwischenknoten des lokalen Merkle-Baums 1002 sind kryptographische Hashes der Bezeichnungen ihrer jeweiligen Kinderknoten (zum Beispiel der Blattknoten). Der beispielhafte lokale Merkle-Baum 1002 ermöglicht eine schnelle Verifikation von Daten und jeglicher Mutationen über die Daten, die gekennzeichnet, gehasht und kryptografisch in eine Wurzel eines Teilbaums des lokalen Merkle-Baums 1002 integriert wurden. Obwohl das beispielhafte lokale Datenversorgungskettenobjekt 1000 den beispielhaften lokalen Merkle-Baum 1002 beinhaltet, kann eine beliebige hierarchische Sicherheitsstruktur verwendet werden.
Daten, die den beispielhaften lokalen Datenobjekten 1004 und den beispielhaften Objektmetadaten 1006 (zum Beispiel Versionsnummern, Zugriffsgewährungen, Aufzeichnungen des Zugriffs, Revision, die an einer davon vorgenommen wurde usw.) der 10A entsprechen, werden von den Knoten des beispielhaften lokalen Merkle-Baums 1002 wiedergegeben. Dementsprechend bildet der Merkle-Baum ein System aus miteinander verbundenen Daten- und Metadatenaufzeichnungen, die von den entsprechenden Codes in dem lokalen Merkle-Baum 1002 geschützt (zum Beispiel signiert) werden und die Historie der Daten, die dem DSC-Objekt 1000 entsprechen, widerspiegeln.
Das beispielhafte Revisionsprotokoll 1010 der 10A beinhaltet Informationen, die Revisionen verfolgen, die an den Daten (zum Beispiel Datei) vorgenommen wurden, die an das DSC-Objekt 1000 angehängt sind. Falls zum Beispiel die Daten eine Audiodatei sind und die Audiodatei von einem Soundtechniker bearbeitet wird, werden die speziellen Bearbeitungen, die von dem Techniker vorgenommen werden, in dem Revisionsprotokoll 1010 dokumentiert. Das beispielhafte lokale Commit-Log 1008 entspricht Differenzversionen der Datei (zum Beispiel einer gespeicherten Version nach einer oder mehreren Revisionen der Datei). Einige oder alle Daten in dem beispielhaften DSC-Objekt 1000 können unter Verwenden eines konsistenten Hash-basierten verteilten Datenspeichers (zum Beispiel Ceph-Dateisystem) oder einer verteilten Hochleistungsdatenbank (zum Beispiel Couch DB, levelDB, RocksDB usw.) repliziert werden.
10B veranschaulicht einen beispielhaften Blockchain-Merkle-Baum (BC-Merkle-Baum) 1012, den die beispielhafte Blockchain 816 und/oder der beispielhafte Objektüberwachungsdienst 818 verwenden, um DSC-Objekte zu verfolgen/zu überwachen, wenn die DSC-Objekte zwischen den beispielhaften Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 der 8 übergehen. Die Blöcke in 10B entsprechen Aufzeichnungen verfolgter DSC-Objekte. Jeder Block entspricht einer Anlegung eines neuen DSC-Objekts entspricht (zum Beispiel der Hash der Aufzeichnung kann das Datenobjekt eindeutig identifizieren, oder falls es ein aggregiertes Objekt ist, beinhaltet der Block Hashes des kombinierten Objekts) oder Editieren/Änderungen an einem bereits erstellten Datenobjekt (wobei in diesem Fall zum Beispiel das Datenobjekt von seinem Hash referenziert und die Art der Änderung in dem Block aufgezeichnet wird).
Der beispielhafte BC-Merkle-Baum 1012 beinhaltet Transaktionsblöcke, die signierte Hashes über die Zusammensetzungen und jegliche Mutationen (zum Beispiel Transformationen), die an ihnen ausgeführt werden können, beinhalten. Der beispielhafte BC-Merkle-Baum wird von der beispielhaften Blockchain 816 und/oder dem beispielhaften Objektüberwachungsdienst 818 geführt, um Protokolle zum Verifizieren und Hinzufügen von Blöcken zu dem beispielhaften BC-Merkle-Baum 1012 zu beobachten. Zusätzlich wird der beispielhafte BC-Merkle-Baum 1012 zum Ausführen irgendwelcher intelligenter Verträge in dem Prozess geführt, je nachdem, ob die Organisation ein öffentliches, privates oder gemischtes Blockchain-System beinhaltet.
Die beispielhaften lokalen DSC-Objekte 1016, 1018, 1020 der 10B sind gleich strukturiert wie das beispielhafte lokale DSC-Objekt 1000 der 10A. Bei dem veranschaulichten Beispiel ist das beispielhafte lokale DSC-Objekt 1016 (das zum Beispiel dem oben beschriebenen Objekt A entspricht) mit Block n des BC-Merkle-Baums 1012 verknüpft. Bei dem veranschaulichten Beispiel ist es ungewiss, ob die anderen beispielhaften lokalen DSC-Objekte 1018, 1020 (wie zum Beispiel etwa ein DSC-Objekt X und ein DSC-Objekt Y) eindeutig benannt und/oder unterschieden werden, bis beide zu der Blockchain beigetragen werden. Zum Beispiel kann eine erste Verarbeitungsvorrichtung (D1) das Objekt X unabhängig von einer zweiten Verarbeitungsvorrichtung (D2) beitragen, die das Objekt Y beitragen kann. Die Blockchain 816 und/oder der beispielhafte Objektüberwachungsdienst 818 können bei einigen Beispielen Objekt X und Objekt Y unter Verwenden der Vorrichtungsnamen für die jeweiligen Vorrichtungen, die die entsprechenden DSC-Objekte beitragen (zum Beispiel D1.X und D2.X, wobei D2.X=Objekt Y), eindeutig machen. Falls die DSC-Objekte jedoch nicht Eigentum der Entität/Vorrichtung sind, die die Blockchain aktualisiert hat, kann dem Objekt sein eigener eindeutiger Name zugewiesen werden. Bei diesem Beispiel legt die relative Position eine Nameneingentümerschaft fest, da Block 1 vor Block n auftritt. Das beispielhafte aggregierte DSC-Objekt 1014 kann den Namen X assertieren, was dazu führt, dass das lokale DSC-Objekt 1018 einen anderen Namen finden muss. Bei anderen Beispielen kann eine Objektidentifikationsanlegung mit einem SSI-System (E.g., Sovrin.org) umgesetzt werden, wobei eine SSI-Blockchain verwendet wird, um das Eigentum eines Objektnamens als eine Voraussetzung zum Beitragen des DSC zu der DSC-Blockchain 816 zu bestimmen. Zusätzlich oder alternativ kann die Blockchain 816 verwendet werden, um DSC-Objektnamen durch Aufzeichnen und Prüfen auf vorherige Blöcke einschließlich der doppelten Namen zu bestimmen. Da Namen eine Zusammenfassung von Medien sein können, können doppelte Namen seltener auftreten, es sei denn, Informationen über die DSC-Objekte sind identisch. Eindeutigkeit des Objektnamens bedeutet nicht notwendigerweise, dass ein Verstoß existiert. Eine weitere Analyse der DSC-Information kann erforderlich sein.
Ein beispielhaftes DSC-Objekt, das von dem beispielhaften Objektmanager 812a der 9 (zum Beispiel oder einer der beispielhaften Objektmanager 812b-e der 8) erzeugt und/oder modifiziert werden kann, kann unter Verwenden der folgenden beispielhaften Common-Development-Distribution-Lizenz-Schreibweise (CDDL-Schreibweise) aufgebaut werden:

// Data and meta data are nested; with a first principal supplying a first data and
                    meta data my-data-supply-chain = {
                          + my-data => data-entry,
                          * $$data-extension
                          + my-meta-data => meta-entry,
                          * $$meta-extension
                    }
                    data-entry = {
                          attribute1 => text,
                          + attribute2 => integer,
                          ? attribute3 => bool,
                          attribute4-array => array-data / [2* array-data],
                          // etc...
                    }
                    array-data {
                         item1 => integer
                         item2 => bstr
                         // etc..
                    } 



                    meta-entry = {
                         meta1 => text,
                         meta2 => integer,
                         ? meta3 => bool,
                         + meta4 => text,
                         // etc...
                    }
                    // A second principal supplying a second data and metadata enveloping the first data
                    and metadata
                         my-data2 = {
                         + my-data2 => data2-entry,
                         * $$data-extension
                         + my-meta2-data => meta2-entry,
                         * $$meta-extension
                    }
                    data2-entry = {
                         attribute1 => text,
                         meta2 => integer,
                         ? attribute3 => bool,
                         + meta4 => text,
                         // etc...
                    }
                    meta2-entry = {
                         meta1 => text,
                         meta2 => integer,
                         ? meta3 => bool,
                         + meta4 => text,
                         // etc...
                    }
                    /* Exemplary payloads that are cryptographically protected */
                    // Both data and meta data protected by the same principal payload = {
                         my-data -supply-chain
                    }
                    // Data protected by a first principal and meta data protected by a second principal
                    Payload1 = {
                         my-data-supply-chain.my-data
                    }
                    Payload2 = {
                         my-data-supply-chain.my-meta
                    }
                    /* see "payload" item in COSE crypto envelope structures to process confidentiality
                    and integrity protections associated with my-data */

Concise Binary Object Representation (CBOR) ist ein Datenformat für kleine Codegröße und kleine Nachrichtengröße, das bei Datensicherheitsdiensten verwendet werden kann. CBOR Object Signing and Encryption (COSE) ist ein entsprechendes Kommunikationsprotokoll. Eine beispielhafte CCDL-Schreibweise für COSE-Crypto-Enveloping beinhaltet:

        start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types
        ; This is define to make the tool quieter
        Internal_Types = Sig_structure / Enc_structure / MAC_structure /
              COSE_KDF_Context
        label = int / tstr
        values = any
        COSE_Messages = COSE_Untagged_Message / COSE_Tagged_Message
        COSE_Untagged_Message = COSE_Sign / COSE_Sign1 /
              COSE_Encrypt / COSE_Encrypt1 /
              COSE_Mac / COSE_Mac0
        COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /
              COSE_Encrypt_Tagged / COSE_Encrypt1_Tagged /
              COSE_Mac_Tagged / COSE_Mac0_Tagged
        Headers = (
              protected : bstr, ; Contains a header_map
               unprotected : header_map
        )
        header_map = {
              Generic_Headers,
              ; Algorithm_Headers,
              * label => values
        }
        Generic_Headers = (
              ? 1 => int / tstr, ; algorithm identifier
              ? 2 => [+label], ; criticality
              ? 3 => tstr / int, ; content type
              ? 4 => bstr, ; key identifier
              ? 5 => bstr, ; IV
              ? 6 => bstr, ; Partial IV
              ? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature
        ) 



        COSE_Sign_Tagged = #6.991(COSE_Sign); Replace 991 with TBD1
        COSE_Sign = [
              Headers,
              payload : bstr / nil,
              signatures : [+ COSE_Signature]
        ]
        COSE_Signature = [
              Headers,
              signature : bstr
        ]
        COSE_Sign1_Tagged = #6.997(COSE_Sign1); Replace 997 with TBD7
        COSE_Sign1 = [
              Headers,
              payload : bstr / nil,
              signature : bstr
        ]
        Sig_structure = [
              context: "Signature" / "Signature1" / "CounterSignature",
              body_protected: bstr,
              ? sign_protected: bstr,
              external_aad: bstr,
              payload: bstr
        ]
        COSE_Encrypt_Tagged = #6.992(COSE_Encrypt); Replace 992 with TBD2
        COSE_Encrypt = [
              Headers,
              ciphertext: bstr / nil,
              recipients: [+COSE_recipient]
        ]
        COSE_recipient = [
              Headers,
              ciphertext: bstr / nil,
              ? recipients: [+COSE_recipient]
        ]

        COSE_Encrypt1_Tagged = #6.993(COSE_Encrypt1); Replace 993 with TBD3
        COSE_Encrypt1 = [
              Headers,
              ciphertext: bstr / nil, 



        ]
        Enc_structure = [
              context : "Encrypt" / "Encrypt1" / "Enc_Recipient" /
                  "Mac_Recipient" / "Rec_Recipient",
              protected: bstr,
              external_aad: bstr
        ]
        COSE_Mac_Tagged = #6.994(COSE_Mac) ; Replace 994 with TBD4
        COSE_Mac = [
              Headers,
              payload: bstr / nil,
              tag: bstr,
              recipients: [+COSE_recipient] 
        ]
        COSE_Mac0_Tagged = #6.996(COSE_Mac0); Replace 996 with TBD6
        COSE_Mac0 = [
              Headers,
              payload: bstr / nil,
              tag: bstr,
        ]
        MAC_structure = [
              context: "MAC" / "MAC0",
              protected: bstr,
              external_aad: bstr,
              payload: bstr
        ]
        COSE_Key = {
              key_kty => tstr / int,
              ? key_ops => [+ (tstr / int)],
              ? key_alg => tstr / int,
              ? key_kid => bstr,
              * label => values
        }
        COSE_KeySet = [+COSE_Key]
        ;key_labels
        key_kty=1
        key_kid=2
        key_alg=3
        key_ops=4 



        Partyinfo = (
              ? nonce : bstr / int,
              ? identity : bstr,
              ? other : bstr,
        )
        COSE_KDF_Context = [
              AlgorithmID : int / tstr,
              PartyUlnfo : [Partyinfo],
              PartyVlnfo : [Partyinfo],
              SuppPublnfo : [
                 keyDataLength : uint,
                 protected : bstr,
                 ? other : bstr
              ],
              ? SuppPrivlnfo : bstr
        ]

Die 11 A und 11 B zeigen ein beispielhaftes Attestierungsschema in Unified Modeling Language (UML). Das beispielhafte Schema-Design beinhaltet ein Concise-Software-Identification-Tags (CoSWID) Manifest r15 mit Evolved Singer und TCBlnfo. Bei dem Beispiel bedeutet '?' (0 oder 1); ‚*‘ bedeutet (0 bis n); ‚+‘ bedeutet (1 bis n). Das beispielhafte Design-Schema stellt eine physische Umgebung dar, um die Daten verarbeitet werden. Die Umgebung kann eine vertrauenswürdige Ausführungsumgebung sein. Das beispielhafte Design-Schema zeigt Attribute einer attestierbaren Ausführungsumgebung, in der Tags eine Hierarchie von Elementen der Umgebung beschreiben und wobei eine Endorser-Entität ein Unterzeichner eines Tags sein kann. Bei dem veranschaulichten Beispiel kann eine Nutzlast eines Tags zusätzlich zu und/oder an Stelle von Software-, Firmware- und/oder Hardware-Digest-Werten Daten und Metadaten, die Artefakte der Umgebung sind, beinhalten. Die Daten und Metadaten der Tag-Integrität schützen die Nutzlast und können sie hinsichtlich der Vertraulichkeit schützen.

Eine Evidenzklasse kann dasselbe Schema wie eine Nutzlastklasse verwenden, um Attestierungsevidenz der Daten und Metadaten zu enthalten, die Digests der Software-, Firmware- und/oder Hardwareumgebungen beinhalten können, die verwendet werden, um die Daten und Metadaten zu schützen, wenn sie nicht kryptographisch geschützt sind. Somit zeigt das veranschaulichte Beispiel Daten- und Metadatenschutz in unterschiedlichen Schichten. Das Design-Schema kann zur Attestierung der Daten und/oder Attestierung der die Daten schützenden Umgebung verwendet werden.

Die 11C und 11D zeigen ein weiteres beispielhaftes Attestierungsschema. 11C und 11D zeigen eine Ressourcensammlung, die als eine Hierarchie von „Objekt“ ausgedrückt wird, die einen Ressourcensammlungsknoten (oder einen Untertyp von Ressourcensammlung) als einen verallgemeinerten Ansatz zum Codieren von Daten und Metadaten, die mit einem Objekt assoziiert sind, instanziieren kann.

12 ist ein Diagramm beispielhafter Attestierungsrollen und Workflow. Die in 12 gezeigte Attestierungsrollenarchitektur beinhaltet Attestierungs-Attester, Endorser, Verifizierer und Relying Parties, die zusammenwirken, um einen Attestierungsarbeitsablauf umzusetzen, der eine Herkunft sowohl von Daten, Metadaten als auch der Umgebungen, die Daten und Metadaten schützen, bereitstellt.

Die Attestierung beinhaltet einen Attester 1202, der die Vertrauenswürdigkeit des Computers bestimmt, der die DSC-Objekte verwaltet, die vor dem Akzeptieren eines DSC-Objekts bestimmt werden kann. Bei einigen Beispielen führt der Attester 1202 Hardwareattestierung an der Verarbeitungsvorrichtung aus, um eine sichere Ausführungsumgebung zum Erzeugen und/oder Modifizieren eines DSC-Objekts zu entwickeln. Auf diese Weise kann ein DSC-Objekt gesichert werden. Zum Beispiel kann das DSC-Objekt unter portable Datenpoolsteuerung gesetzt werden, das DSC-Objekt kann verschlüsselt und/oder zu einem Peer-Knoten unter Verwenden eines Attestierungsprotokolls attestiert werden. Diese Attestierungsevidenz wird an einen Verifier 1204 weitergegeben.

Ein Endorser 1206 gibt Endorsements an den Verifizierer 1204 weiter. Beispielsweise kann eine Vorrichtung zertifiziert sein und der Endorser 1206 stellt dem Verifizierer 1204 Informationen im Zusammenhang mit der Zertifizierung der Vorrichtung bereit, die sich auf Daten erstrecken, die von der Vorrichtung erzeugt und/oder verarbeitet werden. Bei einigen Beispielen kann eine Vorrichtung mit einer Sicherheitsrelevanz zertifiziert werden. Bei derartigen Beispielen kann der Endorser 1206 Referenzmessungen bereitstellen, die Attribute von Vorrichtungen mit der Sicherheitsrelevanz beschreiben.

Ein Verifizierer-Eigentümer 1208 stellt dem Verifizierer 1204 eine Bewertungsrichtlinie für Evidenz bereit, um die Attestierungsevidenz zu bewerten. Bei der Richtlinie handelt es sich um die Standards, Richtlinien, Regeln und/oder Mittel, mit denen der Verifizierer 1204 die Evidenz bei der Attestierungsbestimmung bewertet.

Der Verifizierer 1204 setzt die Bewertungsrichtlinie um, um die Attestierungsevidenz angesichts Endorsements zu bewerten. Der Verifizierer 1204 ermittelt die Vertrauenswürdigkeit der Evidenz. Der Verifizierer 1204 erzeugt Attestierungsergebnisse auf der Grundlage der Bewertung. Bei einigen Beispielen durchläuft der Verifizierer 1204 eine Kette von Attestierungswerten, die eine Ausführungsumgebung eines Computers mit einem Datenobjekt verknüpfen. Bei einigen Beispielen ist der Verifizierer 1204 eine Drittpartei, die verifiziert, dass Klauseln eines Vertrags erfüllt wurden, indem in der Blockchain gespeicherte Signaturen verifiziert werden (wie etwa Hashwerte in der Blockchain, Signaturen von Vorrichtungen, die Klauseln eines Vertrags akzeptieren usw.), sowie Signaturen von Parteien, die an dem Vertrag beteiligt sind. Bei einigen Beispielen kann Verifizieren von Klauseln eines Vertrags eine Treue gegenüber eingerichteten Verträgen bestätigen. Bei einigen Beispielen kann der Nachweis der Vertragserrichtung (wie etwa die Verifizierung des Vertrags in der Blockchain) verwendet werden, um eine Verwendung von Ressourcen oder eine Ausführung einer Workload zu autorisieren.

Der Verifizierer 1204 kann ein Attestierungsergebnis erzeugen, das zu einer Blockchain beitragen kann. Mit anderen Worten kann ein Blockchain-Verarbeitungsknoten eine Relying Party sein, die einen verteilten Konsensusalgorithmus anwendet, um zuzustimmen, dass das Attestierungsergebnis gültig war. Dies kann durch Herstellen von Vertrauensbeziehungen (Vertrauensankern) zwischen Verifizierer und Blockchain-Knoten (paarweise) oder durch Kombinieren von Verifizierer-Rolle mit Blockchain-Knoten erreicht werden.

Ein Relying Party-Eigentümer 1210 stellt eine Bewertungsrichtlinie für die Attestierungsergebnisse zu einer Relying Party 1212 zum Bewerten der Attestierungsergebnisse bereit. Die Richtlinie sind die Standards, Richtlinien, Regeln und/oder Mittel, mit denen die Relying Party 1212 die Ergebnisse der Attestierungsbestimmung bewertet.

Die Relying Party 1212 bewertet die Attestierungsergebnisse gemäß der Bewertungsrichtlinie für die Attestierungsergebnisse aus, um die Vertrauenswürdigkeit der übertragenen Daten zu ermitteln. Wenn die Bewertung bestimmt, dass die Daten vertrauenswürdig sind, kann die Relying Party 1212 die Daten aufbereiten und/oder anderswie verarbeiten. Wenn die Bewertung bestimmt, dass die Daten nicht vertrauenswürdig sind, kann die Relying Party 1212 die Daten ignorieren, eine Fehlermeldung usw. übermitteln.

Bei einigen Beispielen kann auch ein Attestierungsergebniswert als ein Token repräsentiert werden, wie etwa zum Beispiel ein CBOR-Web-Token (CWT), das unter Verwenden von COSE integritätsgeschützt werden kann. Das Token kann von einem Mesh oder einer Teilnehmerbasis von Relying Parties geteilt werden, die Knoten einer Blockchain beinhalten können. Zur Authentifizierung der Token können Vertrauensanker verwendet werden. Falls die Relying Parties Blockchain-Knoten sind, kann die Blockchain als Token dienen, die einen Hash-Baum aufweisen, der jeden Block in der Kette authentifiziert.

Bei einigen Beispielen können einer oder mehrere des Attesters 1202, des Verifizierers 1204, des Endorsers 1206, des Verifizierer-Eigentümers1208, des Relying Party-Eigentümers 1210 und/oder der Relying Party 1212 in die Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 und/oder Objektmanager 812a bis e der 8 und 9 enthalten oder darin eingebaut sein.

13 ist ein Diagramm beispielhafter Entitäten, die beispielhafte Attestierungsrollen und den Workflow der 12 umsetzen und/oder hosten. Zum Beispiel kann der Attestor 1202 eine erste Vorrichtung, wie etwa eine loT-Vorrichtung, eine computergestützte Vorrichtung usw., sein. Der Endorser 1206 kann eine Lieferkettenentität sein. Der Verifizierer-Eigentümer 1208 kann eine erste Verwaltungskonsole sein. Beispielsweise kann der Verifizierer-Eigentümer 1208 die Entität sein, die Kontrolle über einen Dienst hat, aber keinen Server hostet. Der Verifizierer 1204 kann ein Attestierungsdienstanbieter sein. Bei einigen Beispielen ist der Verifizierer 1204 ein Cloud-Dienst. Der Relying Party Owner 1210 kann eine zweite Verwaltungskonsole sein. Die Relying Party 1212 kann ein Ressourcenmanager, ein Stakeholder und/oder eine zweite Vorrichtung, wie etwa eine loT-Vorrichtung, eine computergestützte Vorrichtung usw., sein.

17 ist ein Diagramm, das eine beispielhafte Attestierungs-Kaskadierung in einer Datenversorgungskette zeigt. 14 zeigt einen ersten Attestierungsknoten oder Workflow 1402, der in einen zweiten Attestierungsknoten oder Workflow 1404 kaskadiert. Der erste Attestierungsarbeitsablauf 1402 stellt Herkunft/Vertrauen bezüglich eines ersten Datenlieferanten bereit, der als Attester-Vorrichtung 1406 gezeigt ist. Bei diesem Beispiel führt die Attester-Vorrichtung 1406 die Rolle des Attestors 1202 durch. Ein erster Verifizierer-Dienst 1408 führt die Aufgabe des Verifizierers 1204 aus, um die von der Attestierungsvorrichtung 1406 gelieferten Attestierungsevidenz zu bewerten, um Attestierungsergebnisse zu erzeugen, die die Herkunft/das Vertrauen der von der Attestierungsvorrichtung 1406 gelieferten Daten anzeigen. Der Verifizierer-Dienst 1408 kann in das verschachtelte Datenversorgungskettenobjekt hinunterbohren, um eine andere Schicht von Evidenz und Endorsements, die Handhabung der Daten und/oder Metadaten der Schichten betreffen, aufzudecken.

In dem ersten Attestierungsarbeitsablauf 1402 werden die Attestierungsergebnisse zu einer ersten Datenversorgungskettenentität 1410 übermittelt. In dem ersten Attestierungsarbeitsablauf 1402 führt die erste Datenversorgungskettenentität 1410 die Rolle der Relying Party 1212 aus. Die erste Datenversorgungskettenentität 1410 verkörpert und/oder hostet zum Beispiel eine Relying Party, die eine Daten- und/oder Metadatenschicht über ein erstes Daten-/Metadatenobjekt, das von der Attester-Vorrichtung 1406 empfangen wird, hinzufügt, um zweite Daten/Metadaten anzulegen.

Die erste Datenversorgungskettenentität 1410 tritt dann in den zweiten Attestierungsarbeitsablauf 1404 ein. Der zweite Attestierungsarbeitsablauf 1404 stellt Herkunft/Vertrauen bezüglich der zweiten Daten/Metadaten bereit, die von der ersten Datenversorgungskettenentität 1410 erzeugt, verarbeitet und/oder produziert werden. Dementsprechend schaltet die erste Datenübertragungskettenentität 1410 von der Rolle der Relying Party 1212 auf die Rolle des Attestors 1202 um. Bei dem zweiten Attestierungsarbeitsablauf 1404 produziert die erste Datenversorgungskettenentität 1410 Attestierungsergebnisse, die Herkunft/Vertrauen der zweiten Daten/Metadaten angeben. Ein zweiter Verifizierer-Dienst 1412 führt die Rolle des Verifizierers 1204 aus, um den von der ersten Datenübertragungskettenentität 1410 bereitgestellte Attestierungsevidenz zu beurteilen. Bei einigen Beispielen sind der zweite Verifizierer-Dienst 1412 und der erste Verifizierer-Dienst 1408 gleich.

Bei dem zweiten Attestierungsarbeitsablauf 1404 werden die Attestierungsergebnisse an eine zweite Datenversorgungskettenentität 1414 weitergegeben. Die zweite Datenversorgungskettenentität führt 1414 die Rolle des Begleitenden 1212 aus. Die erste Datenübertragungskettenentität 1410 verkörpert und/oder hostet zum Beispiel eine Relying Party(zum Beispiel eine zweite Relying Party), die eine Daten- und/oder Metadatenschicht über das zweite Daten-/Metadatenobjekt, das von der ersten Datenübertragungskettenentität 1410 empfangen wird, hinzufügt, um dritte Daten/Metadaten anzulegen. Der Workflow kann in einen dritten Attestierungs-Workflow kaskadiert werden und so fort, um eine unendliche Kaskade attestierter Enveloped-Data und/oder Metadaten zu produzieren.

Flussdiagramme, die beispielhafte Hardwarelogik, maschinenlesbare Anweisungen, hardwareumgesetzte Zustandsmaschinen und/oder eine beliebige Kombination davon zum Umsetzen des Objektmanagers 812a der 9 darstellen, sind in den 15 und 16 gezeigt. Die maschinenlesbaren Anweisungen können ein oder mehrere ausführbare Programme oder Teil(e) eines ausführbaren Programms zur Ausführung durch einen Computerprozessor und/oder Prozessorschaltungen, wie etwa den Prozessor 1712, der in der unten in Verbindung mit 17 besprochenen beispielhaften Prozessorplattform 1700 gezeigt ist, sein. Das Programm kann in Software umgesetzt sein, die auf einem nichtflüchtigen computerlesbaren Speicherungsmedium gespeichert ist, wie etwa einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-Ray-Disk oder einem mit dem Prozessor 1712 assoziierten Speicher, aber das gesamte Programm und/oder Teile davon könnten alternativ dazu von einer Vorrichtung, bei der es sich nicht um den Prozessor 1712 handelt, ausgeführt werden und/oder in Firmware oder dedizierter Hardware umgesetzt sein. Obwohl die beispielhaften Programme unter Bezugnahme auf die in den 15 und 16 veranschaulichten Flussdiagramme beschrieben sind, können alternativ viele andere Verfahren zum Umsetzen des beispielhaften Objektmanagers 812a verwendet werden. Beispielsweise kann die Reihenfolge der Ausführung der Blöcke geändert werden und/oder einige der beschriebenen Blöcke können geändert, entfernt oder kombiniert werden. Zusätzlich oder alternativ können beliebige oder alle der Blöcke von einer oder mehrere Hardwareschaltungen (zum Beispiel diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, eine ASIC, einen Operationsverstärker (Op-Amp), eine Logikschaltung usw.) umgesetzt werden, die derart strukturiert sind, dass sie eine entsprechende Operation ohne Ausführung von Software oder Firmware ausführen. Die Prozessorschaltungen können zu unterschiedlichen Netzwerkstandorten und/oder lokal zu einer oder mehreren Vorrichtungen (zum Beispiel zu einem Mehrkernprozessor in einer einzigen Maschine, mehreren Prozessoren, die über ein Server-Rack verteilt sind usw.) verteilt sein.

Die hierin beschriebenen maschinenlesbaren Anweisungen können in einem oder mehreren eines komprimierten Formats, eines verschlüsselten Formats, eines fragmentierten Formats, eines kompilierten Formats, eines ausführbaren Formats, eines verpackten Formats usw. gespeichert werden. Maschinenlesbare Anweisungen, wie hierin beschrieben, können als Daten oder eine Datenstruktur (zum Beispiel Teile von Anweisungen, Code, Repräsentationen von Code usw.) gespeichert werden, die genutzt werden können, um maschinenausführbare Anweisungen anzulegen, herzustellen und/oder zu produzieren. Zum Beispiel können die maschinenlesbaren Anweisungen fragmentiert und auf einer oder mehreren Speicherungsvorrichtungen und/oder Rechenvorrichtungen (zum Beispiel Servern), die sich an denselben oder unterschiedlichen Orten eines Netzwerks oder einer Sammlung von Netzwerken (zum Beispiel in der Cloud, in Edge-Vorrichtungen usw.) befinden, gespeichert werden. Die maschinenlesbaren Anweisungen können Installation und/oder Modifikation und/oder Anpassung und/oder Aktualisierung und/oder Kombinieren und/oder Ergänzen und/oder Konfigurieren und/oder Entschlüsselung und/oder Dekomprimierung und/oder Entpacken und/oder Verteilung und/oder Neuzuordnung und/oder Kompilierung usw. erfordern, um sie von einer Rechenvorrichtung und/oder einer anderen Maschine direkt lesbar, interpretierbar und/oder ausführbar zu machen. Zum Beispiel können die maschinenlesbaren Anweisungen in mehreren Teilen gespeichert sein, die einzeln komprimiert, verschlüsselt und auf separaten Rechenvorrichtungen gespeichert werden, wobei die Teile, wenn sie entschlüsselt, dekomprimiert und kombiniert werden, einen Satz ausführbarer Anweisungen bilden, die eine oder mehrere Funktionen umsetzen, die gemeinsam ein Programm wie das hier beschriebene bilden können.

Bei einem anderen Beispiel können die maschinenlesbaren Anweisungen in einem Zustand gespeichert werden, in dem sie von Prozessorschaltungen gelesen werden können, aber Hinzufügen einer Bibliothek (zum Beispiel einer Dynamic Link Bibliothek (DLL)), eines Softwareentwicklungskits (SDK), einer Anwendungsprogrammierungsschnittstelle (API) usw. erfordern, um die Anweisungen auf einer speziellen Rechenvorrichtung oder einer anderen Vorrichtung auszuführen. Bei einem anderen Beispiel müssen die maschinenlesbaren Anweisungen möglicherweise konfiguriert werden (zum Beispiel Einstellungen gespeichert, Daten eingegeben, Netzwerkadressen aufgezeichnet werden usw.), bevor die maschinenlesbaren Anweisungen und/oder das (die) entsprechende(n) Programm(e) vollständig oder teilweise ausgeführt werden können. Somit können maschinenlesbare Medien, wie hierin verwendet, maschinenlesbare Anweisungen und/oder Programm(e) unabhängig von dem speziellen Format oder Zustand der maschinenlesbaren Anweisungen und/oder Programm(e) beinhalten, wenn sie gespeichert oder anderswie in Ruhe oder im Durchgang sind.

Die hierin beschriebenen maschinenlesbaren Anweisungen können von einer beliebigen vergangenen, gegenwärtigen oder zukünftigen Anweisungssprache, Scriptsprache, Programmiersprache usw. repräsentiert werden. Zum Beispiel können die maschinenlesbaren Anweisungen unter Verwenden einer beliebigen der folgenden Sprachen dargestellt werden: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift usw.

Wie oben erwähnt, können die beispielhaften Prozesse der 15 und 16 unter Verwenden ausführbarer Anweisungen (zum Beispiel computer- und/oder maschinenlesbaren Anweisungen) umgesetzt werden, die auf einem nichtflüchtigen computer- und/oder maschinenlesbaren Medium gespeichert sind, wie etwa einem Festplattenlaufwerk, einem Flash-Speicher, einem Nurlesespeicher, einer Compact Disk, einer Digital Versatile Disk, einem Cache, einem Direktzugriffsspeicher und/oder einer beliebigen anderen Speicherungsvorrichtung oder Speicherungsplatte, auf der Informationen für eine beliebige Dauer (zum Beispiel für längere Zeiträume, permanent, kurzzeitig, zum temporären Puffern und/oder zum Cachen der Informationen) gespeichert sind. Wie hierin verwendet, wird der Begriff nichtflüchtiges computerlesbares Medium ausdrücklich so definiert, dass er eine beliebige Art von computerlesbarer Speicherungsvorrichtung und/oder Speicherungsplatte beinhaltet und das Propagieren von Signalen ausschließt und Übertragungsmedien ausschließt.

„Beinhaltend“ und „umfassend“ (und alle Formen und Zeitformen davon) werden hierin als offene Begriffe verwendet. Wann auch immer ein Anspruch eine beliebige Form von „beinhalten“ und „umfassen“ (zum Beispiel umfasst, beinhaltet, umfassend, beinhaltend, aufweisend usw.) als eine Präambel oder in einem Anspruchsvortrag einer beliebigen Art einsetzt, soll somit verstanden werden, dass zusätzliche Elemente, Begriffe usw. vorhanden sein können, ohne außerhalb des Schutzumfangs des entsprechenden Anspruchs oder des entsprechenden Vortrags zu fallen. Wie hierin verwendet, wenn der Ausdruck „mindestens“ als der Übergangsausdruck zum Beispiel in einer Präambel eines Anspruchs verwendet wird, ist er auf die gleiche Art und Weise offen, wie der Begriff „umfassend“ und „beinhaltend“ offen ist. Der Begriff „und/oder“ betrifft, wenn er zum Beispiel in einer Form wie A, B und/oder C verwendet wird, eine beliebige Kombination oder Untermenge von A, B, C wie (1) A allein, (2) B allein, (3) C allein, (4) A mit B, (5) A mit C, (6) B mit C und (7) A mit B und mit C. Wie hier im Zusammenhang mit der Beschreibung von Strukturen, Bauelementen, Gegenständen, Objekten und/oder Dingen verwendet, bezweckt der Ausdruck „mindestens eines von A und B‟ B auf Umsetzungen zu verweisen, die beliebige von (1) wenigstens Einem A, (2) wenigstens einem B und (3) wenigstens einem A und wenigstens einem B beinhalten. Ähnlich, wie hier im Kontext des Beschreibens von Strukturen, Bauelementen, Elementen, Objekten und/oder Dingen verwendet, soll der Ausdruck „wenigstens eines von A oder B“ auf Umsetzungen verweisen, die beliebige von (1) wenigstens einem A, (2) mindestens einem B und (3) mindestens einem A und mindestens einem B beinhalten. Wie hier im Kontext der Beschreibung der Leistungsfähigkeit oder Ausführung von Prozessen, Anweisungen, Aktionen, Aktivitäten und/oder Schritten verwendet, soll der Ausdruck „mindestens eines von A und B“ auf Umsetzungen verweisen, die beliebige von (1) mindestens einem A, (2) mindestens einem B, und (3) mindestens einem A und mindestens einem B beinhalten. Ähnlich, wie hier im Zusammenhang mit der Beschreibung der Leistungsfähigkeit oder Ausführung von Prozessen, Anweisungen, Aktionen, Aktivitäten und/oder Schritten verwendet, soll der Ausdruck „mindestens eines von A oder B“ auf Umsetzungen verweisen, die beliebige von (1) mindestens einem A, (2) mindestens einem B und (3) mindestens einem A und mindestens einem B beinhalten.

Wie hierin verwendet, schließen Bezüge im Singular (zum Beispiel „ein“, „eine“, „erste/r/s“, „zweite/r/s“ usw.) keine Mehrzahl aus. Der Begriff „eine“ Entität, wie hierin verwendet, verweist auf eine oder mehrere dieser Entität. Die Begriffe „ein“ (oder „eine“), „ein oder mehrere“ und „mindestens ein“ können hierin austauschbar verwendet werden. Obwohl einzeln aufgelistet, kann weiter eine Vielzahl von Mitteln, Elementen oder Verfahrenshandlungen von zum Beispiel einer einzigen Einheit oder einem einzigen Prozessor umgesetzt werden. Zusätzlich, obwohl einzelne Merkmale in unterschiedlichen Beispielen oder Ansprüchen enthalten sein können, können diese möglicherweise kombiniert werden, und der Einschluss in unterschiedlichen Beispielen oder Ansprüchen deutet nicht an, dass eine Kombination von Merkmalen nicht machbar und/oder vorteilhaft ist.

15 zeigt ein beispielhaftes Programm 1500 zur dezentralen Herkunfts-Assertierung. Das beispielhafte Programm 1500 der 15 beinhaltet die Bauelementschnittstelle 900 des Objektmanagers 812a, die auf Daten zugreift (Block 802). In den beispielhaften Programmen 1500 und 1600 der 15 und 16 wird die Offenbarung im Zusammenhang mit Daten derart verstanden, dass sie auch die assoziierten Metadaten beinhaltet. Bei einigen Beispielen sind die Daten Daten, die von der Verarbeitungsvorrichtung 802, in der sich der Objektmanager 812a befindet, erzeugt werden. Zum Beispiel kann die Verarbeitungsvorrichtung 802 eine Rechenvorrichtung sein, die zum Schaffen von Musik verwendet wird. Bei einigen Beispielen sind die Daten, auf die zugegriffen wird, Daten, die von einer andere Vorrichtung (Block Y) produziert werden und von der Verarbeitungsvorrichtung 802 importiert oder anderswie empfangen werden oder darauf zugegriffen wird. Zum Beispiel könnten die Daten eine Musikspur sein, die von einer anderen Vorrichtung aufgezeichnet und importiert wurde.

Das Programm 1500 beinhaltet auch, dass die Verarbeitungsvorrichtung 802 allgemein und/oder der Datenstrukturgenerator 910 den Daten Wert hinzufügt (Block 1504). Zum Beispiel könnte der Datenstrukturgenerator 910 die Musikspur neu mischen und/oder anderswie die Spur ändern.

Der Datenstrukturgenerator 910 baut ein Herkunfts-Token (Block 1506). Der Datenstrukturgenerator 910 fügt eine Tag-Wertstruktur hinzu, um das Herkunfts-Token aufzubauen (Block 1508). Die Tag-Wertstruktur ist ein Anspruch auf den hinzugefügten Wert. Das Tag identifiziert die Art des Inhalts oder der Transformation, die von der Verarbeitungsvorrichtung 802 geliefert wird. Der Wert beinhaltet eine Verweis auf den Inhalt, Algorithmus und/oder einen anderen hinzugefügten Wert. Der Datenstrukturgenerator 910 beinhaltet zum Beispiel eine Tag-Wertstruktur, die Medieninhalt als die Musikspur oder einen Teil der Musikspur identifiziert und die Änderungen identifiziert, die von der Verarbeitungsvorrichtung 802 an der Musikspur vorgenommen wurden.

Der Datenstrukturgenerator 910 fügt auch eine Stakeholder-Identität hinzu (Block 1510), um das Herkunfts-Token aufzubauen (Block 1506). Die Stakeholder-Identität wird von dem Proxy-Generator 912 erzeugt. Zum Beispiel wählt der Proxy-Generator 912 eine selbstsouveräne Identifikation (ID) zur Verwendung in dem Herkunfts-Token aus, um die Verarbeitungsvorrichtung 802 zu identifizieren (Block 1512). Bei einigen Beispielen wird die selbstsouveräne ID von dem Stakeholder ohne Freigabe oder Autorisierung einer zentralen Einrichtung, wie etwa zum Beispiel einer vertrauenswürdigen Drittpartei, die den Verarbeitungsvorrichtungen 802, 804, 806, 808, 810 der Systemarchitektur 800 gemeinsam ist, ausgewählt. Der Proxy-Generator 912 setzt die selbstsouveräne ID als die Stakeholder-Identität (Block 1514). Der Datenstrukturgenerator 910 baut das Herkunfts-Token basierend auf der Stakeholder-Identität, wie oben offenbart, auf.

Der Proxy-Generator 912 bestimmt auch, ob es einen Konflikt mit einer Stakeholder-Identität gibt (Block 1516). Zum Beispiel können zwei Benutzer oder zwei Verarbeitungsvorrichtungen dieselbe selbstsouveräne ID bestätigen, die als ihre jeweiligen Stakeholder-Identität festgelegt ist. Falls der Proxy-Generator 912 bestimmt, dass es keinen Konflikt mit einer Stakeholder-Identität gibt (Block 1516: NEIN), fügt der Datenstrukturgenerator 910 das Herkunfts-Token zu der Blockchain hinzu (Block 1518). Bei einigen Beispielen fügt der Codierer 916 oder der Aggregator 920 das Herkunfts-Token zu der Blockchain hinzu. Das Herkunfts-Token ist ein neuer Hash, der das ältere Material enthält. Somit beinhaltet der neue Hash eine erste Zusammenfassung der Daten vor dem hinzugefügten Wert der Verarbeitungsvorrichtung 802 und eine zweite Zusammenfassung der Daten nach dem hinzugefügten Wert der Verarbeitungsvorrichtung 802. Somit baut das Herkunfts-Token auf der Blockchain auf und fügt eine Identifikation der neuen Daten/Metadaten und ihrer Quelle hinzu.

Falls der Proxy-Generator 912 bestimmt, dass es einen Konflikt mit einer Stakeholder-Identität gibt (Block 1516: JA) bestimmt der Proxy-Generator 912, welche Entität oder Vorrichtung Priorität gegenüber der Stakeholder-Identität hat (Block 1520). Zum Beispiel kann der Proxy-Generator 912 Zeitstempeldaten untersuchen, die angeben, wann die jeweiligen Vorrichtungen ihre selbstsouveränen IDs etabliert haben. Bei einigen Beispielen werden die Zeitstempel basierend auf koordinierter Weltzeit (UTC) verglichen, um Vorrichtungen zu berücksichtigen, die sich in unterschiedlichen geografischen Gebieten befinden. Der Proxy-Generator 912 bestimmt, ob die Verarbeitungsvorrichtung 802, die das beispielhafte Programm 1500 ausführt, um die Herkunft zu bestätigen, Priorität hat (Block 1522). Falls die Verarbeitungsvorrichtung 802, die das Programm 1500 ausführt, keine Priorität gegenüber der Stakeholder-Identität hat (Block 1522: NEIN), fährt das Programm 1500 damit fort, dass der Proxy-Generator 912 eine andere selbstsouveräne ID auswählt (Block 1512).

Falls der Proxy-Generator 912 bestimmt, dass die Verarbeitungsvorrichtung 802, die das Programm 1500 ausführt, Priorität gegenüber der Stakeholder-Identität hat (Block 1522: JA) fährt das Programm 1500 damit fort, dass der Datenstrukturgenerator 910, der Codierer 916 und/oder der Aggregator 920 das Herkunfts-Token zu der Blockchain hinzufügt (Block 1518).

Der Verschlüsseler 908 signiert das Herkunfts-Token mit dem Entitätsschlüssel (Block 1524). Das Programm 1500 beinhaltet auch die Netzwerkschnittstelle 902, die Daten mit der aktualisierten Blockchain zu anderen Vorrichtungen/Netzwerken verteilt oder überträgt (Block 1526). Somit wird die Blockchain mit der Herkunfts-Assertierung der Verarbeitungsvorrichtung 802 mit anderen Arbeitsabläufen kaskadiert (Block X).

16 zeigt ein beispielhaftes Programm 1600 zur Herkunfts- und Dateneinschränkungsbestimmung. Das Programm 1600 beinhaltet, dass die Bauelementschnittstelle 900 auf Daten zugreift (Block 1602). Die Bauelementschnittstelle 900 kann Teil des Objektmanagers 812a der oben offenbarten Verarbeitungsvorrichtung 802 oder Teil eines Objektmanagers 812b bis e einer anderen Verarbeitungsvorrichtung 804, 806, 808, 810 sein. Um die Kaskadierungsart der Daten, Metadaten und Blockchain zu veranschaulichen, wird das Programm 1600 der 16 als auf einer Verarbeitungsvorrichtung stattfindend beschrieben, die sich von der Verarbeitungsvorrichtung unterscheidet, die das Programm 1500 der 15 ausführt. Allerdings ist eine beliebige Verarbeitungsvorrichtung 802, 804, 806, 808, 810, die hier offenbart ist, strukturiert, programmiert, angepasst und/oder konfiguriert, um entweder das Programm 1500 und/oder das Programm 1600 auszuführen. Die Daten, auf die die Bauelementschnittstelle 900 zugreift, können Daten sein, die von der Verarbeitungsvorrichtung 808 erzeugt werden, die das Programm 1600 ausführt, oder können Daten sein, die über das Netzwerk 814 kaskadieren, wie etwa die Daten, die von der Verarbeitungsvorrichtung 802 erzeugt und verteilt werden, die das Programm 1500 ausführt (Block X). Bei anderen Beispielen können die Daten von einer externen Vorrichtung (repräsentiert durch Block X) eine beliebige andere Verarbeitungsvorrichtung sein.

Das beispielhafte Programm 1600 beinhaltet, dass der Vertrauensankergenerator 922 Sicherheitsdeskriptoren ableitet (Block 1604). Die Sicherheitsdeskriptoren sind Datenstruktur in der Blockchain, die Sicherheitsinformationen beinhaltet. Sicherheitsinformationen beinhalten Herkunftsinformationen und Details im Zusammenhang mit Sicherheits- und/oder Datennutzungseinschränkungen. Der Vertrauensankergenerator 922 leitet die Versorgungsketten-Datenherkunft aus den Sicherheitsdeskriptoren ab (Block 1606). Bei einigen Beispielen werden vertrauenswürdige Drittparteien dazu genutzt, als Berechnungsbroker oder Proxies zu fungieren, um eine Operation oder Rechnung über selbstsouveräne Daten auszuführen. Bei derartigen Beispielen kreuzen Daten nicht verschiedene empfindliche Perimeter, Nebeneffekt-freie Funktionen werden in die entgegengesetzte Richtung gesandt, um bestimmte zulässige Ergebnisse über selbstsouveräne Daten zu berechnen und zurückzugeben. Somit können zum Beispiel sensible persönlich identifizierbare Daten einen bestimmten Ort (zum Beispiel ein Gesundheitszentrum, ein Finanzinstitut) nicht verlassen, Wert kann aus derartigen Daten erhalten werden, indem Ergebnisse von Funktionen, die bekannterweise Privatsphärenschutz sind (zum Beispiel Funktionen, die erlaubte Statistiken liefern, wie Korrelationen zwischen Gesundheits- und Erkrankungsfaktoren, oder eine Verteilung von Asset-Mixes in den Portfolio-Holdings der Institution) zurückgegeben werden. Derartige Berechnungen können von den vertrauenswürdigen Drittparteien ausgeführt werden, die bewirken, dass die Verbraucher (zum Beispiel die Verarbeitungsvorrichtung, die das Programm 1600 ausführt) von den Daten, die von selbstsouveränen Kontrollen darüber geschützt sind, getrennt werden.

Bei diesem Beispiel kann der vertrauenswürdige Dritte zum Beispiel eine andere Verarbeitungsvorrichtung 802, 806, 808, 810 und/oder der Objektüberwachungsdienst 818 sein. Die Bauelementschnittstelle 902 der vertrauenswürdigen Drittpartei greift auf Daten zu (Block 1608). Der Vertrauensankergenerator 922 der vertrauenswürdigen Drittpartei berechnet eine Datenschutzfunktion (Block 1610). Die Netzwerkschnittstelle 902 der vertrauenswürdigen Drittpartei gibt das Berechnungsergebnis zurück (Block 1612). Der Vertrauensankergenerator 922 der Verarbeitungsvorrichtung 804, die das Programm 1600 ausführt, verwendet das Rechenergebnis, um Herkunft abzuleiten (Block 1606).

Der Objektprozessor 924 der Verarbeitungsvorrichtung 804, die das Programm 1600 ausführt, verifiziert den Stakeholder aus der Herkunft (Block 1614). Der Objektprozessor 924 bestimmt, ob in dem Stakeholder vertraut wird oder verifiziert wird(Block 1616). Ist der Stakeholder nicht vertrauenswürdig oder verifiziert (Block 1616: NEIN), verwerfen der Objektprozessor 924 und/oder der Objektmanager 812a und/oder die Verarbeitungsvorrichtung 804 im Allgemeinen die Daten und/oder melden eine Warnung (Block 1618). Das beispielhafte Programm 1600 endet dann.

Ist der Stakeholder vertrauenswürdig oder verifiziert (Block 1616: JA) nutzt der Objektprozessor 924 und/oder der Objektmanager 812a und/oder die Verarbeitungsvorrichtung 804 im Allgemeinen die Daten gemäß den Sicherheits- und/oder Dateneinschränkungen, die in den Sicherheitsdeskriptoren identifiziert werden (Block 1620). Zum Beispiel kann die Verarbeitungsvorrichtung 804 die Daten für einen bestimmten Zeitraum, für bestimmte Verwendungen, unter spezifizierten Vertragsbegriffen usw. verwenden.

Der Datenstrukturgenerator 910, der Codierer 916 und/oder der Objektaggregator 920 aktualisieren die Datenversorgungskette gemäß der Verwendung der Daten (Block 1622). Die aktualisierte Versorgungskette wird zu anderen Workflows kaskadiert (Block Y).

Block X und Block Y werden hierin verwendet, um den Import einer Datenversorgungskette von einem externen Gerät und eine Verteilung einer Datenversorgungskette zu einem externen Gerät zu zeigen. Obwohl diese Beschreibung die Verarbeitungsvorrichtung 802 als die Anweisungen oder das Programm 1500 der 15 ausführend verwendet und die Verarbeitungsvorrichtung 804 als die Anweisungen oder das Programm 1600 der 16 ausführend verwendet, versteht es sich, dass beliebige Verarbeitungsvorrichtungen eines der Programme 1500, 1600 ausführen können. Die Ausführung der Programme 1500, 1600 und die Beziehungen der Programme 1500, 1600 sind nicht auf zwei Vorrichtungen beschränkt. Stattdessen können die Programme 1500, 1600 verwendet werden, um eine erweiternde Datenversorgungskette zu einer dritten Vorrichtung, einer vierten Vorrichtung usw. zu kaskadieren.

17 ist ein Blockdiagramm einer beispielhaften Prozessorplattform 1700, die zum Ausführen der Anweisungen der 15 und 16 strukturiert ist, um den Objektmanager 812a der 9 und/oder die Objektmanager 812b bis e der 8 umzusetzen. Bei einigen Beispielen kann die Prozessorplattform 1700 verwendet werden, um einen Edge-Knoten in einer Edge-Rechenumgebung umzusetzen. Die Prozessorplattform 1700 kann zum Beispiel ein Server, ein Personal Computer, eine Workstation, ein Web-Plug-In-Tool, eine selbstlernende Maschine (zum Beispiel ein neuronales Netzwerk), eine Mobilvorrichtung (zum Beispiel ein Mobiltelefon, ein Smartphone, ein Tablet, wie etwa ein iPad™), ein Internetgerät oder eine beliebige andere Art von Rechenvorrichtung sein.

Die Prozessorplattform 1700 des veranschaulichten Beispiels beinhaltet einen Prozessor 1712. Der Prozessor 1712 des veranschaulichten Beispiels ist Hardware. Der Prozessor 1712 kann zum Beispiel von einer oder mehreren integrierten Schaltungen, Logikschaltungen, einem oder mehreren Mikroprozessoren, einer oder mehreren GPUs, DSPs oder Steuervorrichtungen einer beliebigen gewünschten Familie oder eines beliebigen gewünschten Herstellers umgesetzt werden. Der Hardwareprozessor kann eine halbleiterbasierte (zum Beispiel siliziumbasierte) Vorrichtung sein. Bei diesem Beispiel setzt der Prozessor 1712 das beispielhafte Filter 904, den beispielhaften Dateiprozessor 906, den beispielhaften Verschlüsseler 908, den beispielhaften Datenstrukturgenerator 910, den beispielhaften Proxy-Generator 912, den beispielhaften Codierer 916, den beispielhaften Schlüsselgenerator 918, den beispielhaften Objektaggregator 920, den Vertrauensankergenerator 922, den beispielhaften Objektprozessor 924 und den beispielhaften Entschlüsseler 926 um.

Der Prozessor 1712 des veranschaulichten Beispiels beinhaltet einen lokalen Speicher 1713 (zum Beispiel einen Cache). Der Prozessor 1712 des veranschaulichten Beispiels steht über einen Bus 1718 in Kommunikation mit einem Hauptspeicher, der einen flüchtigen Speicher 1714 und einen nichtflüchtigen Speicher 1716 beinhaltet. Der flüchtige Speicher 1714 kann von einem SDRAM (Synchronous Dynamic Random Access Memory - synchroner dynamischer Direktzugriffsspeicher), DRAM (dynamischer Direktzugriffsspeicher), RDRAM^Ⓡ (RAMBUS^® dynamischer Direktzugriffsspeicher) und/oder einer beliebigen anderen Art von Direktzugriffsspeicher-Vorrichtung umgesetzt werden. Der nichtflüchtige Speicher 1716 kann von einem Flash-Speicher und/oder einer beliebigen anderen gewünschten Art von Speichervorrichtung umgesetzt werden. Ein Zugriff auf den Hauptspeicher 1714, 1716 wird von einer Speichersteuerung gesteuert.

Die Prozessorplattform 1700 des veranschaulichten Beispiels weist auch eine Schnittstellenschaltung 1720 auf. Die Schnittstellenschaltung 1720 kann von einer beliebigen Art von Schnittstellenstandard umgesetzt werden, wie etwa von einer Ethernet-Schnittstelle, einem USB (Universal Serial Bus), einer Bluetooth^®-Schnittstelle, einer Nahfeldkommunikationsschnittstelle (NFC-Schnittstelle) und/oder einer PCI-Express-Schnittstelle. Bei diesem Beispiel setzt der Schnittstellenschaltkreis 1730 die beispielhafte Netzwerkschnittstelle 902 der 9 um.

Bei dem veranschaulichten Beispiel sind eine oder mehrere Eingabevorrichtungen 1722 mit der Schnittstellenschaltung 1720 verbunden. Die eine oder die mehreren Eingabevorrichtungen 1722 gestatten es einem Benutzer, Daten und/oder Befehle in den Prozessor 1712 einzugeben. Die eine oder die mehreren Eingabevorrichtungen können zum Beispiel von einem Audiosensor, einem Mikrofon, einer Kamera (Standbild oder Video), einer Tastatur, einer Taste, einer Maus, einem Touchscreen, einem Trackpad, einem Trackball, Isopoint und/oder einem Spracherkennungssystem umgesetzt werden.

Eine oder mehrere Ausgabevorrichtungen 1724 sind auch mit der Schnittstellenschaltung 1720 des veranschaulichten Beispiels verbunden. Die Ausgabevorrichtungen 1724 können zum Beispiel von Anzeigevorrichtungen (zum Beispiel einer Leuchtdiode (LED), einer organischen Leuchtdiode (OLED), einer Flüssigkristallanzeige (LCD), einer Kathodenstrahlröhrenanzeige (CRT-Anzeige), einer IPS-Anzeige (In-Place Switching-Anzeige), einem Touchscreen usw.), einer taktilen Ausgabevorrichtung, einem Drucker und/oder Lautsprecher umgesetzt werden. Die Schnittstellenschaltung 1720 des veranschaulichten Beispiels beinhaltet somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiber-Chip und/oder einen Grafiktreiberprozessor.

Die Schnittstellenschaltung 1720 des veranschaulichten Beispiels beinhaltet auch eine Kommunikationsvorrichtung, wie etwa einen Sender, einen Empfänger, einen Transceiver, ein Modem, ein Haus-Gateway, einen drahtlosen Zugangspunkt und/oder eine Netzwerkschnittstelle zum Erleichtern des Austauschs von Daten mit externen Maschinen (zum Beispiel Rechenvorrichtungen einer beliebigen Art) über das Netzwerk 1726. Die Kommunikation kann zum Beispiel über eine Ethernet-Verbindung, eine DSL-Verbindung (Digital Subscriber Line-Verbindung), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses Line-of-Site-System, ein Zellulartelefonsystem usw. stattfinden.

Die Prozessorplattform 1700 des veranschaulichten Beispiels beinhaltet auch eine oder mehrere Massenspeicherungsvorrichtungen 1728 zum Speichern von Software und/oder Daten. Beispiele für derartige Massenspeicherungsvorrichtungen 1728 beinhalten Diskettenlaufwerke, Festplatten, CD-Laufwerke, Blu-Ray-Disk-Laufwerke, RAID-Systeme (Redundant Array of Independent Disks-Systeme und DVD-Laufwerke (Digital Versatile Disk-Laufwerke).

Die maschinenausführbaren Anweisungen 1732 der 15 und 16 können in der Massenspeicherungsvorrichtung 1728, im flüchtigen Speicher 1714, im nichtflüchtigen Speicher 1716 und/oder auf einem entfernbaren nichtflüchtigen computerlesbaren Speicherungsmedium, wie etwa einer CD oder DVD, gespeichert werden.

18 ist ein Blockdiagramm einer beispielhaften Prozessorplattform 1800, die strukturiert ist, um die beispielhafte Blockchain 816 und/oder den beispielhaften Objektüberwachungsdienst 818 der 8 umzusetzen. Bei einigen Beispielen kann die Prozessorplattform 1800 verwendet werden, um einen Edge-Knoten in einer Edge-Rechenumgebung umzusetzen. Die Prozessorplattform 1800 kann zum Beispiel ein Server, ein Personal Computer, eine Workstation, ein Web-Plug-In-Tool, eine selbstlernende Maschine (zum Beispiel ein neuronales Netzwerk), eine Mobilvorrichtung (zum Beispiel ein Mobiltelefon, ein Smartphone, ein Tablet, wie etwa ein iPad™), ein Internetgerät oder eine beliebige andere Art von Rechenvorrichtung sein.

Die Prozessorplattform 1800 des veranschaulichten Beispiels beinhaltet einen Prozessor 1812. Der Prozessor 1812 des veranschaulichten Beispiels ist Hardware. Der Prozessor 1812 kann zum Beispiel von einer oder mehreren integrierten Schaltungen, Logikschaltungen, einem oder mehreren Mikroprozessoren, einer oder mehreren GPUs, DSPs oder Steuervorrichtungen einer beliebigen gewünschten Familie oder eines beliebigen gewünschten Herstellers umgesetzt werden. Der Hardwareprozessor kann eine halbleiterbasierte (zum Beispiel siliziumbasierte) Vorrichtung sein.

Der Prozessor 1812 des veranschaulichten Beispiels beinhaltet einen lokalen Speicher 1813 (zum Beispiel einen Cache). Der Prozessor 1812 des veranschaulichten Beispiels steht über einen Bus 1818 in Kommunikation mit einem Hauptspeicher, der einen flüchtigen Speicher 1814 und einen nichtflüchtigen Speicher 1816 beinhaltet. Der flüchtige Speicher 1814 kann von SDRAM, DRAM, RDRAM ^® und/oder einer beliebigen anderen Art von Direktzugriffsspeichervorrichtung umgesetzt werden. Der nichtflüchtige Speicher 1816 kann von einem Flash-Speicher und/oder einer beliebigen anderen gewünschten Art von Speichervorrichtung umgesetzt werden. Ein Zugriff auf den Hauptspeicher 1814, 1816 wird von einer Speichersteuervorrichtung gesteuert.

Die Prozessorplattform 1800 des veranschaulichten Beispiels weist auch eine Schnittstellenschaltung 1820 auf. Die Schnittstellenschaltung 1820 kann von einem beliebige Typ von Schnittstellenstandard umgesetzt werden, wie etwa von einer Ethernet-Schnittstelle, einem USB, einer Bluetooth-Schnittstelle, einer NFC-Schnittstelle und/oder eine PCI-Express-Schnittstelle. Bei diesem Beispiel setzt der Schnittstellenschaltkreis 1830 die beispielhafte Netzwerkschnittstelle 202 der 2 um.

Bei dem veranschaulichten Beispiel sind eine oder mehrere Eingabevorrichtungen 1822 mit der Schnittstellenschaltung 1820 verbunden. Die eine oder die mehreren Eingabevorrichtungen 1822 gestatten es einem Benutzer, Daten und/oder Befehle in den Prozessor 1812 einzugeben. Die eine oder die mehreren Eingabevorrichtungen können zum Beispiel von einem Audiosensor, einem Mikrofon, einer Kamera (Standbild oder Video), einer Tastatur, einer Taste, einer Maus, einem Touchscreen, einem Trackpad, einem Trackball, Isopoint und/oder einem Spracherkennungssystem umgesetzt werden.

Eine oder mehrere Ausgabevorrichtungen 1824 sind auch mit der Schnittstellenschaltung 1820 des veranschaulichten Beispiels verbunden. Die Ausgabeeinrichtungen 1824 können zum Beispiel durch Anzeigeeinrichtungen (zum Beispiel eine LED, eine OLED, ein LCD, eine CRT-Anzeige, eine IPS-Anzeige, einen Touchscreen usw.), eine taktile Ausgabevorrichtung, einen Drucker und/oder Lautsprecher umgesetzt sein. Die Schnittstellenschaltung 1820 des veranschaulichten Beispiels beinhaltet somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip und/oder einen Grafiktreiberprozessor.

Die Schnittstellenschaltung 1820 des veranschaulichten Beispiels beinhaltet auch eine Kommunikationsvorrichtung, wie etwa einen Sender, einen Empfänger, einen Transceiver, ein Modem, ein Haus-Gateway, einen drahtlosen Zugangspunkt und/oder eine Netzwerkschnittstelle zum Erleichtern des Austauschs von Daten mit externen Maschinen (zum Beispiel Rechenvorrichtungen einer beliebigen Art) über das Netzwerk 1826. Die Kommunikation kann beispielsweise über eine Ethernet-Verbindung, eine DSL-Verbindung, eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses Line-of-Sight-System, ein Mobilfunksystem usw. erfolgen.

Die Prozessorplattform 1800 des veranschaulichten Beispiels beinhaltet auch eine oder mehrere Massenspeicherungsvorrichtungen 1828 zum Speichern von Software und/oder Daten. Beispiele für derartige Massenspeichervorrichtungen 1828 beinhalten Diskettenlaufwerke, Festplatten, Compact-Disc-Laufwerke, Blu-Ray-Disc-Laufwerke, RAID-Systeme und DVD-Laufwerke.

Die maschinenausführbaren Anweisungen 1832 der 18 können in der Massenspeicherungsvorrichtung 1828, im flüchtigen Speicher 1814, im nichtflüchtigen Speicher 1816 und/oder auf einem entfernbaren nichtflüchtigen computerlesbaren Speicherungsmedium, wie etwa einer CD oder DVD, gespeichert werden.

Aus dem Vorstehenden versteht es sich, dass beispielhafte Systeme, Verfahren, Einrichtungen und Herstellungsartikel offenbart wurden, die es den Stakeholdern ermöglichen, eine selbstsouveräne Identifikation für eine dezentrale Herkunfts-Assertierung auszuwählen und diese Identifikation und eine Tag-Wertstruktur zu einer Datenversorgungskette hinzuzufügen. Die offenbarten Systeme, Verfahren, Einrichtungen und Herstellungsartikel verbessern die Effizienz des Verwendens einer Rechenvorrichtung, indem sie das Verfolgen verschiedener Arten von Daten erleichtern, wodurch es Medienerzeugern ermöglicht wird, Schutzrechte für geistiges Eigentum in einem verteilten und dezentralen Datenökosystem zu schützen. Hierin offenbarte Beispiele ermöglichen es Medieneigentümern Inferenzen, die von AI-getriebenen Entitäten erzeugt werden, unabhängig zu prüfen. Hierin offenbarte Beispiele stellen automatische Zusammenführungen von Daten bereit, die in neuen Zusammensetzungen resultieren, die von einer Datenversorgungskette verfolgt werden können. Hierin offenbarte Beispiele stellen eine rechnerische Infrastruktur bereit, die eine dezentralisierte Workload hosten kann und AI-Plattform-Sicherheitsbauelemente zum Verbessern der Sicherheit des Systems und der Daten, die innerhalb des Systems verarbeitet werden, bereitstellen kann. Die offenbarten Verfahren, Einrichtungen und Herstellungsartikel sind dementsprechend auf eine oder mehrere Verbesserungen der Funktionsweise eines Computers ausgerichtet.

Das Hinzufügen von Herkunft auf eine dezentrale Weise ermöglicht eine dynamische Erweiterung von Metadatennomenklatur, was die Benutzerbedienbarkeit verbessert und nicht erfordert, dass Inhaltseigentümer einen spezifischen und oft auf Englisch basierten Satz von Standards anwenden. Die Datenherkunft ist beim Bestimmen der Vertrauenswürdigkeit von Daten, wie frisch die Daten sind, der Genauigkeit, Vollständigkeit, Vertraulichkeit, Integrität usw. wichtig. Die hier offenbarten Beispiele weisen eine vorteilhafte Umsetzung in der Gesundheits- und Finanzindustrie zum Schützen privater Daten auf, während die Herkunft und somit das Vertrauen in die Quelle der Daten authentifiziert werden.

Beispielhafte Verfahren, Einrichtungen, Systeme und Herstellungsartikel zum Bestimmen einer Herkunft für Datenversorgungsketten sind hier offenbart. Weitere Beispiele und Kombinationen davon beinhalten das Folgende: Beispiel 1 beinhaltet ein nichtflüchtiges computerlesbares Speichermedium, das Daten umfasst, die zu ausführbaren Anweisungen konfiguriert werden können und, wenn sie konfiguriert und ausgeführt werden, bewirken, dass ein oder mehrere Prozessoren mindestens Folgendes ausführen: Ableiten einer Herkunft eines ersten Datenversorgungskettenobjekts; Identifizieren eines ersten Stakeholders aus der Herkunft; Bestimmen, ob der erste Stakeholder verifiziert ist; Nutzen von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert ist; Aufbauen einer Tag-Wertstruktur basierend auf der Nutzung der Daten; Aufbauen eines zweiten Datenversorgungskettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders; und Hinzufügen des zweiten Datenversorgungskettenobjekts zu der Datenversorgungskette.

Beispiel 2 beinhaltet das computerlesbare Speichermedium des Beispiels 1, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Daten und das zweite Datenversorgungskettenobjekt zu einer Vorrichtung, die Zugriff auf die Daten angefordert hat, übertragen.

Beispiel 3 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 1 und/oder 2 und optional die Anweisungen, die bewirken, dass der eine oder die mehreren Prozessoren die Herkunft basierend auf einer vertrauenswürdigen Drittpartei-Datenschutzfunktion ableiten.

Beispiel 4 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 1 bis 3 und optional die Anweisungen, die bewirken, dass der eine oder die mehreren Prozessoren die zweite Stakeholder-Identität basierend auf einer selbstsouveränen Identifikation auswählen.

Beispiel 5 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 1 bis 4 und beinhaltet optional, dass die selbstsouveräne Identifikation von dem zweiten Stakeholder entwickelt wird.

Beispiel 6 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 1 bis 5 und beinhaltet optional die Anweisungen, die bewirken, dass der eine oder die mehreren Prozessoren einen zentralen Bestand umgehen, um die zweite Stakeholder-Identität auszuwählen.

Beispiel 7 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 1 bis 6 und beinhaltet optional die Anweisungen, die bewirken, dass der eine oder die mehreren Prozessoren die Priorität der selbstsouveränen Identifikation gegenüber dem zweiten Stakeholder verifizieren.

Beispiel 8 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 1 bis 7 und beinhaltet optional, dass die selbstsouveräne Identifikation eine erste selbstsouveräne Identifikation ist und die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren eine zweite selbstsouveräne Identifikation auswählen, wenn dem zweiten Stakeholder Priorität gegenüber der ersten selbstsouveränen Identifikation fehlt.

Beispiel 9 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 1 bis 8 und beinhaltet optional die Anweisungen, die bewirken, dass der eine oder die mehreren Prozessoren die selbstsouveräne Identifikation und die Tag-Wertstruktur zu einer oder mehreren anderen Vorrichtungen zur Bewertung der Nomenklatur der selbstsouveränen Identifikation und der Tag-Wertstruktur übertragen.

Beispiel 10 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 1 bis 9 und beinhaltet optional die Anweisungen, die bewirken, dass der eine oder die mehreren Prozessoren das zweite Datenversorgungskettenobjekt zu einer Blockchain und/oder einem Objektüberwachungsdienst übertragen, um (a) einen den Daten entsprechenden Vertrag durchzusetzen, (b) Revisionen an den Daten aufzuzeichnen, (c) Datenherkunft durchzusetzen oder (d) die Daten zu verfolgen.

Beispiel 11 beinhaltet ein System zum Erzeugen eines Datenversorgungskettenobjekts, wobei die Einrichtung Folgendes umfasst: einen Vertrauensankergenerator zum: Ableiten einer Herkunft eines ersten Datenversorgungskettenobjekts; und Identifizieren eines ersten Stakeholders aus der Herkunft. Das System des Beispiels 11 beinhaltet auch einen Objektprozessor zum: Bestimmen, ob der erste Stakeholder verifiziert ist; und Nutzen von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert ist; und einen Datenstrukturgenerator zum: Aufbauen einer Tag-Wertstruktur basierend auf der Nutzung der Daten; Aufbauen eines zweiten Datenversorgungskettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders; und Hinzufügen des zweiten Datenversorgungkettenobjekts zu der Datenversorgungskette.

Beispiel 12 beinhaltet das System des Beispiels 11, das weiter eine Netzwerkschnittstelle zum Übertragen der Daten und des zweiten Datenversorgungskettenobjekts zu einer Vorrichtung, die Zugriff auf die Daten angefordert hat, beinhaltet.

Beispiel 13 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 11 und/oder 12 und beinhaltet optional, dass der Vertrauensankergenerator die Herkunft basierend auf einer vertrauenswürdigen Drittpartei-Datenschutzfunktion ableitet.

Beispiel 14 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 11 bis 13 und beinhaltet optional einen Proxy-Generator zum Auswählen der zweiten Stakeholder-Identität basierend auf einer selbstsouveränen Identifikation.

Beispiel 15 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 11 bis 14 und beinhaltet optional, dass die selbstsouveräne Identifikation von dem zweiten Stakeholder entwickelt wird.

Beispiel 16 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 11 bis 15 und beinhaltet optional, dass der Proxy-Generator einen zentralen Bestand umgeht, um die zweite Stakeholder-Identität auszuwählen.

Beispiel 17 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 11 bis 16 und beinhaltet optional den Proxy-Generator zum Verifizieren der Priorität der selbstsouveräne Identifikation gegenüber dem zweiten Stakeholder.

Beispiel 18 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 11 bis 17 und beinhaltet optional, dass die selbstsouveräne Identifikation eine erste selbstsouveräne Identifikation ist, und der Proxy-Generator eine zweite selbstsouveräne Identifikation auswählt, wenn dem zweiten Stakeholder Priorität gegenüber der ersten selbstsouveränen Identifikation fehlt.

Beispiel 19 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 11 bis 18 und beinhaltet optional eine Netzwerkschnittstelle zum Übertragen der selbstsouveränen Identifikation und der Tag-Wertstruktur zu einer oder mehreren anderen Vorrichtungen zur Bewertung der Nomenklatur der selbstsouveränen Identifikation und der Tag-Wertstruktur.

Beispiel 20 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 11 bis 19 und beinhaltet optional eine Netzwerkschnittstelle zum Übertragen des zweiten Datenversorgungskettenobjekts zu einer Blockchain und/oder einem Objektüberwachungsdienst, um (a) einen den Daten entsprechenden Vertrag durchzusetzen und/oder (b) Revisionen an den Daten aufzuzeichnen und/oder (c) eine Datenherkunft durchzusetzen und/oder (d) die Daten zu verfolgen.

Beispiel 21 beinhaltet ein System zum Erzeugen eines Datenversorgungskettenobjekts, wobei die Einrichtung Folgendes umfasst: Mittel zum Ableiten einer Herkunft eines ersten Datenversorgungskettenobjekts und Identifizieren eines ersten Stakeholders aus der Herkunft; Mittel zum Bestimmen, ob der erste Stakeholder verifiziert ist, und Nutzen von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert ist; und Mittel zum Aufbauen einer Tag-Wertstruktur basierend auf der Nutzung der Daten, Aufbauen eines zweiten Datenversorgungskettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders, und Hinzufügen des zweiten Datenversorgungskettenobjekts zu der Datenversorgungskette.

Beispiel 22 beinhaltet das System des Beispiels 21, das weiter Mittel zum Übertragen der Daten und des zweiten Datenversorgungskettenobjekts zu einer Vorrichtung, die Zugriff auf die Daten angefordert hat, beinhaltet.

Beispiel 23 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 21 und/oder 22 und beinhaltet optional das Mittel zum Ableiten, um die Herkunft basierend auf einer vertrauenswürdigen Drittpartei-Datenschutzfunktion abzuleiten.

Beispiel 24 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 21 bis 23 und beinhaltet optional Mittel zum Auswählen der zweiten Stakeholder-Identität basierend auf einer selbstsouveränen Identifikation.

Beispiel 25 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 21 bis 24 und beinhaltet optional, dass die selbstsouveräne Identifikation von dem zweiten Stakeholder entwickelt wird.

Beispiel 26 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 21 bis 25 und beinhaltet optional das Mittel zum Auswählen, um einen zentralen Bestand zu umgehen, um die zweite Stakeholder-Identität auszuwählen.

Beispiel 27 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 21 bis 26 und beinhaltet optional das Mittel zum Auswählen, um die Priorität der selbstsouveränen Identifikation gegenüber dem zweiten Stakeholder zu verifizieren.

Beispiel 28 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 21 bis 27 und beinhaltet optional, dass die selbstsouveräne Identifikation eine erste selbstsouveräne Identifikation ist, und das Mittel zum Auswählen, um eine zweite selbstsouveräne Identifikation auszuwählen, wenn dem zweiten Stakeholder Priorität gegenüber der ersten selbstsouveränen Identifikation fehlt.

Beispiel 29 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 21 bis 28 und beinhaltet optional Mittel zum Übertragen der selbstsouveränen Identifikation und der Tag-Wertstruktur zu einer oder mehreren anderen Vorrichtungen zum Bewerten der Nomenklatur der selbstsouveränen Identifikation und der Tag-Wertstruktur.

Beispiel 30 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 21 bis 29 und beinhaltet optional Mittel zum Übertragen des zweiten Datenversorgungskettenobjekts zu einer Blockchain und/oder einem Objektüberwachungsdienst, um (a) einen den Daten entsprechenden Vertrag durchzusetzen und/oder (b) Revisionen an den Daten aufzuzeichnen und/oder (c) Datenherkunft durchzusetzen und/oder (d) die Daten zu verfolgen.

Beispiel 31 beinhaltet eine Einrichtung zum Erzeugen eines Datenversorgungskettenobjekts, wobei die Vorrichtung Folgendes umfasst: Prozessorschaltungen; und einen Speicher, der Anweisungen beinhaltet, die, wenn sie ausgeführt werden, die Prozessorschaltungen zu Folgendem veranlassen: Ableiten einer Herkunft eines ersten Datenversorgungskettenobjekts; Identifizieren eines ersten Stakeholders aus der Herkunft; Bestimmen, ob der erste Stakeholder verifiziert ist; Nutzen von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert ist; Aufbauen einer Tag-Wertstruktur basierend auf der Nutzung der Daten; Aufbauen eines zweiten Datenversorgungskettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders; und Hinzufügen des zweiten Datenversorgungskettenobjekts zu der Datenversorgungskette.

Beispiel 32 beinhaltet die Einrichtung des Beispiels 31, wobei die Anweisungen bewirken, dass die Prozessorschaltungen die Daten und das zweite Datenversorgungskettenobjekt zu einer Vorrichtung übertragen, die Zugriff auf die Daten angefordert hat.

Beispiel 33 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 31 und/oder 32 und beinhaltet optional die Anweisungen, die bewirken, dass die Prozessorschaltungen die Herkunft basierend auf einer vertrauenswürdigen Drittpartei-Datenschutzfunktion ableiten.

Beispiel 34 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 31 bis 33 und beinhaltet optional die Anweisungen, die bewirken, dass die Prozessorschaltungen die zweite Stakeholder-Identität basierend auf einer selbstsouveränen Identifikation auswählen.

Beispiel 35 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 31 bis 34 und beinhaltet optional, dass die selbstsouveräne Identifikation von den zweiten Stakeholdern entwickelt wird.

Beispiel 36 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 31 bis 35 und beinhaltet optional die Anweisungen, die bewirken, dass die Prozessorschaltungen einen zentralen Bestand umgehen, um die zweite Stakeholder-Identität auszuwählen.

Beispiel 37 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 31 bis 36 und beinhaltet optional die Anweisungen, die bewirken, dass die Prozessorschaltungen die Priorität der selbstsouveränen Identifikation für den zweiten Stakeholder verifizieren.

Beispiel 38 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 31 bis 37 und beinhaltet optional, dass die selbstsouveräne Identifikation eine erste selbstsouveräne Identifikation ist und die Anweisungen bewirken, dass die Prozessorschaltungen eine zweite selbstsouveräne Identifikation auswählen, wenn dem zweiten Stakeholder Priorität gegenüber der ersten selbstsouveränen Identifikation fehlt.

Beispiel 39 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 31 bis 38 und beinhaltet optional die Anweisungen, die bewirken, dass die Prozessorschaltungen die selbstsouveräne Identifikation und die Tag-Wertstruktur zu einer oder mehreren anderen Vorrichtungen zur Bewertung der Nomenklatur der selbstsouveränen Identifikation und der Tag-Wertstruktur übertragen.

Beispiel 40 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 31 bis 39 und beinhaltet optional die Anweisungen, die bewirken, dass die Prozessorschaltungen das zweite Datenversorgungskettenobjekt zu einer Blockchain und/oder einem Objektüberwachungsdienst übertragen, um (a) einen Vertrag, der den Daten entspricht, durchzusetzen, (b) Revisionen an den Daten aufzuzeichnen, (c) Datenherkunft durchzusetzen oder (d) die Daten zu verfolgen.

Beispiel 41 beinhaltet ein Verfahren zum Erzeugen eines Datenversorgungskettenobjekts, wobei das Verfahren Folgendes umfasst: Ableiten, durch Ausführen einer Anweisung mit einem Prozessor, einer Herkunft eines ersten Datenversorgungskettenobjekts; Identifizieren, durch Ausführen einer Anweisung mit dem Prozessor, eines ersten Stakeholders aus der Herkunft; Bestimmen, durch Ausführen einer Anweisung mit dem Prozessor, ob der erste Stakeholder verifiziert ist; Nutzen durch Ausführen einer Anweisung mit dem Prozessor, von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert ist; Aufbauen durch Ausführen einer Anweisung mit dem Prozessor einer Tag-Wertstruktur basierend auf der Nutzung der Daten; Aufbauen durch Ausführen einer Anweisung mit dem Prozessor eines zweiten Datenversorgungskettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders; und Hinzufügen durch Ausführen einer Anweisung mit dem Prozessor des zweiten Datenversorgungskettenobjekts zu der Datenversorgungskette.

Beispiel 42 beinhaltet das Verfahren des Beispiels 41, das weiter das Übertragen der Daten und des zweiten Datenversorgungskettenobjekts zu einer Vorrichtung, die Zugriff auf die Daten angefordert hat, beinhaltet.

Beispiel 43 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 41 und/oder 42 und beinhaltet optional Ableiten, durch Ausführen einer Anweisung mit dem Prozessor, der Bereitstellung basierend auf einer vertrauenswürdigen Drittpartei-Datenschutzfunktion.

Beispiel 44 beinhaltet den Gegenstand von einem oder mehreren der Beispiele 41 bis 43 und beinhaltet optional Auswählen durch Ausführen einer Anweisung mit dem Prozessor der zweiten Stakeholder-Identität basierend auf einer selbstsouveränen Identifikation.

Beispiel 45 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 41 bis 44 und beinhaltet optional, dass die selbstsouveräne Identifikation von dem zweiten Stakeholder entwickelt wird.

Beispiel 46 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 41 bis 45 und beinhaltet optional Umgehen eines zentralen Bestands, um die zweite Stakeholder-Identität auszuwählen.

Beispiel 47 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 41 bis 46 und beinhaltet optional durch Ausführen einer Anweisung mit dem Prozessor Verifizieren der Priorität der selbstsouveränen Identifikation gegenüber dem zweiten Stakeholder.

Beispiel 48 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 41 bis 47 und beinhaltet optional, dass die selbstsouveräne Identifikation eine erste selbstsouveräne Identifikation ist, wobei das Verfahren weiter Auswählen durch Ausführen einer Anweisung mit dem Prozessor, einer zweiten selbstsouveränen Identifikation beinhaltet, wenn dem zweiten Stakeholder Priorität gegenüber der ersten selbstsouveränen Identifikation fehlt.

Beispiel 49 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 41 bis 48 und beinhaltet optional Übertragen der selbstsouveräne Identifikation und der Tag-Wertstruktur zu einer oder mehreren anderen Vorrichtungen zur Bewertung der Nomenklatur der selbstsouveräne Identifikation und der Tag-Wertstruktur.

Beispiel 50 beinhaltet den Gegenstand eines oder mehrerer der Beispiele 41 bis 49 und beinhaltet optional Übertragen des zweiten Datenversorgungskettenobjekts zu einer Blockchain und/oder einem Objektüberwachungsdienst, um (a) einen Vertrag, der den Daten entspricht, durchzusetzen und/oder (b) Revisionen an den Daten aufzuzeichnen und/oder (c) Datenherkunft durchzusetzen und/oder (d) die Daten zu verfolgen.

Beispiel 51 ist ein Edge-Computing-Gateway, das Verarbeitungsschaltungen zum Ausführen eines beliebigen der Beispiele 41 bis 50 umfasst.

Beispiel 52 ist eine Basisstation, die eine Netzwerkschnittstellenkarte und Verarbeitungsschaltungen zum Ausführen eines beliebigen der Beispiele 4 bis 50 umfasst.

Beispiel 53 ist ein computerlesbares Medium, das Anweisungen zum Ausführen eines der Beispiele 41 bis 50 umfasst.

Obwohl bestimmte beispielhafte Verfahren, Einrichtungen und Herstellungsartikel hierin offenbart wurden, ist der Schutzumfang dieses Patents nicht darauf beschränkt. Vielmehr deckt dieses Patent alle Verfahren, Einrichtungen und Herstellungsartikel, die angemessen in den Schutzumfang der Ansprüche dieses Patents fallen.

Die folgenden Ansprüche werden hiermit durch Bezugnahme in diese ausführliche Beschreibung aufgenommen, wobei jeder Anspruch allein als eine separate Ausführungsform der vorliegenden Offenbarung steht.

Claims

Nichtflüchtiges computerlesbares Speichermedium, das Daten umfasst, die in ausführbare Anweisungen konfiguriert sein können und, wenn sie konfiguriert und ausgeführt werden, bewirken, dass ein oder mehrere Prozessoren mindestens Folgendes ausführen: Ableiten einer Herkunft eines ersten Datenversorgungskettenobjekts; Identifizieren eines ersten Stakeholders aus der Herkunft; Bestimmen, ob der erste Stakeholder verifiziert ist; Nutzen von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert wird; Aufbauen einer Tag-Wertstruktur basierend auf der Nutzung der Daten; Aufbauen eines zweiten Datenversorgungskettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders; und Hinzufügen des zweiten Datenversorgungskettenobjekts zu der Datenversorgungskette.
Computerlesbares Speichermedium nach Anspruch 1, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Daten und das zweite Datenversorgungskettenobjekt zu einer Vorrichtung, die Zugriff auf die Daten angefordert hat, übertragen.
Computerlesbares Speichermedium nach einem der vorhergehenden Ansprüche, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Herkunft basierend auf einer vertrauenswürdigen Drittpartei-Schutzfunktion ableiten.
Computerlesbares Speichermedium nach einem der vorhergehenden Ansprüche, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die zweite Stakeholder-Identität basierend auf selbstsouveräner Identifikation auswählen.
Computerlesbares Speichermedium nach Anspruch 4, wobei die selbstsouveräne Identifikation von dem zweiten Stakeholder entwickelt wird.
Computerlesbares Speichermedium nach Anspruch 4 oder 5, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren einen zentralen Bestand umgehen, um die zweite Stakeholder-Identität auszuwählen.
Computerlesbares Speichermedium nach einem der Ansprüche 4-6, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Priorität der selbstsouveränen Identifikation für den zweiten Stakeholder verifizieren.
Computerlesbares Speichermedium nach Anspruch 7, wobei die selbstsouveräne Identifikation eine erste selbstsouveräne Identifikation ist, und die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren eine zweite selbstsouveräne Identifikation auswählen, wenn dem zweiten Stakeholder Priorität gegenüber der ersten selbstsouveränen Identifikation fehlt.
Computerlesbares Speichermedium nach einem der Ansprüche 4-8, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die selbstsouveräne Identifikation und die Tag-Wertstruktur zu einer oder mehreren anderen Vorrichtungen zur Bewertung der Nomenklatur der selbstsouveränen Identifikation und der Tag-Wertstruktur übertragen.
Computerlesbares Speichermedium nach einem der vorhergehenden Ansprüche, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren das zweite Datenversorgungskettenobjekt zu einer Blockchain und/oder einem Objektüberwachungsdienst senden, um (a) einen Vertrag, der den Daten entspricht, durchzusetzen und/oder (b) Revisionen an den Daten aufzuzeichnen und/oder (c) einen Datenherkunft durchzusetzen und/oder (d) die Daten zu verfolgen.
System zum Erzeugen eines Datenversorgungskettenobjekts, wobei die Einrichtung Folgendes umfasst: einen Vertrauensankergenerator zum: Ableiten einer Herkunft eines ersten Datenversorgungskettenobjekts; und Identifizieren eines ersten Stakeholders aus der Herkunft; einen Objektprozessor zum: Bestimmen, ob der erste Stakeholder verifiziert ist; und Nutzen von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert wird; und einen Datenstrukturgenerator zum: Aufbauen einer Tag-Wertstruktur basierend auf der Nutzung der Daten; Aufbauen eines zweiten Datenversorgungskettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders; und Hinzufügen des zweiten Datenversorgungskettenobjekts zu der Datenversorgungskette.
System nach Anspruch 11, das weiter eine Netzwerkschnittstelle zum Übertragen der Daten und des zweiten Datenversorgungskettenobjekts zu einer Vorrichtung beinhaltet, die einen Zugriff auf die Daten angefordert hat.
System nach Anspruch 11 oder 12, wobei der Vertrauensankergenerator dazu dient, die Herkunft basierend auf einer vertrauenswürdigen Drittpartei-Datenschutzfunktion abzuleiten.
System nach einem der Ansprüche 11-13, das weiter einen Proxy-Generator zum Auswählen der zweiten Stakeholder-Identität basierend auf einer selbstsouveränen Identifikation beinhaltet.
System nach Anspruch 14, wobei die selbstsouveräne Identifikation von dem zweiten Stakeholder entwickelt wird.
System nach Anspruch 14 oder 15, wobei der Proxy-Generator einen zentralen Bestand umgehen soll, um die zweite Stakeholder-Identität auszuwählen.
System nach einem der Ansprüche 14-16, wobei der Proxy-Generator dazu dient, die Priorität der selbstsouveränen Identifikation für den zweiten Stakeholder zu verifizieren.
System nach Anspruch 17, wobei die selbstsouveräne Identifikation eine erste selbstsouveräne Identifikation ist, und der Proxy-Generator eine zweite selbstsouveräne Identifikation auswählen soll, wenn dem zweiten Stakeholder Priorität gegenüber der ersten selbstsouveränen Identifikation fehlt.
System nach einem der Ansprüche 14-18, das weiter eine Netzwerkschnittstelle zum Übertragen der selbstsouveränen Identifikation und der Tag-Wertstruktur zu einer oder mehreren anderen Vorrichtungen zur Bewertung der Nomenklatur der selbstsouveränen Identifikation und der Tag-Wertstruktur beinhaltet.
System nach einem der Ansprüche 11-19, das weiter eine Netzwerkschnittstelle zum Übertragen des zweiten Datenversorgungskettenobjekts zu einer Blockchain und/oder einem Objektüberwachungsdienst zum (a) Durchsetzen eines Vertrags, der den Daten entspricht, und/oder (b) Aufzeichnen von Revisionen an den Daten und/oder (c) Durchsetzen einer Daten Herkunft und/oder (d) Verfolgen der Daten beinhaltet.
System zum Erzeugen eines Datenversorgungskettenobjekts, wobei die Einrichtung Folgendes umfasst: Mittel zum Ableiten einer Herkunft eines ersten Datenversorgungskettenobjekts und Identifizieren eines ersten Stakeholders aus der Herkunft; Mittel zum Bestimmen, ob der erste Stakeholder verifiziert ist, und Nutzen von Daten, die mit der Datenversorgungskette assoziiert sind, wenn der erste Stakeholder verifiziert ist; und Mittel zum Aufbauen einer Tag-Wertstruktur basierend auf der Nutzung der Daten, Aufbauen eines zweiten Datenversorgungskettenobjekts basierend auf der Tag-Wertstruktur und einer Identität eines zweiten Stakeholders, und Hinzufügen des zweiten Datenversorgungskettenobjekts zu der Datenversorgungskette.
System nach Anspruch 21, wobei das Mittel zum Ableiten die Herkunft basierend auf einer vertrauenswürdigen Drittpartei-Datenschutzfunktion ableiten soll.
System nach Anspruch 21 oder 22, das ferner Mittel zum Auswählen eines Durchführens des Folgenden beinhaltet: Auswählen der zweiten Stakeholder-Identität basierend auf einer selbstsouveränen Identifikation, wobei die selbstsouveräne Identifikation von dem zweiten Stakeholder entwickelt wird, Umgehen eines zentralen Bestands, um die zweite Stakeholder-Identität auszuwählen; und Verifizieren der Priorität der selbstsouveränen Identifikation gegenüber dem zweiten Stakeholder.
System nach Anspruch 23, wobei die selbstsouveräne Identifikation eine erste selbstsouveräne Identifikation ist, und das Mittel zum Auswählen eine zweite selbstsouveräne Identifikation auswählen soll, wenn dem zweiten Stakeholder Priorität gegenüber der ersten selbstsouveränen Identifikation fehlt.
System nach einem der Ansprüche 21-24, das weiter Mittel zum Übertragen des zweiten Datenversorgungskettenobjekts zu einer Blockchain und/oder einem Objektüberwachungsdienst beinhaltet, um (a) einen Vertrag, der den Daten entspricht, durchzusetzen und/oder (b) Revisionen an den Daten aufzuzeichnen und/oder (c) Datenherkunft durchzusetzen und/oder (d) die Daten zu verfolgen.