Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
LOCATION-BASED CONTENT MANAGEMENT METHOD FOR OUTPUTTING DIGITAL CONTENT TO A USER, AND LOCATION-BASED CONTENT MANAGEMENT SYSTEM
Document Type and Number:
WIPO Patent Application WO/2023/180280
Kind Code:
A1
Abstract:
The invention relates to a location-based, preferably decentralised, content management method at least for outputting digital content (Content, 10) to a user (12), comprising at least the method steps (82, 84, 86) of: - determining a location of the user (12); - ascertaining a virtually prescribed digital content (10) in the region (14) of the location of the user (12); - providing the digital content (10) for retrieval by the user (12). It is proposed that the digital content (10) is provided by at least one smart contract (18) based on a, preferably decentralised, digital ledger technology (DLT, 16), such as a blockchain or a tangle.

Inventors:
BÖNISCH BENJAMIN (DE)
Application Number:
PCT/EP2023/057137
Publication Date:
September 28, 2023
Filing Date:
March 21, 2023
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ETO GRUPPE TECH GMBH (DE)
International Classes:
G06Q20/12; G06Q20/22; G06Q30/0601; H04L9/00
Domestic Patent References:
WO2018213672A12018-11-22
Foreign References:
US20210279695A12021-09-09
US20200193717A12020-06-18
US20200036533A12020-01-30
KR20200077681A2020-07-01
US20130083011A12013-04-04
DE102021112613A12022-06-23
Attorney, Agent or Firm:
DAUB, Thomas (DE)
Download PDF:
Claims:
Ansprüche

1 . Ortsbezogenes, vorzugsweise dezentrales, Content Management Verfahren zumindest zur Ausgabe von digitalen Inhalten (Content, 10) an einen Nutzer (12), umfassend zumindest die Verfahrensschritte (82, 84, 86)

- Bestimmung einer Lokalisation des Nutzers (12)

- Ermitteln eines im Bereich (14) der Lokalisation des Nutzers (12) virtuell verordneten digitalen Inhalts (10)

- Bereitstellen des digitalen Inhalts (10) für einen Abruf an den Nutzer (12), dadurch gekennzeichnet, dass die Bereitstellung des digitalen Inhalts (10) über zumindest einen auf eine, vorzugsweise dezentrale, Digital Ledger Technologie (DLT, 16), wie z.B. eine Blockchain oder einen Tangle, aufgesetzten Smart Contract (18) erfolgt.

2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass ein Willen zum Abruf des digitalen Inhalts (10) durch ein Senden einer DLT- Transaktion (20) an eine Eingabefunktion („write function“) des Smart Contracts (18), insbesondere mittels eines dem Nutzer (12) zugeordneten Schnittstellengeräts (22), kundgetan wird.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der DLT- Transaktion (20) an die Eingabefunktion, insbesondere zusätzlich zu den Aufrufparametern für die Eingabefunktion, zumindest ein digitales Asset, wie z.B. eine Nachricht, eine Information oder ein DLT-Token, beigefügt ist. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass eine Freigabe des digitalen Inhalts (10) durch eine DLT-Antworttransaktion (26) des Smart Contracts (18) zumindest ausgelöst wird. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Freigabe des digitalen Inhalts (10) spezifisch für zumindest ein Schnittstellengerät (22) erfolgt, welchem eine D LT- Empfangsadresse der DLT-Antworttransaktion (26) zugeordnet ist oder welchem eine DLT- Adresse zugeordnet ist, die in der DLT-Antworttransaktion (26) spezifiziert ist. Verfahren nach einem der Ansprüche 4 oder 5, dadurch gekennzeichnet, dass die DLT-Antworttransaktion (26) von zumindest einer DLT-Antwort-Begleittransaktion (28, 34, 36, 40), insbesondere des Smart Contracts (18), flankiert wird, welche zumindest ein Versenden zumindest eines digitalen Assets, wie z.B. einer Nachricht, einer Information oder eines DLT-Tokens, an zumindest eine, insbesondere nicht dem Nutzer (12) mit dem Abrufwillen zugeordnete, D LT- Drittadresse umfasst. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass zumindest eine D LT- Drittadresse, die Ziel zumindest einer DLT-Antwort- Begleittransaktion (28) ist, einem Urheber (30) zumindest eines Teils des digitalen Inhalts (10) zugeordnet ist. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass zumindest eine DLT-Drittadresse, die Ziel zumindest einer DLT-Antwort- Begleittransaktion (34) ist, einem Verwalter (32) und/oder Bereitsteiler des digitalen Inhalts (10) zugeordnet ist. 9. Verfahren nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass zumindest eine DLT-Drittadresse, die Ziel zumindest einer DLT- Antwort-Begleittransaktion (36) ist, einem Inhaber und/oder Produzenten (38) der den Nutzern (12) zuordenbaren Schnittstellengeräte (22) zugeordnet ist.

10. Verfahren nach einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, dass zumindest eine DLT-Drittadresse, die Ziel zumindest einer DLT- Antwort-Begleittransaktion (40) ist, zumindest einem weiteren Smart Contract (42) zugeordnet ist.

11 . Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass durch die DLT-Antwort-Begleittransaktion (40) eine Eingabefunktion des weiteren Smart Contracts (42) ausgeführt wird.

12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Willen zum Einstellen eines, insbesondere nach dem Einstellen zum Abruf bereitgestellten, digitalen Inhalts (10) durch ein Senden einer DLT-Transaktion (44) an eine weitere Eingabefunktion des Smart Contracts (18), insbesondere mittels eines einem Urheber (30) und/oder Einsteller zugeordneten Schnittstellengeräts (46), kundgetan wird.

13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die bereitgestellten digitalen Inhalte (10) mit einem Non-Fungible Token (NFT) der DLT (16) verknüpft werden.

14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zumindest ein Teil der bereitgestellten digitalen Inhalte (10) dezentral, z.B. in der DLT (16), abgespeichert werden. 15. Ortsbezogenes, vorzugsweise dezentrales, Content Management Verfahren zumindest zu einer räumlich organisierten Aufnahme von digitalen Inhalten (Content, 10), die von Urhebern (30) und/oder Erstellern zur Verfügung gestellt werden, in ein ortsbezogenes, insbesondere dezentrales, Content Management System (CMS, 48), wobei ein realer dreidimensionaler Aufnahmeraum (104) für digitale Inhalte (10) virtuell in eine Vielzahl an nebeneinander und übereinander angeordneten Volumensegmenten (106, 108) unterteilt wird, wobei jedem der Volumensegmente (106, 108) eine eineindeutige DLT- Adresse einer, vorzugsweise dezentralen, Digital Ledger Technologie (DLT, 16), wie z.B. einer Blockchain oder einem Tangle, zugeordnet wird, und wobei jeder der digitalen Inhalte (10) bei dem Einstellen mit zumindest einer der, einem der Volumensegmente (106, 108) zugeordneten DLT- Adressen verknüpft wird.

16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass jeder der digitalen Inhalte (10) mit zumindest einem auf die DLT (16) aufgesetzten Smart Contract (18) verknüpft wird, wobei eine Bereitstellung des digitalen Inhalts (10) an Nutzer (12) über den zumindest einen Smart Contract (18) erfolgt, vorzugsweise mittels eines Verfahrens nach einem der Ansprüche 1 bis14.

17. Verfahren nach Anspruch 15 oder 16, dadurch gekennzeichnet, dass der reale dreidimensionale Aufnahmeraum (104) weltkugelumspannend ausgebildet ist.

18. Verfahren nach einem der Ansprüche 15 bis 17, dadurch gekennzeichnet, dass die den Volumensegmenten (106, 108) zugeordneten DLT-Adressen zusätzlich Zeitintervallen zugeordnet sind. Ortsbezogenes, insbesondere dezentrales, Content Management System (CMS, 48), zumindest zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche. CMS (48) nach Anspruch 19, aufweisend zumindest ein Lokalisierungsgerät (50) zu einer Bestimmung einer Momentanposition des Nutzers (12) des Lokalisierungsgeräts (50) und zumindest ein Schnittstellengerät (22, 46) zur Kommunikation mit der DLT (16). CMS (48) nach Anspruch 20, gekennzeichnet durch ein Inhalte- Erstellungsgerät (52), welches verschieden von dem Lokalisierungsgerät (50) und verschieden von dem Schnittstellengerät (22, 46) ausgebildet ist. CMS (48) nach einem der Ansprüche 20 oder 21 , gekennzeichnet durch ein Inhalte-Abspielgerät (54), welches verschieden von dem Lokalisierungsgerät (50) und verschieden von dem Schnittstellengerät (22, 46) ausgebildet ist. CMS (48) nach den Ansprüchen 21 und 22, dadurch gekennzeichnet, dass das Inhalte-Erstellungsgerät (52) mit dem Inhalte-Abspielgerät (54) identisch ist. CMS (48) nach einem der Ansprüche 20 bis 23, dadurch gekennzeichnet, dass das Lokalisierungsgerät (50) mit dem Schnittstellengerät (22) identisch ist. CMS (48) nach einem der Ansprüche 20 bis 24, gekennzeichnet durch eine oder mehrere Ankerstationen (56), welche eine von Navigationssatellitensystemen unabhängige Bestimmung einer Lokalisation des Nutzers (12) und/oder der virtuell verordneten digitalen Inhalte (10), z.B. durch lokale Triangulation oder durch lokale Time-of- flight-Messungen, ermöglichen.

Description:
Ortsbezogenes Content Management Verfahren zur Ausgabe von digitalen Inhalten an einen Nutzer und ortsbezogenes Content Management System

Stand der Technik

Die Erfindung betrifft ein Verfahren nach dem Oberbegriff des Anspruchs 1 , ein Verfahren nach dem Anspruch 15 und ein System nach dem Oberbegriff des Anspruchs 19.

Es sind bereits Augmented Reality Systeme vorgeschlagen worden, welche auf einer Interaktion mit einem zentralen Server oder einer Cloud beruhen.

Die Aufgabe der Erfindung besteht insbesondere darin, eine gattungsgemäße Vorrichtung mit vorteilhaften Eigenschaften hinsichtlich einer Vielseitigkeit und/oder einer Benutzerfreundlichkeit bereitzustellen. Die Aufgabe wird erfindungsgemäß durch die Merkmale der Patentansprüche 1 , 15 und 19 gelöst, während vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung den Unteransprüchen entnommen werden können.

Vorteile der Erfindung

Die Erfindung geht aus von einem, insbesondere computerimplementierten, ortsbezogenen, vorzugsweise dezentralen, Content Management Verfahren zumindest zur Ausgabe von digitalen Inhalten (Content) an einen Nutzer, umfassend zumindest die Verfahrensschritte: a) Bestimmung einer Lokalisation des Nutzers; b) Ermitteln eines im Bereich der Lokalisation des Nutzers virtuell verordneten digitalen Inhalts und c) Bereitstellen des, insbesondere in dem Bereich der Lokalisation des Nutzers virtuell verordneten, digitalen Inhalts für einen Abruf an den Nutzer, insbesondere zumindest für den Zeitraum, in dem der digitale Inhalt sich in dem Bereich der Lokalisation des Nutzers befindet.

Es wird vorgeschlagen, dass die Bereitstellung des digitalen Inhalts über zumindest einen auf eine, vorzugsweise dezentrale, Digital Ledger Technologie (DLT), wie z.B. eine Blockchain oder einen Tangle, aufgesetzten Smart Contract erfolgt. Dadurch kann vorteilhaft eine besonders hohe Vielseitigkeit erreicht werden, insbesondere indem eine Vielzahl individuell angepasster Smart Contracts eingesetzt werden kann. Zudem kann vorteilhaft eine hohe Benutzerfreundlichkeit erreicht werden, insbesondere indem eine besonders hohe Transparenz hinsichtlich der Herkunft von Inhalten und/oder hinsichtlich Vergütungsströmen erreicht werden kann, insbesondere dann wenn der Smart Contract auf einer öffentlichen, vorzugsweise verteilten, DLT aufgesetzt ist. Zudem kann vorteilhaft eine Dezentralität erreicht werden, wodurch eine Anfälligkeit für Systemausfälle vorteilhaft reduziert werden kann. Vorteilhaft kann eine direkte Umsetzung eines Content Management Verfahrens erreicht werden, welche frei ist von Intermediären, insbesondere bei der Vergütung von Leistungen und/oder bei dem Teilen von Inhalten. Dadurch kann vorteilhaft eine hohe Effizienz, insbesondere Kosteneffizienz und/oder Energieeffizienz erreicht werden. Vorteilhaft können insbesondere durch die Verwendung von Smart Contracts sichere direkte Interaktionen/Transaktionen zwischen Parteien, die sich nicht kennen und entsprechend noch kein Vertrauen zueinander aufgebaut haben, ermöglicht werden. Dadurch kann vorteilhaft auf einen Intermediär, wie eine Bank oder einen Datenbankverwalter, verzichtet werden. Vorteilhaft bedarf es keiner Vertragsabschlüsse oder damit verbundener vertraglicher Verpflichtungen zwischen den Teilnehmern des Content Management Verfahrens.

In einem ortsbezogenen Content Management Verfahren werden insbesondere Inhalte gemanagt, also z.B. bereitgestellt, welche, insbesondere virtuell, mit einer Ortskoordinate verknüpft sind. Das Content Management Verfahren ist vorzugsweise auch zu einer Aufnahme von digitalen Inhalten in ein Content Management System (CMS) vorgesehen. Ein digitaler Inhalt kann als eine digitale Bilddatei, eine digitale Videodatei, eine digitale Sounddatei, eine digitale Zeichenfolge, ein digitaler Schlüssel, ein digitales Computerprogramm (App) oder dergleichen ausgebildet sein. Insbesondere ist das Content Management Verfahren dazu vorgesehen, den digitalen Inhalt derart bereitzustellen, dass dieser von einem Abspielgerät des Nutzers abgespielt werden kann. Die Bestimmung der Lokalisation des Nutzers kann mittels einer Ortungsfunktion des Abspielgeräts des Nutzers oder eines weiteren Geräts des Nutzers, z.B. eines Schnittstellengeräts des Nutzers, erfolgen. Denkbar sind z.B. eine globale Ortung unter Verwendung von Navigationssatellitensystemen, wie GPS, etc., oder eine lokale Ortung unter Verwendung von, von Navigationssatellitensystemen unabhängigen Ortungsmethoden wie einer lokalen Triangulation mit Ankerstationen, z.B. über Ultrabreitband (UWB)-Signale, o.ä. oder einer lokalen Time-of-flight-Messung, etc. Die Bestimmung der im Bereich der Lokalisation des Nutzers virtuell verordneten digitalen Inhalte kann über einen Abgleich von der für den Nutzer momentan bestimmten Lokalisation / Ortskoordinate mit den jeweiligen Ortskoordinaten, die den digitalen Inhalten, insbesondere des CMS, zugeordnet sind, erfolgen. Der Bereich kann dabei variabel festgelegt werden. Sinnvolle Bereichsgrößen können beispielsweise durch Kreise mit Durchmessern zwischen 0,5 m und 10 m (z.B. 0,5 m, 1 m, 1 ,5 m, 2 m, 2,5 m, 3 m, 4 m, 5 m, 6 m, 7 m, 8 m, 9 m, 10 m) um die momentan ermittelte Lokalisation des Nutzers gebildet sein. Für bestimmte Anwendungen, wie z.B. Stadttouren, sind auch noch weitaus größere Bereiche von mehreren 10 m oder sogar 100 m denkbar. Wenn in dem festgelegten Bereich nun ein oder mehrere digitale Inhalte aufgefunden werden, können diese dem Nutzer zur Auswahl, z.B. in einem Dropdown-Menü einer Datenbrille, angezeigt werden. Digitale Inhalte, die dem Nutzer zur Auswahl angezeigt werden, können von dem Nutzer an dem Ort, an dem sich der Nutzer momentan befindet, abgespielt werden. Dabei ist denkbar, dass die digitalen Inhalte wieder aus der dem Nutzer zur Verfügung gestellten Auswahl entfernt werden, wenn sich der Nutzer von der Ortskoordinate des digitalen Inhalts entfernt, insbesondere wenn sich der digitale Inhalt nicht mehr in dem ortsveränderten Bereich der Lokalisation des Nutzers befindet. Alternativ ist denkbar, dass der Nutzer alle digitalen Inhalte, die sich einmal in dem Bereich der Lokalisation des Nutzers befanden, „einsammelt“ und für einen späteren, ggf. zeitlich begrenzten Abruf, bereitgestellt werden. Zudem ist denkbar, dass die digitalen Inhalte gerankt sind bzw. gerankt angezeigt werden. Beispielsweise können die digitalen Inhalte in Abhängigkeit von Nutzer-Bewertungen, z.B. einer Anzahl an „Likes“ oder einer durch Nutzer vergebenen Punktezahl sortiert dargestellt werden. Insbesondere könnten höher gerankte digitale Inhalte bevorzugt oder vergrößert oder speziell markiert angezeigt werden.

Darunter, dass die Bereitstellung des digitalen Inhalts über einen Smart Contract erfolgt, soll insbesondere verstanden werden, dass vor einem Aufrufen oder Abspielen des digitalen Inhalts eine Interaktion des Nutzers mit einem Smart Contract erfolgt. Dabei kann ein Smart Contract die Bereitstellung mehrerer digitaler Inhalte organisieren / verwalten oder es kann jedem digitalen Inhalt oder Teilmengen aller digitalen Inhalte ein eigener, insbesondere individueller, Smart Contract zugeordnet sein. Insbesondere entscheidet ein Resultat der Interaktion mit dem Smart Contract darüber, ob der digitale Inhalt für den Nutzer zur Verwendung bereitgestellt wird oder nicht. Vorzugsweise ist der Smart Contract auf eine DLT aufgesetzt, die auf einer Directed Acyclic Graph-Architektur (DAG) beruht, wie z.B. IOTA™. Vorteilhaft ist der Smart Contract auf eine DLT aufgesetzt, die frei oder nahezu frei von Transaktionskosten ist. Vorteilhaft ist der Smart Contract auf eine DLT aufgesetzt, die zumindest im Wesentlichen frei von einer Begrenzung eines Transaktionsdurchsatzes ist. Alternativ sind jedoch auch andere DLT denkbar, z.B. Smart Contract fähige Blockchains wie Ethereum, EOS, Stellar, Solana, Avalanche, Fantom, Cronos, Polygon, Algorand, Chainlink, Binance Smart Chain, u.v.m. Vorteilhaft ist der Smart Contract durch das Aufsetzen auf die DLT öffentlich einsehbar und unveränderbar.

Unter einem „Smart Contract“ soll insbesondere ein auf die DLT aufgesetzter Vertrag verstanden werden, welcher zumindest eine, vorzugsweise eine Mehrzahl an wenn/dann-Bedingungen als vorprogrammierte Funktionen umfasst, die aufgerufen werden können. Dazu werden dem Smart Contract insbesondere „wenn“-Bedingungen als Input bereitgestellt und der Smart Contract reagiert durch eine Ausgabe / Nicht-Ausgabe von „dann“-Resultaten. Insbesondere ist der Smart Contract als ein auf die DLT aufgesetzter Software Code ausgebildet. Insbesondere ist der Smart Contract durch das Aufsetzen auf die DLT unveränderlich ausgebildet. Insbesondere ist dem Smart Contract eine DLT- Adresse in der DLT zugeordnet. Insbesondere kann der Smart Contract aufgerufen werden, indem Transaktionen an die DLT-Adresse des Smart Contracts gesendet werden („write“). Insbesondere kann eine Ausführung des Smart Contracts eine Zahlung einer Gebühr erfordern, welche in Form von DLT- Token der DLT den Transaktionen, die den Smart Contract aufrufen, hinzugefügt werden. Insbesondere wird der Smart Contract nach einem Aufrufen von mehr als einem DLT-Knoten („Quorum“) der DLT ausgeführt, wobei eine Ausgabe des Resultats nur dann erfolgt, wenn alle Mitglieder des Quorums zum selben Ergebnis gelangen. Vorzugsweise führt der Smart Contract nach einem Empfangen einer von dem Nutzer ausgelösten DLT-Transaktion die folgenden Schritte aus: a) Verifizieren der Existenz der laut den mit der DLT-Transaktion empfangenen Informationen aufzurufenden Funktionen in dem Smart Contract, ggf. mit einer Plausibilitätsprüfung der Parameter, b) Verifizieren, ob ausreichend Gebühren in Form von DLT-Token empfangen wurden, ggf. überschüssige Gebühren werden zurückgesendet, c) Vorbereiten einer Transaktion an eine oder mehrere DLT-Adressen des DLT-Netzwerks, insbesondere zumindest an die DLT- Adresse, von der aus der Smart Contract aufgerufen wurde, wobei die Transaktion eine Zugriffserlaubnis auf den digitalen Inhalt oder den digitalen Inhalt (ggf. als Non-Fungible-Token, NFT) selbst umfasst und d) Ausführen der Transaktion. Wenn der digitale Inhalt als ein NFT ausgebildet ist, dann ist danach die DLT- Adresse, an die die Transaktion gerichtet war, die DLT-Besitzeradresse des neuen NFTs. Die DLT-Besitzeradresse ist der Entität (hier: dem Nutzer) zugeordnet, die den zu der DLT-Adresse (i.d.R. selbst ein Public Key der DLT, z.B.

0xEfcA6C6981 a448388780cbfefA72dc77C3F73e6b) zugehörigen Private Key kennt/besitzt. Dadurch ist die Entität insbesondere in der Lage alle DLT-Token, NFTs, etc., die der DLT-Besitzeradresse zugeordnet sind, innerhalb der DLT weiter zu versenden. Unter „vorgesehen“ soll insbesondere speziell programmiert, ausgelegt und/oder ausgestattet verstanden werden. Darunter, dass ein Objekt zu einer bestimmten Funktion vorgesehen ist, soll insbesondere verstanden werden, dass das Objekt diese bestimmte Funktion in zumindest einem Anwendungs- und/oder Betriebszustand erfüllt und/oder ausführt.

Ferner wird vorgeschlagen, dass, insbesondere in einem Anfrageschritt, ein Willen zum Abruf des digitalen Inhalts durch ein Senden einer DLT-Transaktion an eine Eingabefunktion („write function“) des Smart Contracts, insbesondere mittels des dem Nutzer zugeordneten Schnittstellengeräts, kundgetan wird. Dadurch kann vorteilhaft eine direkte, von Intermediären im Wesentlichen freie Bereitstellung der digitalen Inhalte ermöglicht werde. Beispielsweise wird in dem Anfrageschritt von einem dem Nutzer zugeordneten Gerät, z.B. der Schnittstelleneinheit, eine Aufforderung an den Smart Contract geschickt, einen bestimmten zuvor ausgewählten digitalen Inhalt (z.B. den Content #2145) an einen Inhaber einer bestimmten DLT-Adresse (z.B.

0xEfcA6C6981 a448388780cbfefA72dc77C3F73e6b) bereitzustellen. Die DLT Transaktion wird dabei insbesondere direkt von dem, dem Nutzer zugeordneten Gerät an den Smart Contract in der DLT gesandt. Die DLT-Transaktion umfasst dabei vorzugsweise mehrere Inputparameter / Aufrufparameter / digitale Assets, z.B. den Identifikator des gewünschten digitalen Inhalts und die DLT-Adressen, für die der digitale Inhalt angefordert wird, oder Zusatzinformationen über Beschränkungen bei der Wiedergabe / Vorgaben für die Wiedergabe des digitalen Inhalts, wie z.B. Sprache, Alter des Nutzers, Werbeerlaubnis, Werbepräferenz, Zustimmung zu Nutzungsbedingungen, Detailstufe des freigegebenen digitalen Inhalts etc. Falls die DLT nicht transaktionskostenfrei ist, umfasst die DLT- Transaktion dabei auch einen sogenannten „Gas-Fee“ bzw. die an die Eingabefunktion des Smart Contracts gesandte DLT-Transaktion ist dabei von dem Nutzer, der den digitalen Inhalt abrufen möchte, signiert. Dadurch kann vorteilhaft eine hohe Sicherheit der Transaktionen erreicht werden. Zudem wird vorgeschlagen, dass der DLT-Transaktion an die Eingabefunktion, insbesondere zusätzlich zu den Aufrufparametern für die Eingabefunktion, zumindest ein digitales Asset, wie z.B. eine Nachricht, eine Information oder ein DLT-Token, beigefügt ist. Dadurch kann vorteilhaft eine Interaktion zwischen den Partnern des Smart Contracts präzisiert und/oder optimiert werden. Beispielsweise kann vorteilhaft ein freigegebener Inhalt an durch den Nutzer gewünschte Rahmenparameter angepasst werden. Beispielsweise können digitale Inhalte in verschiedenen Sprachen, mit verschiedenen Detailstufen, für verschiedene Altersgruppen, mit verschiedenen Werbebeimischungen, etc. freigegeben werden. Der Nutzer kann vorteilhaft bei dem Aufrufen der Eingabefunktion(en) des Smart Contracts eine entsprechende Auswahl treffen. Dabei ist zudem denkbar, dass verschiedene Ausgaben des digitalen Inhalts mit verschiedenen Gebühren verbunden sind. Der Nutzer kann der Transaktion an die Eingabefunktion bereits die entsprechenden Gebühren in Form von DLT-Token beifügen, welche dann von dem Smart Contract an die entsprechenden berechtigten Empfänger verteilt werden. Die DLT-Token können als Kryptowährungs-Token, denen ein monetärer Wert zugeordnet ist, als NFTs, als Incentive-Token / Bewertungspunkte eines Bewertungs- und/oder Reputationssystems, als Gutschein-Token, oder als andere Arten von DLT-Token ausgebildet sein.

Weiterhin wird vorgeschlagen, dass eine Freigabe des digitalen Inhalts durch eine DLT-Antworttransaktion des Smart Contracts zumindest ausgelöst wird. Dadurch kann vorteilhaft eine direkte, von Intermediären im Wesentlichen freie Bereitstellung der digitalen Inhalte ermöglicht werden. Beispielsweise kann in der DLT-Antworttransaktion ein Schlüssel zur Entschlüsselung des digitalen Inhalts umfasst sein. Beispielsweise kann die DLT-Antworttransaktion eine Auffinde- und/oder Downloadadresse für den digitalen Inhalt enthalten. Beispielsweise kann die DLT-Antworttransaktion den digitalen Inhalt direkt enthalten. Beispielsweise kann die DLT-Antworttransaktion an die DLT oder an eine den digitalen Inhalt verwahrende Stelle geschickt werden, welche einem Besitzer einer bestimmten DLT-Adresse (z.B. die DLT-Adresse des Nutzers) Zugriff auf den digitalen Inhalt erlaubt. Weitere dem Fachmann bekannte Freigabearten, die insbesondere auch spezifisch nur für Besitzer bestimmter DLT Adressen beschränkt sein können, sind selbstverständlich denkbar. Zudem ist denkbar, dass die DLT-Antworttransaktion eine zeitliche Begrenzung der Freigabe des digitalen Inhalts umfasst. Die zeitliche Begrenzung könnte dabei als eine Art Countdown bis zum Ablauf der Freigabe, als festgelegter Endzeitpunkt der Freigabe oder als eine von zumindest einer weiteren externen Bedingung (z.B. einem Vorhandensein von digitalen Assets auf einem Krypto-Wallet, das der DLT-Adresse zugeordnet ist, für die auch die Freigabe gilt) abhängige dynamische Begrenzung ausgebildet sein.

Bevorzugt wird jedoch vorgeschlagen, dass die Freigabe des digitalen Inhalts spezifisch für zumindest ein Schnittstellengerät erfolgt, welchem eine DLT- Empfangsadresse der DLT-Antworttransaktion zugeordnet ist oder welchem eine DLT-Adresse zugeordnet ist, die in der DLT-Antworttransaktion spezifiziert ist. Dadurch kann vorteilhaft eine sichere direkte und gezielte Bereitstellung des digitalen Inhalts erreicht werden. Es ist denkbar, dass in der DLT- Antworttransaktion mehrere Adressen unterschiedlicher Schnittstellengeräte spezifiziert sind oder dass mehrere DLT-Antworttransaktionen in Reaktion auf das Aufrufen der Eingabefunktion an verschiedene Schnittstellengeräte versendet werden. Das Schnittstellengerät kann als ein Abspielgerät für digitale Inhalte, wie ein Smartphone oder eine Datenbrille ausgebildet sein, vorzugsweise ist das Abspielgerät jedoch verschieden von einem, insbesondere gewöhnlichen, Abspielgerät für digitale Inhalte ausgebildet, welches insbesondere jedoch eine Kommunikationsschnittstelle zu einer Kommunikation der digitalen Inhalte und/oder der Freigabe zu einem oder mehreren Abspielgeräten aufweist.

Des Weiteren wird vorgeschlagen, dass die DLT-Antworttransaktion von zumindest einer, insbesondere automatischen, DLT-Antwort-Begleittransaktion, insbesondere des Smart Contracts, flankiert wird, welche zumindest ein Versenden und/oder Weiterleiten zumindest eines digitalen Assets, wie z.B. einer Nachricht, einer Information oder eines DLT-Tokens, an zumindest eine, insbesondere nicht dem Nutzer mit dem Abrufwillen zugeordnete, DLT- Drittadresse umfasst. Dadurch kann eine besonders vorteilhafte, insbesondere einfache, flexible und/oder sichere, Verwaltung für Content Management Systeme ermöglicht werden. Insbesondere ist in dem Smart Contract spezifiziert, wann welche DLT-Antwort-Begleittransaktion mit welchem Inhalt verschickt wird. Beispielsweise kann durch eine oder mehrere der DLT-Begleittransaktionen zumindest ein Teil der digitalen Assets, z.B. der DLT Token, die der ursprünglich an die Eingabefunktion gesendeten DLT-Transaktion beigefügt waren, weitergeleitet werden. Vorteilhaft kann dadurch eine zuverlässige, manipulationssichere und nachvollziehbare Verteilung der digitalen Assets ermöglicht werden. Alternativ könnten die flankierenden DLT-Antwort- Begleittransaktionen nicht automatisch, sondern erst auf Wunsch des Empfängers der Freigabe erfolgen. Beispielsweise könnte der Empfänger eine oder mehrere flankierende DLT-Antwort-Begleittransaktionen in Abhängigkeit von einer Zufriedenheit mit der Übermittlungsdienstleistung und/oder mit dem empfangenen digitalen Inhalt manuell auslösen. Beispielsweise könnte eine flankierende DLT- Antwort-Begleittransaktion durch eine Vergabe eines „Likes“ für den digitalen Inhalt oder in Abhängigkeit von einer Bewertung des digitalen Inhalts durch den Empfänger (umso besser die Bewertung, desto mehr DLT-Token werden versandt) ausgelöst werden. Insbesondere werden die flankierenden DLT-Antwort- Begleittransaktionen durch den Smart Contract ausgelöst. Alternativ oder zusätzlich ist auch ein optionales direktes Auslösen der flankierenden DLT- Antwort-Begleittransaktionen durch den Nutzer, z.B. bei der „Like“-Vergabe, denkbar. Das weitergeleitete digitale Asset ist ein Teil des ursprünglich an die Eingabefunktion übermittelten digitalen Assets.

Wenn zumindest eine DLT-Drittadresse, die Ziel zumindest einer DLT-Antwort- Begleittransaktion ist, einem Urheber zumindest eines Teils des digitalen Inhalts zugeordnet ist, kann eine vorteilhafte (sichere, zuverlässige, unkomplizierte und/oder direkte), insbesondere permanente, Einbeziehung des Urhebers, vorzugsweise aller Urheber, in die Verteilung und Verwaltung von digitalen Inhalten ermöglicht werden. Insbesondere ist denkbar, dass der Urheber vor Erteilen der Freigabe eine Bestätigung, z.B. durch eine in der DLT registrierte Signatur, erteilen muss. Auf diese Weise kann einfach ein Benutzerkreis festgelegt werden. Insbesondere kann ein digitaler Inhalt mehrere Urheber haben, welche jeweils Ziele verschiedener DLT-Antwort-Begleittransaktionen sein können. Über den Smart Contract lässt sich vorteilhaft festlegen, an welchen Urheber, d.h. an welche DLT-Drittadresse, was und wieviel davon weitergeleitet wird.

Wenn alternativ oder zusätzlich zumindest eine DLT-Drittadresse, die Ziel zumindest einer DLT-Antwort-Begleittransaktion ist, einem Verwalter und/oder Bereitsteiler des digitalen Inhalts zugeordnet ist, kann eine vorteilhafte (sichere, zuverlässige, unkomplizierte und/oder direkte), insbesondere permanente, Einbeziehung des Verwalters und/oder Bereitstellers, in die Verteilung und Verwaltung von digitalen Inhalten ermöglicht werden. Insbesondere ist denkbar, dass der Verwalter und/oder Bereitsteiler dadurch eine Rückmeldung über eine Beliebtheit / eine Verwendungshäufigkeit von digitalen Inhalten erhält. Insbesondere ist denkbar, dass der Verwalter und/oder Bereitsteiler dadurch eine Beteiligung an der durch den Nutzer versandten Gesamtmenge von DLT-Token erhält. Über den Smart Contract lässt sich vorteilhaft festlegen, an welchen Verwalter und/oder welchen Bereitsteiler, d.h. an welche DLT-Drittadresse, was und wieviel davon weitergeleitet wird.

Wenn alternativ oder zusätzlich zumindest eine DLT-Drittadresse, die Ziel zumindest einer DLT-Antwort-Begleittransaktion ist, einem Inhaber und/oder Produzenten der den Nutzern zuordenbaren Geräte, insbesondere der Schnittstellengeräte, zugeordnet ist, kann eine vorteilhafte (sichere, zuverlässige, unkomplizierte und/oder direkte), insbesondere permanente, Einbeziehung des Inhabers und/oder des Produzenten der den Nutzern zuordenbaren Geräte in die Verteilung und Verwaltung von digitalen Inhalten ermöglicht werden. Insbesondere ist denkbar, dass der Inhaber und/oder der Produzent der den Nutzern zuordenbaren Geräte dadurch eine Rückmeldung über eine Beliebtheit / eine Nutzungshäufigkeit der Geräte, insbesondere der Schnittstellengeräte, erhält. Insbesondere ist denkbar, dass der Inhaber und/oder der Produzent der den Nutzern zuordenbaren Geräte dadurch eine Beteiligung an der durch den Nutzer versandten Gesamtmenge von DLT-Token erhält. Über den Smart Contract lässt sich vorteilhaft festlegen, an welchen Inhaber und/oder Produzent der den Nutzern zuordenbaren Geräte, d.h. an welche DLT-Drittadresse, was und wieviel davon weitergeleitet wird.

Außerdem wird vorgeschlagen, dass zumindest eine DLT-Drittadresse, die Ziel zumindest einer DLT-Antwort-Begleittransaktion ist, zumindest einem weiteren Smart Contract zugeordnet ist. Dadurch kann eine besonders hohe Flexibilität und/oder Erweiterbarkeit des Content Management Systems erreicht werden, insbesondere trotz der statischen Unveränderlichkeit von in die DLT eingebetteten Smart Contracts. Vorteilhaft kann dadurch eine Verknüpfung von Smart Contracts erreicht werden. Der weitere Smart Contract könnte beispielsweise der Smart Contract eines ursprünglichen digitalen Inhalts sein, der bei der Erstellung des aktuell angeforderten digitalen Inhalts verwendet wurde. Dieser weitere Smart Contract kann dann erneut eine Verteilung, z.B. an den Urheber des vorgenannten ursprünglichen digitalen Inhalts, vorsehen. Die durch den weiteren Smart Contract vorgenommene Verteilung von digitalen Assets könnte in Abhängigkeit von der Herkunft der DLT-Antwort-Begleittransaktion oder in Abhängigkeit einer Popularität eines wiederverwendeten digitalen Inhalts entsprechend seiner Popularität, etc. verändert werden. Beispielsweise könnte der weitere Smart Contract so gestaltet sein, dass für eine positive Rückantwort des weiteren Smart Contracts an den Smart Contract mit jeder Wiederverwertung eines digitalen Inhalts in einem anderen digitalen Inhalt ein höherer Anteil an den beim Aufrufen der Eingabefunktion des Smart Contracts digitalen Assets erforderlich ist.

Insbesondere könnte der Smart Contract so gestaltet sein, dass zur Erteilung der Freigabe zunächst alle weiteren Smart Contracts von wiederverwerteten digitalen Inhalten ihrerseits eine Freigabe an den Smart Contract geschickt haben müssen.

Wenn durch die DLT-Antwort-Begleittransaktion eine Eingabefunktion des weiteren Smart Contracts ausgeführt wird, kann vorteilhaft eine erweiterbare Kette von Smart Contracts zur Verwaltung von Freigaben von digitalen Inhalten erhalten werden. Vorteilhaft kann dadurch eine besonders hohe Flexibilität erreicht werden.

Zusätzlich wird vorgeschlagen, dass, insbesondere in einem Einstellschritt, ein Willen zum Einstellen eines, insbesondere nach dem Einstellen zum Abruf bereitgestellten, digitalen Inhalts durch ein Senden einer DLT-Transaktion an eine weitere Eingabefunktion („write function“) des Smart Contracts oder eines weiteren ebenfalls auf die Digital Ledger Technologie (DLT) aufgesetzten Smart Contracts, insbesondere mittels eines einem Urheber und/oder Einsteller zugeordneten, insbesondere weiteren, Schnittstellengeräts, kundgetan wird. Dadurch kann vorteilhaft eine direkte, von Intermediären im Wesentlichen freie Bereitstellung der digitalen Inhalte zwischen Urheber / Einsteller und Konsument / Nutzer ermöglicht werden. Insbesondere wird der gleiche Smart Contract für das Einstellen und für das Abrufen der digitalen Inhalte verwendet. Alternativ können jedoch auch unterschiedliche Smart Contracts für das Einstellen und für das Abrufen der digitalen Inhalte vorgesehen sein. Beispielsweise wird in dem Einstellschritt von einem dem Urheber / Einsteller zugeordneten Gerät, z.B. einer weiteren Schnittstelleneinheit, die insbesondere identisch zu der Schnittstelleneinheit ausgebildet sein kann, eine Aufforderung an den Smart Contract geschickt, einen bestimmten zuvor ausgewählten digitalen Inhalt in der DLT zu registrieren oder an die DLT zu senden. Dem Inhalt wird dann insbesondere von dem Smart Contract eine Content-Nummer zugeordnet (z.B. Content #2145). Unter dieser Content- Nummer kann der digitale Inhalt später von einem Nutzer angefordert werden. Die DLT-Transaktion wird dabei insbesondere direkt von dem, dem Urheber / Einsteller zugeordneten Gerät an den Smart Contract in der DLT gesandt. Die DLT-Transaktion umfasst dabei vorzugsweise mehrere Inputparameter / Aufrufparameter / digitale Assets, z.B. die Art und/oder den Umfang des gewünschten digitalen Assets, welches bei dem Aufrufen des digitalen Inhalts an den Urheber / Erfasser weitergeleitet werden soll und die DLT-Adressen, an die das digitale Asset weitergeleitet werden soll oder weitere Zusatzinformationen über Beschränkungen bei der Freigabe / Vorgaben für die Freigabe des digitalen Inhalts, wie z.B. Sprache, Alter der erlaubten Nutzer, Nutzungsbedingungen, etc.

Wenn die bereitgestellten digitalen Inhalte mit einem Non-Fungible Token (NFT) der DLT verknüpft werden, kann vorteilhaft eine hohe Fälschungssicherheit erreicht werden. Außerdem kann vorteilhaft eine kontrollierte Weitergabe der digitalen Inhalte durch Nutzer an weitere Nutzer ermöglicht werden. Wenn die digitalen Inhalte als NFTs verteilt werden, können sie vorteilhaft fix mit bestimmten DLT-Adressen verbunden sein. Auch die Weitergabe derartiger NFTs könnte über den Smart Contract oder einen weiteren Smart Contract organisiert sein. Beispielsweise können über den Smart Contract bei jeder Weitergabe des NFT sogenannte Royalties in Form von digitalen Assets abgezweigt und an den Urheber und/oder den Ersteller des digitalen Inhalts oder an Vorbesitzer des NFTs verteilt werden.

Wenn zumindest ein Teil der bereitgestellten digitalen Inhalte dezentral, z.B. in der DLT, abgespeichert werden, kann vorteilhaft eine besonders manipulationssichere, direkte, ohne Mittelsmänner auskommende und/oder schlanke Organisation erreicht werden. Alternativ können die digitalen Inhalte zumindest teilweise zentral auf einem Server oder in einer Cloud abgelegt werden. Insbesondere könnte der Speicherort abhängig gemacht werden von einer Dateigröße des digitalen Inhalts. Alles oberhalb einer bestimmten Dateigrößengrenze würde dann zentral abgespeichert, während alles unterhalb der Dateigrößengrenze dezentral auf der DLT abgespeichert wird.

Außerdem wird ein (weiteres) ortsbezogenes, vorzugsweise dezentrales, Content Management Verfahren zumindest zu einer räumlich organisierten Aufnahme von digitalen Inhalten, die von Urhebern (20) und/oder Erstellern zur Verfügung gestellt werden, in ein ortsbezogenes, insbesondere dezentrales, Content Management System (CMS) vorgeschlagen, wobei ein realer dreidimensionaler Aufnahmeraum für die digitalen Inhalte virtuell in eine Vielzahl an nebeneinander und übereinander angeordneten Volumensegmenten unterteilt wird, wobei jedem der Volumensegmente eine eineindeutige DLT-Adresse einer DLT zugeordnet wird, und wobei jeder der digitalen Inhalte bei dem Einstellen mit zumindest einer der, einem der Volumensegmente zugeordneten DLT-Adressen verknüpft wird. Dadurch kann vorteilhaft ein digitaler Inhalt, z.B. eine Information, mit einer räumlichen Komponente verknüpft werden. Vorteilhaft können die digitalen Inhalte in drei Dimensionen räumlich positioniert werden. Vorteilhaft kann ein dezentral organisierter dreidimensionaler Wissensraum geschafften werden, welcher insbesondere mit freiem, von jedermann erstelltem Wissen gefüllt werden kann. Dabei kann vorteilhaft eine Suche durch räumliche Informationen verfeinert und/oder verbessert werden. Beispielsweise könnte der die räumlichen Informationen umfassende dreidimensionale Wissensraum von intelligenten Kl- Such-Bots des Web 4.0 gezielter durchsuchbar sein, da Informationen an Räume geknüpft sind. Wenn beispielsweise heute im Internet nach Kirchenbeleuchtung gesucht wird, werden sich eine unüberschaubar große Zahl an Suchergebnissen von real existierenden, real nicht-existierenden oder früher existierenden Beleuchtungen ergeben. Wenn nun ein Kl-Such-Bot die Aufgabe erhält, alle aktuell besichtigbaren Kronleuchter in Kirchenschiffen anzuzeigen, die ggf zudem noch Ähnlichkeiten mit einer bestimmten Beschreibung aufweisen, benötigt der Kl- Such-Bot räumliche Information zu den jeweiligen Beschreibungen (digitalen Inhalten). Derartige Suchen könnten zusätzlich räumlich oder anderweitig eingegrenzt werden („zeige mir ähnliche Kronleuchter in Kirchen im Umkreis von 10 km“, „zeige mir Kronleuchter aus bestimmten Epochen, von bestimmten Künstlern“, „zeige mit Kronleuchter, die von bestimmten Urhebern / Erstellern digitaler Inhalte besprochen werden“, etc.). Insbesondere können die Volumensegmente verschiedene Formen, wie eine Würfelform, eine Form eines sechsseitigen Prismas, eine Pyramidenform oder eine andere Körperform, mit der sich ein Raum lückenlos füllen lässt, aufweisen. Insbesondere kann ein, z.B. einem besonders großen Objekt, wie beispielsweise einem Kirchenfenster, zugeordneter digitaler Inhalt auch mehreren Volumensegmenten, und somit insbesondere mehreren DLT Adressen zugeordnet werden. Diese DLT-Adressen können dann vorteilhaft einfacher in einen Smart Contract eingehängt werden, so dass letztendlich der Smart Contract einfacher gefunden werden kann, wenn von Kl-Such-Bots nach ähnlichen Smart Contracts gesucht wird.

Zudem wird vorgeschlagen, dass jeder der digitalen Inhalte mit zumindest einem auf die DLT aufgesetzten Smart Contract verknüpft wird, wobei eine Bereitstellung des digitalen Inhalts an Nutzer über den zumindest einen Smart Contract erfolgt, vorzugsweise mittels des ortsbezogenen Content Management Verfahrens zur Ausgabe der digitalen Inhalte an den Nutzer. Dadurch kann vorteilhaft eine hohe Benutzerfreundlichkeit erreicht werden, insbesondere indem eine besonders hohe Transparenz hinsichtlich der Herkunft von Inhalten und/oder hinsichtlich Vergütungsströmen erreicht werden kann. Vorteilhaft kann eine direkte Umsetzung eines Content Management Verfahrens erreicht werden, welche frei ist von Intermediären, insbesondere bei der Vergütung von Leistungen und/oder bei dem Teilen von Inhalten.

Wenn der reale dreidimensionale Aufnahmeraum weltkugelumspannend ausgebildet ist, kann vorteilhaft eine besonders große Informationsfülle erreicht werden. Beispielsweise könnte der dreidimensionale Aufnahmeraum wie folgt zusammengesetzt / aufgebaut sein. Zunächst wird die Weltkugel plus etwa 10 km Höhe in einen Würfel gesteckt. Dieser Würfel wird dann z.B. in 1 m x 1 m x 1 m Unterwürfel unterteilt. Bei einem Durchmesser der Weltkugel von etwa 12.756 km würde der Würfel dann etwa einen Durchmesser von 12.800 km aufweisen und hätte etwa 12.800 x 12.800 x 12.800 x 1.000 = 2.097.152.000.000.000 Unterwürfel. Unterwürfel, welche an unerreichbaren Stellen unterhalb der Erdoberfläche liegen, also z.B. Unterwürfel innerhalb eines Weltkugeldurchmessers minus 10 km Tiefe (um auch Unterwasserobjekte, Höhlen etc. umfassen zu können), blieben dann unberücksichtigt und allen anderen Unterwürfeln wird dann eine eineindeutige DLT-Adresse zugeordnet. Dadurch erhielte man etwa 2.097.152.000.000.000 - 12.700 x 12.700 x 12.700 x 1 .000 = 48.769.000.000.000 Unterwürfel mit DLT-Adressen. Diese Unterwürfel mit DLT- Adressen bilden dann in diesem Beispiel die einzelnen Volumensegmente aus. Die Gesamtheit aller Unterwürfel mit DLT-Adressen bildet dann in diesem Beispiel den dreidimensionalen Aufnahmeraum aus. Selbstverständlich sind auch begrenztere (z.B. nur auf ein Gebäude, wie eine Kirche begrenzte) oder außerhalb der Erde (z.B. mondumspannende, etc.) dreidimensionale Aufnahmeräume denkbar. Selbstverständlich sind auch feinere oder gröbere Auflösungen des dreidimensionalen Aufnahmeraums in Volumensegmente als die 1 -Kubikmeter- Würfel denkbar. Vorteilhaft bilden die Volumensegmente des dreidimensionalen Aufnahmeraums ein sauberes räumliches Suchraster für Kl-Such-Bots aus.

Des Weiteren wird vorgeschlagen, dass die den Volumensegmenten zugeordneten DLT-Adressen zusätzlich, insbesondere festlegbaren, Zeitintervallen zugeordnet sind. Dadurch kann dem dreidimensionalen Aufnahmeraum vorteilhaft zusätzlich eine Zeitkomponente hinzugefügt werden. Vorteilhaft können dadurch Suchaufrufe auch zeitlich präzisiert werden (z.B. „was hing hier vor 10, 20 und 50 Jahren für ein Kronleuchter“, „was für ein Gebäude stand hier früher?“). Insbesondere können die den Volumensegmenten zugeordneten DLT-Adressen in festlegbaren Zeitintervallen durch neue DLT- Adressen ersetzt werden oder es werden bereits von vorneherein allen Volumensegmenten Zeitintervalle in der Vergangenheit, der Gegenwart und/oder der Zukunft zugeordnet. Dadurch könnten beispielsweise Vorschläge für die Zukunft in dem CMS hinterlegt werden. Wenn z.B. etwas kaputt ist an einer Stelle, könnte eine Frage sein: „was kommt hier in Zukunft hin?“. Beispielsweise hat dann ein Architekt schon einen Vorschlag in einer Audiodatei oder einer Bilddatei hinterlegt. Der Adressraum für DLT-Adressen bekannter DLT ist groß genug für nahezu beliebige zeitliche Auflösungen (z.B. Adressraum von Ethereum- Adressen: 2 256 > 1 ,1 e+77).

Ferner wird ein ortsbezogenes, insbesondere dezentrales, Content Management System (CMS), aufweisend zumindest ein Lokalisierungsgerät zu einer Bestimmung einer Momentanposition des Nutzers des Lokalisierungsgeräts, insbesondere zu der Lokalisation des Nutzers und zumindest ein Schnittstellengerät zur Kommunikation mit der DLT vorgeschlagen. Vorteilhaft kann dadurch eine hohe Benutzerfreundlichkeit erreicht werden, insbesondere indem eine besonders hohe Transparenz hinsichtlich der Herkunft von Inhalten und/oder hinsichtlich Vergütungsströmen erreicht werden kann. Zudem kann vorteilhaft eine Dezentralität erreicht werden, wodurch eine Anfälligkeit für Systemausfälle vorteilhaft reduziert werden kann. Vorteilhaft kann eine direkte Umsetzung eines Content Management Verfahrens erreicht werden, welche frei ist von Intermediären, insbesondere bei der Vergütung von Leistungen und/oder bei dem Teilen von Inhalten. Dadurch kann vorteilhaft eine hohe Effizienz, insbesondere Kosteneffizienz und/oder Energieeffizienz erreicht werden. Vorteilhaft können insbesondere durch die Verwendung von Smart Contracts sichere direkte Interaktionen/Transaktionen zwischen Parteien, die sich nicht kennen und entsprechend noch kein Vertrauen zueinander aufgebaut haben, ermöglicht werden. Das Schnittstellengerät kann als ein alleinstehendes elektronisches (Computer-)Gerät ausgebildet sein, welches vorzugsweise mit einer, insbesondere vorinstallierten, Software ausgestattet ist, die zumindest zur Ausführung zumindest des Anfrageschritts und/oder des Einstellschritts des vorbeschriebenen, insbesondere computerimplementierten, ortsbezogenen, vorzugsweise dezentralen, Content Management Verfahrens vorgesehen ist. Insbesondere ist das Schnittstellengerät in einer deutschen Patentanmeldung mit der Anmeldenummer 10 2021 112 613.4, welche hiermit vollumfänglich in die vorliegende Patentanmeldung übernommen wird, umfangreich beschrieben.

Zudem wird vorgeschlagen, dass das CMS ein Inhalte-Erstellungsgerät aufweist, welches verschieden von dem Lokalisierungsgerät und verschieden von dem Schnittstellengerät ausgebildet ist. Das Inhalte-Erstellungsgerät kann als ein Smartphone, als ein Tablet, als eine Datenbrille, als ein Personal Computer oder als ein weiteres Computergerät ausgebildet sein, welches vorzugsweise mit einer, insbesondere vorinstallierten, Software ausgestattet ist, die zumindest zur Kommunikation von digitalen Inhalten mit dem Schnittstellengerät vorgesehen ist. Optional kann das Inhalte-Erstellungsgerät auch zur Ausführung zumindest des Einstellschritts des vorbeschriebenen, insbesondere computerimplementierten, ortsbezogenen, vorzugsweise dezentralen, Content Management Verfahrens vorgesehen sein.

Weiterhin wird vorgeschlagen, dass das CMS ein Inhalte-Abspielgerät aufweist, welches verschieden von dem Lokalisierungsgerät und verschieden von dem Schnittstellengerät ausgebildet ist. Das Inhalte-Abspielgerät kann als ein Smartphone, als ein Tablet, als eine Datenbrille, als ein Personal Computer, als ein Audiowiedergabegerät oder als ein weiteres Computergerät ausgebildet sein, welches vorzugsweise mit einer, insbesondere vorinstallierten, Software ausgestattet ist, die zumindest zur Kommunikation von digitalen Inhalten mit dem Schnittstellengerät vorgesehen ist. Optional kann das Inhalte-Abspielgerät auch zur Ausführung zumindest des Anfrageschritts des vorbeschriebenen, insbesondere computerimplementierten, ortsbezogenen, vorzugsweise dezentralen, Content Management Verfahrens vorgesehen sein.

Wenn das Inhalte-Erstellungsgerät mit dem Inhalte-Abspielgerät identisch ist, kann vorteilhaft eine einfache Bedienung und/oder eine hohe Benutzerfreundlichkeit erreicht werden. Alternativ könnten das Inhalte-Erstellungsgerät und das Inhalte- Abspielgerät auch als getrennte Geräte ausgebildet sein.

Wenn außerdem das Lokalisierungsgerät mit dem Schnittstellengerät identisch ist, kann vorteilhaft eine einfache Bedienung und/oder eine hohe Benutzerfreundlichkeit erreicht werden. Alternativ könnten das Lokalisierungsgerät und das Schnittstellengerät auch als getrennte Geräte ausgebildet sein. Alternativ könnte das Lokalisierungsgerät auch in ein Smartphone integriert sein, also identisch zumindest mit dem Inhalte-Abspielgerät ausgebildet sein.

Des Weiteren wird vorgeschlagen, dass das CMS eine oder mehrere Ankerstationen, welche eine von Navigationssatellitensystemen unabhängige Bestimmung einer Lokalisation des Nutzers und/oder der virtuell verordneten digitalen Inhalte, z.B. durch lokale Triangulation oder durch lokale Time-of-flight- Messungen, ermöglicht. Dadurch kann vorteilhaft eine präzise Lokalisierung des Nutzers innerhalb geschlossener Gebäude und/oder innerhalb von Bereichen, in denen keine Navigationssatellitensysteme zur Verfügung stehen (z.B. Höhlen), ermöglicht werden. Eine Beschreibung einer Funktionsweise einer Lokalisierung mittels Ankerstationen ist in der deutschen Patentanmeldung mit der Anmeldenummer 10 2021 112 613.4 beschrieben.

Das erfindungsgemäße Verfahren und das erfindungsgemäße System sollen hierbei nicht auf die oben beschriebene Anwendung und Ausführungsform beschränkt sein. Insbesondere kann das erfindungsgemäße Verfahren und das erfindungsgemäße System zu einer Erfüllung einer hierin beschriebenen Funktionsweise eine von einer hierin genannten Anzahl von einzelnen Elementen, Bauteilen und Einheiten abweichende Anzahl aufweisen.

Zeichnungen

Weitere Vorteile ergeben sich aus der folgenden Zeichnungsbeschreibung. In den Zeichnungen ist ein Ausführungsbeispiel der Erfindung dargestellt. Die Zeichnungen, die Beschreibung und die Ansprüche enthalten zahlreiche Merkmale in Kombination. Der Fachmann wird die Merkmale zweckmäßigerweise auch einzeln betrachten und zu sinnvollen weiteren Kombinationen zusammenfassen.

Es zeigen:

Fig. 1 Ein schematisches Schaubild eines ortsbezogenen Content Management Systems (CMS),

Fig. 2 einen beispielhaften Innenraum-Anwendungsfall des CMS,

Fig. 3 ein schematisches Ablaufdiagramm eines ortsbezogenen Content Management Verfahrens und

Fig. 4 einen beispielhaften in Volumensegmente unterteilten dreidimensionalen Aufnahmeraum. Beschreibung des Ausführungsbeispiels

Die Fig. 1 zeigt ein sehr vereinfachtes schematisches Schaubild eines Content Management Systems (CMS) 48. Das CMS 48 ist zu einer Verwaltung von digitalen Inhalten 10 vorgesehen. Das CMS 48 ist zu einer Aufnahme und Ausgabe der digitalen Inhalte 10 an einen Nutzer 12 (siehe auch Fig. 2) vorgesehen. Das CMS 48 ist als ein ortsbezogenes CMS 48 ausgebildet. Die digitalen Inhalte 10 des ortsbezogenen CMS 48 sind jeweils mit Ortskoordinaten verknüpft (siehe auch Fig. 2). Das CMS 48 ist dezentral ausgebildet. Die Verwaltung der digitalen Inhalte 10 des dezentralen CMS 48 erfolgt dezentral über eine Digital Ledger Technologie (DLT) 16. Die Aufnahme und die Ausgabe der digitalen Inhalte 10 des dezentralen CMS 48 erfolgt dezentral über die DLT 16. Die DLT 16 ist als eine dezentrale DLT 16 ausgebildet. Die DLT 16 ist als eine öffentliche DLT 16 ausgebildet. Alternativ kann die DLT 16 auch privat, zumindest teilweise dezentral und/oder nichtöffentlich ausgebildet sein. Die DLT 16 ist vorzugsweise als ein IOTA™-Tangle ausgebildet. In der Fig. 1 ist die DLT 16 jedoch beispielhaft als eine Blockchain skizziert. Die digitalen Inhalte 10 des dezentralen CMS 48 können dezentral, z.B. auf der DLT 16, wie einer Blockchain oder einem Tangle, abgespeichert sein. Alternativ können die digitalen Inhalte 10 jedoch auch zentral auf einem Server oder auf einer Cloud abgespeichert sein und nur die Verwaltung dezentral erfolgen (nicht dargestellt). Das CMS 48 umfasst einen Smart Contract 18. Der Smart Contract 18 ist auf die DLT 16 aufgesetzt. Der Smart Contract 18 ist zu einer Verwaltung der digitalen Inhalte 10, insbesondere der Aufnahme und der Ausgabe der digitalen Inhalte 10, vorgesehen. Der Smart Contract 18 ist zu einer Steuerung von Abspiel-Freigaben für die digitalen Inhalte 10 vorgesehen. Der Smart Contract 18 ist zu einer Steuerung einer Integration von neuen digitalen Inhalten 10 in das CMS 48 vorgesehen. Der Smart Contract 18 weist eine oder mehrere Eingabefunktionen („write functions“) auf. Der Smart Contract 18 weist eine oder mehrere Ausgabefunktionen auf. Dem Smart Contract 18 ist eine DLT-Adresse der DLT 16 zugeordnet. Der Smart Contract 18 kann DLT-Transaktionen 20 empfangen. Der Smart Contract 18 kann DLT- Antworttransaktionen 26 an weitere DLT-Adressen der DLT 16 versenden. Auf die DLT 16 können weitere Smart Contracts 42 aufgesetzt sein. Die weiteren Smart Contracts 42 können mit dem Smart Contract 18 verknüpft werden.

Das CMS 48 weist ein Schnittstellengerät 22 auf. Das Schnittstellengerät 22 ist zu einer Kommunikation mit der DLT 16 vorgesehen. Das Schnittstellengerät 22 ist zu einer Ausbildung einer Schnittstelle zwischen DLT 16 und einem, insbesondere einem Nutzer 12 zuordenbaren, Inhalte-Abspielgerät 54 des CMS 48 und/oder einem, einem Urheber 30 von digitalen Inhalten 10 zuordenbaren Inhalte- Erstellungsgerät 52, vorgesehen. Prinzipiell wäre auch vorstellbar, dass die Inhalte-Abspielgeräte 54 und die Inhalte-Erstellungsgeräte 52 direkt und unabhängig von Schnittstellengeräten 22, 46 mit der DLT 16 kommunizieren. Das Schnittstellengerät 22 ist einem Nutzer 12 fest zugeordnet. Das Schnittstellengerät 22 kann beispielsweise als ein elektronischer Tag oder als ein Wearable ausgebildet sein. Das Schnittstellengerät 22 ist dazu vorgesehen, mit dem Nutzer 12 mitgeführt zu werden. Das CMS 48 weist ein Lokalisierungsgerät 50 auf. Das Lokalisierungsgerät 50 ist zu einer Bestimmung einer Momentanposition des Nutzers 12 vorgesehen. Das Lokalisierungsgerät 50 ist zu einer Bestimmung der Ortskoordinaten, an denen sich der Nutzer 12 befindet, vorgesehen. Das Lokalisierungsgerät 50 ist identisch mit dem Schnittstellengerät 22. Alternativ ist jedoch auch eine getrennte Ausbildung denkbar. Beispielsweise könnte das Schnittstellengerät 22 Nutzerlokalisierungen von einem Drittgerät, z.B. von einem dem Nutzer 12 zugeordneten Smartphone, empfangen. Das Schnittstellengerät 22 ist dazu vorgesehen, die ermittelten Lokalisierungen des Nutzers 12, insbesondere in Echtzeit, mit virtuellen Lokalisierungen von digitalen Inhalten 10 innerhalb des CMS 48 abzugleichen. Die digitalen Inhalte 10 können als Augmented-Reality-Objekte oder als Virtual- Reality-Objekte ausgebildet sein. Das Schnittstellengerät 22 ist dazu vorgesehen, den Nutzer 12 auf digitale Inhalte 10, die sich in einem Bereich 14 der Lokalisierung des Nutzers 12 befinden, hinzuweisen. Alternativ oder zusätzlich können auch die Inhalte-Abspielgeräte 54 für diese Aufgabe vorgesehen sein. Das CMS 48 weist das Inhalte-Abspielgerät 52 auf. Das Inhalte-Abspielgerät 52 ist verschieden von dem Lokalisierungsgerät 50 ausgebildet. Das Inhalte-Abspielgerät 52 ist verschieden von dem Schnittstellengerät 22 ausgebildet. Das Inhalte-Abspielgerät 52 ist beispielhaft als ein Kopfhörer / als eine VR-Brille ausgebildet. Das Inhalte-Abspielgerät 52 ist zur Ausgabe der digitalen Inhalte 10 an den Nutzer 12 vorgesehen.

Das CMS 48 weist das Inhalte-Erstellungsgerät 52 auf. Das Inhalte- Erstellungsgerät 52 ist verschieden von dem Lokalisierungsgerät 50 ausgebildet. Das Inhalte-Erstellungsgerät 52 ist verschieden von dem Schnittstellengerät 22 ausgebildet. Das Inhalte-Erstellungsgerät 52 kann mit dem Inhalte-Abspielgerät 54 identisch sein. In der beispielhaften Darstellung von Fig. 1 sind Inhalte- Erstellungsgerät 52 und Inhalte-Abspielgerät 54 jedoch verschieden und getrennt voneinander ausgebildet und insbesondere unterschiedlichen Nutzern 12, 30 zugeordnet. Das CMS 48 weist ein weiteres Schnittstellengerät 46 auf. Das weitere Schnittstellengerät 46 ist im in der Fig. 1 dargestellten Fall einem Urheber 30 von digitalen Inhalten 10 zugeordnet. Das weitere Schnittstellengerät 46 ist zumindest im Wesentlichen identisch zu dem Schnittstellengerät 22 ausgebildet. Das weitere Schnittstellengerät 22 bildet das Lokalisierungsgerät 50 aus.

Alternativ ist jedoch auch eine getrennte Ausbildung denkbar. Das weitere Schnittstellengerät 46 ist zu einer Kommunikation mit der DLT 16 vorgesehen. Das weitere Schnittstellengerät 46 ist zu einer Ausbildung einer Schnittstelle zwischen DLT 16 und dem, insbesondere dem Urheber 30 zuordenbaren, Inhalte- Erstellungsgerät 52, vorgesehen. Das weitere Schnittstellengerät 46 ist dem Urheber 30 fest zugeordnet. Das weitere Schnittstellengerät 22 ist dazu vorgesehen, die ermittelten Lokalisierungen des Urhebers 30, insbesondere in Echtzeit, mit virtuellen Lokalisierungen von digitalen Inhalten 10 zu verknüpfen, die von dem Urheber 30 erstellt und hinterlassen werden. Alternativ ist jedoch auch denkbar, dass der Urheber 30 den von ihm erstellten digitalen Inhalten 10 manuell Ortskoordinaten zuordnet, an denen diese dann virtuell verortet werden.

Das CMS 48 kann dazu vorgesehen sein, mit weiteren Parteien, wie z.B. einem

Verwalter 32 des CMS 48 und/oder einem Produzenten 38 der Schnittstellengeräte 22 und/oder weiteren Smart Contracts 42 und/oder weiteren an einem digitalen Inhalt 10 beteiligten Urhebern 66 zu kommunizieren und/oder in Verbindung zu treten. Siehe dazu insbesondere die Erläuterungen zu Fig. 3.

Die Fig. 2 zeigt einen beispielhaften Innenraum-Anwendungsfall des CMS 48. Das CMS 48 wird in diesem Fall für eine Besucherführung in einem Innenraum 62 einer Kirche (Überlinger Münster) angewandt. Vergleichbare Verwendungen an anderen Orten innen (Museum, Messegelände, Konferenz-Veranstaltungsort, Krankenhausgebäude, Universitätsgebäude, Flughafengebäude, etc.) wie außen (Stadtführung, Vergnügungspark, Wanderwege, etc.) sind selbstverständlich ebenfalls denkbar. Das CMS 48 weist mehrere Ankerstationen 56 auf. Die Ankerstationen 56 sind innerhalb des Innenraums 62 verteilt angeordnet. Die Ankerstationen 56 sind zu einer Lokalisation von Schnittstellengeräten 22 in Innenräumen 62 vorgesehen. Die Ankerstationen 56 sind zu einer von Navigationssatellitensystemen unabhängigen Bestimmung der Lokalisation des Nutzers 12, insbesondere der dem Nutzer 12 zugeordneten Schnittstellengeräte 22, vorgesehen. Die Ankerstationen 56 sind zu einer von Navigationssatellitensystemen unabhängigen Bestimmung der Lokalisation der virtuell verordneten digitalen Inhalte 10 vorgesehen. Die Ankerstationen 56 sind dazu vorgesehen, eine Lokalisation durch lokale Triangulation und/oder durch lokale Time-of-flight-Messungen zu ermöglichen. In dem Innenraum 62 sind mehrere digitale Inhalte 10 virtuell verortet. Jeder verortete digitale Inhalt 10 stellt beispielsweise eine Audio- und/oder Videoerläuterung zu einem an dieser Stelle zu besichtigenden Objekt dar. Dem Nutzer 12 werden die digitalen Inhalte 10 und deren Positionen durch die Schnittstellengeräte 22 mitgeteilt. Um den Nutzer 12 herum wird jeweils ein Bereich 14 definiert (z.B. ein Kreis von 2 m Radius). Die Schnittstellengeräte 22 ermitteln kontinuierlich, ob sich ein digitaler Inhalt 10 in dem Bereich 14 des Nutzers 12 befindet. Wenn dies der Fall ist, wird der digitale Inhalt 10 für den Nutzer 12, insbesondere für ein Inhalte-Abspielgerät 54 des Nutzers 12, vorzugsweise via des Schnittstellengeräts 22, zum Abruf bereitgestellt. Die Fig. 3 zeigt ein schematisches Ablaufdiagramm eines ortsbezogenen Content Management Verfahrens zur Ausgabe der digitalen Inhalte 10 an den Nutzer 12. Das Verfahren ist als ein dezentrales Content Management Verfahren ausgebildet. Das Verfahren umfasst zudem ein ortsbezogenes, vorzugsweise dezentrales, Content Management Verfahren zu einer räumlich organisierten Aufnahme von digitalen Inhalten 10, die von den Urhebern 30 und/oder von Erstellern zur Verfügung gestellt werden, in das CMS 48. In zumindest einem Verfahrensschritt 110 wird ein realer dreidimensionaler Aufnahmeraum 104 für digitale Inhalte 10 virtuell in eine Vielzahl an nebeneinander und übereinander angeordneten Volumensegmenten 106, 108 unterteilt (vgl. dazu auch Fig. 4). Der in der Fig. 4 beispielhaft dargestellte reale dreidimensionale Aufnahmeraum 104 ist weltkugelumspannend ausgebildet. In zumindest einem weiteren Verfahrensschritt 112 wird jedem der Volumensegmente 106, 108 ein Bündel eineindeutiger DLT- Adressen der DLT 16 zugeordnet. Jede der den Volumensegmenten 106, 108 zugeordneten DLT-Adressen ist dabei genau einem Zeitintervall zugeordnet. In zumindest einem weiteren Verfahrensschritt 64 wird von dem Urheber 30 ein digitaler Inhalt 10 erzeugt. Der Urheber 30 kann dabei auf Material (z.B. eine Hintergrundmusik, eine Animation, ein Bild, etc.) zurückgreifen, welches von anderen Urhebern 66 stammt (vgl. Fig. 1 ). Der Urheber 30 erstellt den digitalen Inhalt 10 mittels des Inhalte-Erstellungsgeräts 52 (z.B. mit seinem Smartphone). In zumindest einem Verfahrensschritt 76 ordnet der Urheber 30 dem digitalen Inhalt 10 eine Ortskoordinate zu. Dies kann durch ein Aufsuchen des Ortes der Ortskoordinate und ein Durchführen des folgenden Verfahrensschritts 68 an diesem Ort oder durch ein manuelles Hinzufügen einer Ortskoordinate zu dem digitalen Inhalt 10 von einem anderen Ort aus erfolgen. Jeder Teilnehmer des CMS 48 kann dabei ein Urheber 30 sein / als Urheber 30 aktiv werden. In dem, einen Einstellschritt 60 ausbildenden, weiteren Verfahrensschritt 68 tut der Urheber 30 den Willen zum Einstellen des erstellten digitalen Inhalts 10 kund. Dazu sendet der Urheber 30 eine DLT-Transaktion 44 an eine Eingabefunktion des Smart Contracts 18. Der Urheber 30 verwendet dazu das ihm zugeordnete Schnittstellengerät 46. Jeder der so dem CMS 48 hinzugefügten digitalen Inhalte 10 wird bei dem Einstellen mit zumindest einer der, einem der Volumensegmente 106, 108 zugeordneten DLT-Adressen verknüpft. In zumindest einem weiteren Verfahrensschritt 70 registriert der Smart Contract 18 den digitalen Inhalt 10 in dem CMS 48. Beispielsweise weist der Smart Contract 18 dem digitalen Inhalt 10 eine Registrierungsnummer zu. Dabei wird jeder der digitalen Inhalte 10 mit dem Smart Contract 18 verknüpft. Zudem ordnet der Smart Contract 18 dem digitalen Inhalt 10 den Urheber 30, bzw. die DLT-Adresse des Urhebers 30 zu. Bei dem Aufrufen der Eingabefunktion des Smart Contracts 18 gibt der Urheber 30 optional die weiteren digitalen Inhalte, die er bei der Erstellung seines digitalen Inhalts 10 verwendet hat, oder zumindest die DLT-Adressen der Urheber 66 dieser weiteren digitalen Inhalte an.

In zumindest einem weiteren Verfahrensschritt 72 wird der bereitgestellte digitale Inhalt 10 dezentral in der DLT 16 abgespeichert. Alternativ ist auch eine zentrale Speicherung oder eine Cloudspeicherung denkbar. In zumindest einem weiteren Verfahrensschritt 74 wird der bereitgestellte digitale Inhalt 10 von dem Smart Contract 18 mit einem Non-Fungible Token (NFT) der DLT 16 verknüpft. Dies kann beispielsweise durch Aufnahme eines Hash-Werts des digitalen Inhalts 10 in ein NFT der DLT 16 erfolgen. Es kann zu jedem digitalen Inhalt 10 mehrere NFTs geben, so dass jeder Nutzer 12 ein individuelles, unverwechselbares und unvervielfältigbares NFT des digitalen Inhalts 10 erhält. In zumindest einem weiteren Verfahrensschritt 80 wird der digitale Inhalt 10 nach dem Einstellen in das CMS 48 zum ortsbezogenen Abruf an den verknüpften Koordinaten bereitgestellt.

In zumindest einem weiteren Verfahrensschritt 82 wird eine Lokalisation des Nutzers 12 bestimmt. Dazu bestimmt das Lokalisierungsgerät 50 des Nutzers 12 die kontinuierlich sich ändernde Position des beweglichen Nutzers 12 in dem Innenraum 62. Die Positionsbestimmung erfolgt über eine Wechselwirkung mit den Ankerstationen 56. Die Schnittstellengeräte 22 tauschen dabei Signale mit den Ankerstationen 56 aus oder empfangen Signale von den Ankerstationen 56, auf Basis derer die Positionsbestimmung erfolgen kann. In zumindest einem weiteren Verfahrensschritt 84 wird ermittelt, ob in dem Bereich 14 um die Lokalisation des Nutzers 12 ein digitaler Inhalt 10 virtuell verordnet ist. Wenn ein digitaler Inhalt 10 in dem Bereich 14 ermittelt wird, wird dieser in einem weiteren Verfahrensschritt 86 für den Abruf an den Nutzer 12 bereitgestellt. Die Bereitstellung des digitalen Inhalts 10 erfolgt in dem Verfahrensschritt 86 über den Smart Contract 18. Der Nutzer 12 kann das Lokalisierungsgerät 50 zudem auch zu einer Zusammenstellung und/oder einer Navigation einer geführten Tour verwenden. Dabei ist denkbar, dass zwischen verschiedenen, verschiedene digitale Inhalte 10 passierenden Touren ausgewählt werden kann. Wenn mehrere digitalen Inhalte 10 in dem Bereich 14 um die Lokalisation des Nutzers 12 ermittelt werden, kann beispielsweise eine Anzeige eines Drop-Down-Menüs innerhalb des Inhalte-Abspielgeräts 54 vorgesehen sein, mittels welchem ein digitaler Inhalt 10 unter mehreren Inhalten auf einfache Weise ausgewählt werden kann.

In zumindest einem, einen Anfrageschritt 58 ausbildenden, Teilschritt 88 des Verfahrensschritts 86 tut der Nutzer 12 einen Willen zum Abruf des digitalen Inhalts 10 kund. Dazu sendet der Nutzer 12 eine DLT-Transaktion 20 an eine Eingabefunktion des Smart Contracts 18. Bezüglich einer weiteren Veranschaulichung aller im Folgenden beschriebenen DLT-Transaktionen wird an dieser Stelle auch auf die Fig. 1 verwiesen. Dies erfolgt mittels des dem Nutzer 12 zugeordneten Schnittstellengeräts 22. Die DLT-Transaktion 20 umfasst dabei Aufrufparameter für die Eingabefunktion des Smart Contracts 18. Der DLT- Transaktion 20 an die Eingabefunktion wird zudem zumindest ein digitales Asset, wie z.B. ein DLT-Token, beigefügt. Es ist denkbar, dass die Schnittstellengeräte 22 mit einem Krypto-Wallet eines Nutzers 12 verbindbar sind oder dass den Schnittstellengeräten 22 eigene Krypto-Wallets zugeordnet sind, welche von dem Nutzer 12 mit digitalen Assets aufgeladen werden können, beispielsweise durch eine Fiat-Zahlung an den Verwalter 32 bei der Übernahme der jeweiligen Schnittstellengeräte 22. In zumindest einem weiteren Teilschritt 90 des Verfahrensschritts 86 wird der Smart Contract 18 von mindestens einem DLT- Knoten der DLT 16 ausgeführt. In zumindest einem weiteren Teilschritt 92 des Verfahrensschritts 86 wird eine Freigabe des digitalen Inhalts 10 durch eine DLT- Antworttransaktion 26 des Smart Contracts 18 zumindest ausgelöst. Die Freigabe des digitalen Inhalts 10 erfolgt dabei spezifisch für zumindest ein Schnittstellengerät 22, welchem eine DLT-Empfangsadresse der DLT- Antworttransaktion 26 zugeordnet ist oder welchem eine DLT-Adresse zugeordnet ist, die in der DLT-Antworttransaktion 26 spezifiziert ist.

In zumindest einem weiteren Teilschritt 94 des Verfahrensschritts 86 wird die DLT- Antworttransaktion 26 von einer ersten DLT-Antwort-Begleittransaktion 28 flankiert. Die DLT-Antwort-Begleittransaktion 28 wird von dem Smart Contract 18 in zeitlichem Zusammenhang (zeitgleich oder kurz vorher oder kurz nachher) zu der DLT-Antworttransaktion 26 versandt. Die DLT-Antwort-Begleittransaktion 28 umfasst ein Versenden zumindest eines digitalen Assets / ein Weiterleiten zumindest eines Teils des digitalen Assets, welches der DLT-Transaktion 20 von dem Nutzer 12 (in dem Teilschritt 88) beigefügt wurde. Die DLT-Antwort- Begleittransaktion 28 wird von dem Smart Contract 18 an eine nicht dem Nutzer 12 mit dem Abrufwillen zugeordnete DLT-Drittadresse gesandt. Die DLT- Drittadresse, an die die DLT-Antwort-Begleittransaktion 28 gerichtet wird, ist dem Urheber 30 des digitalen Inhalts 10 zugeordnet. Beispielsweise werden dem Urheber 30 75 % der der DLT-Transaktion 20 von dem Nutzer 12 beigefügten digitalen Assets zugewiesen. In zumindest einem weiteren Teilschritt 96 des Verfahrensschritts 86 wird die DLT-Antworttransaktion 26 von einer zweiten DLT- Antwort-Begleittransaktion 34 flankiert. Die zweite DLT-Antwort-Begleittransaktion 34 wird von dem Smart Contract 18 in zeitlichem Zusammenhang (zeitgleich oder kurz vorher oder kurz nachher) zu der DLT-Antworttransaktion 26 versandt. Die zweite DLT-Antwort-Begleittransaktion 34 umfasst ein Versenden zumindest eines digitalen Assets / ein Weiterleiten zumindest eines Teils des digitalen Assets, welches der DLT-Transaktion 20 von dem Nutzer 12 (in dem Teilschritt 88) beigefügt wurde. Die zweite DLT-Antwort-Begleittransaktion 34 wird von dem Smart Contract 18 an eine nicht dem Nutzer 12 mit dem Abrufwillen zugeordnete DLT-Drittadresse gesandt. Die DLT-Drittadresse, an die die zweite DLT-Antwort- Begleittransaktion 34 gerichtet wird, ist dem Verwalter 32 und/oder einem Bereitsteiler des digitalen Inhalts 10 zugeordnet. Beispielsweise werden dem Verwalter 32 und/oder dem Bereitsteiler des digitalen Inhalts 10 10 % der der DLT-Transaktion 20 von dem Nutzer 12 beigefügten digitalen Assets zugewiesen. In zumindest einem weiteren Teilschritt 24 des Verfahrensschritts 86 wird die DLT- Antworttransaktion 26 von einer dritten DLT-Antwort-Begleittransaktion 36 flankiert. Die dritte DLT-Antwort-Begleittransaktion 36 wird von dem Smart Contract 18 in zeitlichem Zusammenhang (zeitgleich oder kurz vorher oder kurz nachher) zu der DLT-Antworttransaktion 26 versandt. Die dritte DLT-Antwort- Begleittransaktion 36 umfasst ein Versenden zumindest eines digitalen Assets / ein Weiterleiten zumindest eines Teils des digitalen Assets, welches der DLT- Transaktion 20 von dem Nutzer 12 (in dem Teilschritt 88) beigefügt wurde. Die dritte DLT-Antwort-Begleittransaktion 36 wird von dem Smart Contract 18 an eine nicht dem Nutzer 12 mit dem Abrufwillen zugeordnete DLT-Drittadresse gesandt. Die DLT-Drittadresse, an die die dritte DLT-Antwort-Begleittransaktion 36 gerichtet wird, ist einem Inhaber und/oder dem Produzenten 38 des dem Nutzer 12 zugeordneten Schnittstellengeräts 22 zugeordnet. Beispielsweise werden dem Inhaber und/oder dem Produzenten 38 des dem Nutzer 12 zugeordneten Schnittstellengeräts 22 15 % der der DLT-Transaktion 20 von dem Nutzer 12 beigefügten digitalen Assets zugewiesen.

In zumindest einem weiteren Teilschritt 98 des Verfahrensschritts 86 wird die DLT- Antworttransaktion 26 von einer vierten DLT-Antwort-Begleittransaktion 40 flankiert. Die vierte DLT-Antwort-Begleittransaktion 40 wird von dem Smart Contract 18 in zeitlichem Zusammenhang (zeitgleich oder kurz vorher oder kurz nachher) zu der DLT-Antworttransaktion 26 versandt. Die vierte DLT-Antwort- Begleittransaktion 40 umfasst ein Versenden zumindest eines digitalen Assets / ein Weiterleiten zumindest eines Teils des digitalen Assets, welches der DLT- Transaktion 20 von dem Nutzer 12 (in dem Teilschritt 88) beigefügt wurde. Die vierte DLT-Antwort-Begleittransaktion 40 wird von dem Smart Contract 18 an eine nicht dem Nutzer 12 mit dem Abrufwillen zugeordnete DLT-Drittadresse gesandt. Die D LT- Drittadresse, an die die vierte DLT-Antwort-Begleittransaktion 36 gerichtet wird, ist dem weiteren Smart Contract 42 zugeordnet. Dadurch wird der Smart Contract 18 mit dem weiteren Smart Contract 42 verknüpft. Der weitere Smart Contract 42 kann zu einer Organisation / Verwaltung eines weiteren digitalen Inhalts vorgesehen sein. Der weitere Smart Contract 42 kann zur Vergabe von Royalties vorgesehen sein. In zumindest einem weiteren Teilschritt 100 des Verfahrensschritts 86 wird ausgelöst durch die vierte DLT-Antwort- Begleittransaktion 40 eine Eingabefunktion des weiteren Smart Contracts 42 ausgeführt. Durch den weiteren Smart Contract 42 werden in Reaktion auf die Ausführung der Eingabefunktion weitere DLT-Antwort-Begleittransaktionen 102 ausgelöst. Den weiteren DLT-Antwort-Begleittransaktionen 102 sind jeweils zumindest Teile des digitalen Assets beigefügt, welche mit der vierten DLT- Antwort-Begleittransaktion 40 an den weiteren Smart Contract 42 gesendet wurden. Beispielsweise ist einer der Empfänger der weiteren DLT-Antwort- Begleittransaktionen 102 der weitere Urheber 66, dessen Material in dem ursprünglich angeforderten digitalen Inhalt 10 verwendet wurde. Beispielsweise ist einer der Empfänger der weiteren DLT-Antwort-Begleittransaktionen 102 der Verwalter 32, über den der weitere digitale Inhalt bereitgestellt wurde, welcher bei der Erstellung des ursprünglich angeforderten digitalen Inhalts 10 wiederverwendet wurde. Beispielsweise werden dem weiteren Urheber 66 10% der 75% des Urhebers 30 zugewiesen. Beispielsweise werden dem Verwalter 32, über den der weitere digitale Inhalt bereitgestellt wurde, 5 % der 75% des Urhebers 30 zugewiesen. Generell ist die Anzahl der DLT-Antwort- Begleittransaktionen 28, 34, 36, 40, 102, die eine DLT-Antworttransaktion 26 flankieren oder die durch eine DLT-Antworttransaktion 26 ausgelöst werden, beliebig veränderbar. Auch ist eine Verknüpfung mehrerer weiterer Smart Contracts 42 mit dem Smart Contract oder auch eine Kette von verknüpften Smart Contracts 18, 42 denkbar.

In zumindest einem weiteren Verfahrensschritt 78 wird der freigegebene digitale

Inhalt 10 von dem Nutzer 12 mittels des Inhalte-Abspielgeräts 54 abgespielt. Dazu kann nur die Freigabe oder auch der gesamte digitale Inhalt 10 von dem Schnittstellengerät 22 an das Inhalte-Abspielgerät 54 weitergeleitet werden.

Bezugszeichen

10 Digitaler Inhalt

12 Nutzer

14 Bereich

16 DLT

18 Smart Contract

20 DLT-Transaktion

22 Schnittstellengerät

24 Teilschritt

26 DLT-Antworttransaktion

28 DLT-Antwort-Begleittransaktion

30 Urheber

32 Verwalter

34 DLT-Antwort-Begleittransaktion

36 DLT-Antwort-Begleittransaktion

38 Produzent

40 DLT-Antwort-Begleittransaktion

42 Weiterer Smart Contract

44 DLT-Transaktion

46 Schnittstellengerät

48 Content Management System

50 Lokalisierungsgerät

52 Inhalte-Erstellungsgerät

54 Inhalte-Abspielgerät

56 Ankerstation

58 Anfrageschritt

60 Einstellschritt

62 Innenraum

64 Verfahrensschritt

66 Urheber Verfahrensschritt

Verfahrensschritt

Verfahrensschritt

Verfahrensschritt

Verfahrensschritt

Verfahrensschritt

Verfahrensschritt

Verfahrensschritt

Verfahrensschritt

Verfahrensschritt

Teilschritt

Teilschritt

Teilschritt

Teilschritt

Teilschritt

Teilschritt

Teilschritt

Weitere DLT-Antwort-Begleittransaktion

Dreidimensionaler Aufnahmeraum

Volumensegment

Volumensegment

Verfahrensschritt

Verfahrensschritt