Stand der Technik

Die Erfindung betrifft ein Content Management Verfahren nach dem Oberbegriff des Anspruchs 1 , ein Content Management System nach dem Oberbegriff des Anspruchs 20, ein Metaversum nach dem Anspruch 22 und ein Computerprogrammprodukt nach dem Anspruch 23.

Im Zusammenhang mit populären Projekten wie Decentraland wurde bereits eine Art von ortsbezogenem dezentralisiertem Content Management Verfahren zur Verwaltung von digitalen Inhalten innerhalb eines mit einer Blockchain (dort: Ethereum Blockchain) verknüpften Metaversums, wobei ein durch das Metaversum definierter virtueller Raum in eine Anzahl nebeneinander angeordnete Segmente aufgeteilt ist, und wobei die digitalen Inhalte einzelnen Segmenten zugeordnet werden können, vorgeschlagen.

Die Aufgabe der Erfindung besteht insbesondere darin, ein gattungsgemäßes Verfahren mit vorteilhaften Eigenschaften hinsichtlich einer Vielseitigkeit, einer Gestaltungsfreiheit und/oder einer Benutzerfreundlichkeit bereitzustellen. Die Aufgabe wird erfindungsgemäß durch die Merkmale der Patentansprüche 1 , 20, 22 und 23 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 computerimplementiertem, Content Management Verfahren (CMV), insbesondere einem computerimplementierten ortsbezogenen, vorzugsweise dezentralisierten, Content Management Verfahren zumindest zur Verwaltung von digitalen Inhalten (Content) innerhalb eines mit einer Distributed Ledger Technologie (DLT), wie z.B. einer Blockchain oder einem Tangle, verknüpften Metaversums, wobei ein durch das Metaversum definierter virtueller Raum in eine Anzahl nebeneinander und/oder übereinander angeordneter Segmente, insbesondere Volumensegmente, aufgeteilt ist, und wobei digitale Inhalte einzelnen Segmenten zugeordnet werden.

Es wird vorgeschlagen, dass zumindest einem der Segmente eine auf die DLT aufgesetzte Decentralized Autonomous Organization (DAO, im Folgenden kurz mit VolumeDAO bezeichnet) zugeordnet wird. Dadurch können vorteilhaft Eigenschaften hinsichtlich einer Vielseitigkeit, einer Gestaltungsfreiheit und/oder einer Benutzerfreundlichkeit erreicht werden. Vorteilhaft kann dadurch eine hohe Transparenz des CMV erreicht werden, insbesondere indem Regeln und Governance des CMV innerhalb jedes einzelnen der Segmente für jedermann zugänglich und/oder für jedermann nachvollziehbar sind (unverfälschbarer transparenter Audit Trail). Außerdem kann vorteilhaft eine hohe Transparenz dadurch erreicht werden, indem die Governance über einzelne Segmente in unveränderbar auf die DLT aufgesetzten Smart Contracts hartkodiert ist. Zudem kann vorteilhaft eine hohe Vielseitigkeit und/oder Gestaltungsfreiheit dadurch erreicht werden, dass eine (demokratische) Mitbestimmung über Vorgänge in den einzelnen Segmenten für jedermann, jederzeit ermöglicht ist. Dabei kann beispielsweise vorteilhaft ein existierender, dem VolumeDAO eines Segments zugeordneter Smart Contract durch Abstimmung unter den Teilnehmern der VolumeDAO ersetzt werden. Vorteilhaft ist zur Organisation des CMV keine übergeordnete Verwaltungs- und/oder Steuerungsstruktur notwendig. Vorteilhaft kann ein das CMV übergreifender Einfluss von außen, beispielsweise durch eine Manipulation oder eine Zensur von digitalen Inhalten o.ä. zumindest im Wesentlichen verhindert werden. Dadurch kann beispielsweise eine nur sehr begrenzt beeinflussbare Suchfunktion zum Auffinden von digitalen Inhalten ermöglicht werden. 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.

In einem, insbesondere ortsbezogenen, vorzugsweise dezentralisierten, Content Management Verfahren werden insbesondere digitale Inhalte verwaltet, also z.B. bereitgestellt, welche, insbesondere virtuell, zumindest mit einer Koordinate in einem Metaversum und/oder 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), ein digitaler Text 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. Insbesondere erfolgt die Verwaltung und/oder die Bereitstellung des digitalen Inhalts über einen Smart Contract, welcher vorzugsweise der VolumeDAO des jeweiligen Segments zugeordnet ist. Insbesondere erfolgt dabei vor einem Einstellen, Aufrufen oder Abspielen des digitalen Inhalts eine Interaktion des Nutzers mit dem Smart Contract der VolumeDAO. Dabei kann ein einzelner Smart Contract der jeweiligen Volume DAO die Bereitstellung mehrerer digitaler Inhalte innerhalb eines Segments organisieren / verwalten oder es kann jedem digitalen Inhalt oder Teilmengen aller digitalen Inhalte innerhalb eines der Segmente ein eigener, insbesondere individueller, Smart Contract der jeweiligen VolumeDAO zugeordnet sein. Insbesondere entscheidet ein Resultat der Interaktion mit dem Smart Contract der VolumeDAO darüber, ob der digitale Inhalt für den Nutzer zur Verwendung bereitgestellt wird oder nicht. Vorzugsweise ist die VolumeDAO und/oder der Smart Contract auf einer DLT aufgesetzt, die auf einer Directed Acyclic Graph- Architektur (DAG) beruht, wie z.B. IOTA™. Vorteilhaft ist die VolumeDAO und/oder der Smart Contract auf eine DLT aufgesetzt, die frei oder nahezu frei von Transaktionskosten ist. Vorteilhaft ist die VolumeDAO und/oder 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 sind die Smart Contracts der VolumeDAOs 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, insbesondere von Governance Token der jeweiligen VolumeDAO, 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 beispielsweise eine Zugriffserlaubnis auf einen digitalen Inhalt oder eine Einstellerlaubnis eines digitalen Inhalts, etc. umfasst und d) Ausführen der Transaktion. 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.

Ein Metaversum soll insbesondere als ein konsistenter und persistenter digitaler / virtueller Raum verstanden werden. Insbesondere entsteht der digitale / virtuelle Raum des Metaversums durch eine Konvergenz von virtueller und/oder erweiterter und physischer Realität. Insbesondere ist der virtuelle Raum des Metaversums in die Segmente unterteilt, wobei die Segmente 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 können. Die Segmente können identisch geformt und identisch groß sein, es ist jedoch denkbar, dass einzelne Segmente in Untersegmente weiterverzweigbar sind und/oder dass die Segmente zumindest teilweise verschieden groß und/oder verschieden geformt sind. Dies könnte beispielsweise durch einen Smart Contract einer VolumeDAO bestimmt werden, welcher dann übergeordnet über Unter- VolumeDAOs einzelner Untersegmente wäre. Dadurch kann vorteilhaft eine beliebig tiefe Verschachtelung von immer kleiner werdenden Metaversen erreicht werden. Alternativ oder zusätzlich ist jedoch auch denkbar, dass durch in den VolumeDAOs getroffene Entscheidungen VolumeDAOs einzelner Segmente miteinander verbunden und/oder verknüpft werden (z.B. über entsprechende gemeinsame Smart Contracts). Auf diese Weise können einzelne Sub-Metaversen des Metaversums miteinander verschmelzen. Insbesondere kann ein, z.B. einem besonders großen Objekt, wie beispielsweise einem Gebäude, zugeordneter digitaler Inhalt auch mehreren Volumensegmenten, und somit insbesondere mehreren VolumeDAOs zugeordnet werden. Vorteilhaft sind die Segmente überlappungsfrei zueinander. Vorteilhaft bedecken die Segmente zumindest einen interessanten Bereich, z.B. einen für Menschen zugänglichen Bereich der Weltkugel, lückenlos.

Eine „Decentralized Autonomous Organization (DAO)“ ist insbesondere eine technische Organisationsstruktur, deren Governance in verschiedenen auf einer DLT aufgesetzten Smart Contracts verankert ist, welche dann ausgeführt wird, wenn bestimmte festgelegte Voraussetzungen erfüllt sind. Die Governance in der DAO ist insbesondere wesentlich verschieden von einem CEO, der Entscheidungen trifft. Die Governance in der DAO erfordert insbesondere einen demokratischen Konsensus, der in dem/den Smart Contract/s der DAO hartkodiert ist. Grundsätzlich kann jede VolumeDAO auch mit einem festen Wertesystem, beispielsweise einer übergeordneten DAO, versehen sein. Dabei handelt es sich insbesondere um ein übergeordnetes Regelwerk, welches für alle Segmente / VolumeDAOs des CMS / CMV gilt. Dabei ist möglich, dass nicht alle Regeln auf alle Segmente / VolumeDAOs anwendbar sind / zutreffen, jedoch kann kein Segment / VolumeDAO gegen diese Regeln verstoßen. Beispielsweise könnte eine derartige übergeordnete Regel lauten: „Hassrede ist nicht erlaubt“. Diese Regel würde dann überall gelten. Beispielsweise könnte eine derartige übergeordnete Regel lauten: „Werbung ist nicht erlaubt in öffentlichen Gebäuden oder Kirchen“. Diese Regel würde dann auf Segmente innerhalb von Kirchen zutreffen, jedoch nicht auf Segmente innerhalb von Shopping Malls. Vorteilhaft sind die Regeln des festen Wertesystems programmierbar. Wenn beispielsweise eine neue VolumeDAO erstellt wird, z.B. weil Content ergänzt wird, zieht sich das VolumeDAO basierend auf seiner geographischen Position das entsprechende Regelwerk aus dem CMS / CMV oder der übergeordneten DAO. Alternativ oder zusätzlich ist vorstellbar, dass die an dem jeweiligen Volumen teilnehmenden Nutzer (Besitzer von Governance Token der jeweiligen Volume DAO) die Bestimmung der Natur des realen Raums in einem bestimmten Segment (Handelt es sich z.B. um eine Schule oder um eine Kirche?) über Votings innerhalb der VolumeDAO festlegen und somit insbesondere auch über das grundlegende Regelwerk der VolumeDAO bestimmen. Um einen Missbrauch zu vermeiden, ist denkbar, dass das CMS / das CMV oder die übergeordnete DAO ein Veto-Recht für jede der VolumeDAOs besitzt, welches beispielsweise nur dann einsetzbar ist, wenn es zu einer Mindestzahl an Beschwerden über einen Meldebutton kommt. Es können auch Auditoren von dem CMS / dem CMV oder der übergeordneten DAO eingesetzt werden, welche an einen strittigen Ort fahren und die Gegebenheiten vor Ort prüfen.

Ferner wird vorgeschlagen, dass das CMV die Verfahrensschritte: a1 ) Empfangen eines neuen, in/aus einem der Segmente hochgeladenen digitalen Inhalts, insbesondere durch die DLT oder a2) Empfangen einer Information, dass in/aus einem Segment ein digitaler Inhalt hochgeladen wurde und b) Überprüfen, ob bereits eine diesem Segment zugeordnete und auf die DLT aufgesetzte Decentralized Autonomous Organization (VolumeDAO) existiert und c) Erstellen einer neuen VolumeDAO für das Segment innerhalb der DLT, in dem Fall, dass noch keine dem Segment zugeordnete VolumeDAO existiert, umfasst. Dadurch kann vorteilhaft eine einfache, effiziente und/oder benutzerfreundliche Umsetzung des CMV erreicht werden. Insbesondere kann bei dem Erstellen der neuen VolumeDAO diesem automatisch ein die neue VolumeDAO definierender Standard Smart Contract oder ein Bündel an interagierenden Standard Smart Contracts, die die neue VolumeDAO definieren, zugeordnet werden. Alternativ oder zusätzlich kann bei dem Erstellen der neuen VolumeDAO dem Nutzer, der den ersten digitalen Inhalt in dem Segment hochgeladen hat, eine Auswahl an vorgefertigten, die neue VolumeDAO definierenden Initial-Smart Contracts bereitgestellt werden, wobei der/die durch die Nutzerauswahl bestimmte/n Smart Contract/s dann der neuen VolumeDAO zugeordnet werden und die neue VolumeDAO definieren. Alternativ oder zusätzlich kann bei dem Erstellen der neuen VolumeDAO dem Nutzer, der den ersten digitalen Inhalt in dem Segment hochgeladen hat, eine Aufforderung zu einem Bereitstellen eines die neue VolumeDAO definierenden Custom-Smart Contracts angezeigt werden, woraufhin der Nutzer einen oder mehrere Custom-Smart Contracts bereitstellen kann, welche/r dann der neuen VolumeDAO zugeordnet wird/werden und der/die neue VolumeDAO definiert/definieren. Insbesondere können auch die vorbereiteten oder automatisch bereitgestellten Standard Smart Contracts und/oder Initial-Smart Contracts bei der Erstellung der VolumeDAO durch den, den ersten digitalen Inhalt in dem Segment hochladenden Nutzer modifizierbar und/oder anpassbar ausgebildet sein.

Wenn der virtuelle Raum dem real existierenden Raum überlagert ist und insbesondere zumindest weltkugelumspannend ist, kann vorteilhaft ein Metaversum mit einem Bezug zur echten Welt versehen werden. Vorteilhaft kann dadurch eine besonders umfassende und große Informationsfülle erreicht werden. Vorteilhaft kann dadurch ein ortsbezogenes CMV verwirklicht werden. Vorteilhaft kann 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 geschaffen 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 Suchmaschinen oder von intelligenten Kl-Such-Bots des Web 4.0 gezielter durchsuchbar sein, da Informationen an Räume geknüpft sind. Der virtuelle Raum kann zumindest teilweise auch innerhalb der Weltkugel liegen und/oder definiert sein. Insbesondere umfasst das CMS / CMV eine bijektive Abbildung zumindest zwischen einem Teil, insbesondere einem praktisch besuchbaren Teil, des real existierenden Raums und dem virtuellen Raum. Insbesondere sind der virtuelle Raum und der real existierende Raum zumindest in Teilen der Gesamtheit des real existierenden Raums zueinander bijektiv abgebildet. Insbesondere existiert, vorzugsweise begrenzt auf Teile der Gesamtheit des real existierenden Raums, z.B. begrenzt auf „interessante“ Teile oder praktisch besuchbare Teile des real existierenden Raums, eine bijektive Abbildung zwischen Volumenelementen der physischen Welt / des materiellen Universums und den Segmenten der virtuellen Welt / des virtuellen Raums. 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 (Segmente) unterteilt. Bei einem Durchmesser der Weltkugel von etwa 12.756 km würde der Würfel dann etwa eine Kantenlänge 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 Weltkugelradius 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 Segmente, insbesondere 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 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 Segmente, insbesondere Volumensegmente, als die 1 -Kubikmeter-Würfel denkbar. Beispielsweise könnten ausgehend vom Erdmittelpunkt mittels gedanklicher Laserstrahlen quaderförmige immer größer werdende Strukturen erzeugt werden, welche ungefähr 1 m ³ Raumvolumen an der Erdoberfläche haben, aber immer größer werden mit zunehmender Entfernung von der Erde. Vorteilhaft bilden die Segmente, insbesondere Volumensegmente, des dreidimensionalen Aufnahmeraums ein sauberes räumliches Suchraster für Suchmaschinen und/oder Kl-Such-Bots aus.

Zudem wird vorgeschlagen, dass jeder der digitalen Inhalte mit zumindest einem Smart Contract verknüpft wird, welcher der VolumeDAO, die dem Segment, in/aus welchem der digitale Inhalt ursprünglich hochgeladen wurde, zugehörig ist. Dabei kann auch eine Bereitstellung des digitalen Inhalts an weitere Nutzer über einen Smart Contract dieser VolumeDAO erfolgen. 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.

Zusätzlich wird vorgeschlagen, dass bei dem Empfang des hochgeladenen digitalen Inhalts eine Zuordnung des digitalen Inhalts zu dem jeweiligen Segment in dem virtuellen Raum durch eine Lokalisierung des das Hochladen initiierenden Nutzers und/oder Schnittstellengeräts im durch den virtuellen Raum überlagerten real existierenden Raum erfolgt. Vorteilhaft kann dadurch ein ortsbezogenes CMV verwirklicht werden. Vorteilhaft kann ein digitaler Inhalt, z.B. eine Information, mit einer räumlichen Komponente verknüpft werden. Die Bestimmung der Lokalisation des Nutzers kann mittels einer Ortungsfunktion eines Geräts des Nutzers, z.B. eines Schnittstellengeräts des Nutzers, welches ein Hochladen und/oder Abspielen der digitalen Inhalte erlaubt, erfolgen. Denkbar sind z.B. eine globale Ortung unter Verwendung von Navigationssatellitensystemen (GNSS), 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. Alternativ ist denkbar, dass ein Nutzer seine Präsenz in einem bestimmten Segment dadurch belegt, dass er ein an dem zugehörigen Ort positioniertes und mit dem Segment verbundenes Tag, z.B. einen QR-Code, einen DataMatrix-Code oder einen Barcode, einliest. Es ist denkbar, dass in Abhängigkeit einer Stärke einer Beweiskraft der Lokalisierung, z.B. anhand der von dem jeweiligen Nutzer verwendeten Lokalisierungsmethode den diesem Nutzer zugewiesenen NFTs (z.B. FollowerNFT oder CreatorNFT) eine bestimmte unterschiedliche Reputationsstufe zugeordnet wird. Beispielsweise kann mittels IEEE802.15.4z (UWB) und Kryptographie eine besonders beweiskräftige und/oder fälschungssichere Entfernungsmessung zu einer der Ankerstationen implementiert sein, wodurch vorteilhaft eine höchstmögliche Reputationsstufe für Lokalisierungsdaten erreicht werden kann. Beispielsweise kann einer (spoofbaren) Lokalisierung mittels GNSS eine niedrigere Reputationsstufe zugeordnet werden. Es ist denkbar, dass eine Reputationsstufe, z.B. durch bestimmte Aktivitäten des Nutzers, erhöht / verbessert werden kann. Beispielsweise kann eine Anzahl an Besuchen eines Segments, eine Häufigkeit an Besuchen eines Segments, eine Anzahl oder Häufigkeit von Besuchen benachbarter oder (thematisch oder örtlich) verwandter Segmente zu einer Erhöhung / Verbesserung der Reputationsstufe führen. Beispielsweise kann einem neuen NFT für eine Person in einem Segment, welches einer Kirche zugeordnet ist, bereits eine höhere Reputationsstufe zugewiesen werden, wenn diese Person bereits nachweisbar eine große Anzahl an Kirchen besucht hat und/oder bereits nachweisbar eine größere Anzahl von NFTs besitzt, die anderen "Kirchen- Segmenten“ zugeordnet sind. Eine Bereitstellung der digitalen Inhalte an weitere Nutzer des CMV kann über das in der deutschen Patentanmeldung mit der Anmeldenummer 10 2022 107 027.1 beschriebene Verfahren erfolgen, deren Beschreibung hiermit vollumfänglich in die vorliegende Patentanmeldung übernommen wird. Des Weiteren wird vorgeschlagen, dass in Reaktion auf das Hochladen des digitalen Inhalts aus dem Segment ein Creator-Non-Fungible-Token (CreatorNFT) innerhalb der DLT erzeugt wird. Dadurch kann vorteilhaft eine sichere, unverfälschbare und/oder einfach rückverfolgbare Zuordnung von digitalen Inhalten ermöglicht werden. Insbesondere ist das CreatorNFT mit dem jeweiligen digitalen Inhalt, welcher seine Erzeugung bewirkt hat, verknüpft. Insbesondere kann ein Nutzer durch Nachweis des Besitzes des CreatorNFT ein Eigentums- und/oder Verfügungsrecht über den damit verknüpften digitalen Inhalt nachweisen. Es ist denkbar, dass dem CreatorNFT zusätzliche Informationen / Metadaten, wie beispielsweise ein Zeitstempel, eine Nutzungsgebühr, eine Lizenzforderung, etc. beigefügt werden. Durch das Beifügen der Tags wie dem Zeitstempel bei dem Einstellen des Contents kann vorteilhaft eine zeitbezogene Inhaltssuche in einem Segment ermöglicht werden, insbesondere zusätzlich zu einer ortsbezogenen Inhaltssuche.

Außerdem wird vorgeschlagen, dass der digitale Inhalt mit dem CreatorNFT verknüpft wird. Dadurch kann vorteilhaft eine sichere, unverfälschbare und/oder einfach rückverfolgbare Zuordnung von digitalen Inhalten ermöglicht werden. Unter einem Non-Fungible Token (NFT), manchmal auch nicht austauschbarer Token genannt, soll insbesondere eine digitalisierte Form eines Datensatzes / Vermögenswerts verstanden werden, der vorzugsweise auf eine DLT, wie eine Blockchain oder ein Tangle oder dergleichen, aufgesetzt ist, und welcher insbesondere nicht eins-zu-eins austauschbar, nicht teilbar und einzigartig ausgebildet ist. NFTs können innerhalb des VolumeDAO und/oder innerhalb der DLT verteilbar und/oder versendbar sein. In öffentlichen DLTs können die darauf aufgesetzten NFTs und vorzugsweise mit dem NFT assoziierte Transaktionen von jedermann eingesehen werden. Ein NFT kann insbesondere mit zumindest einem physischen oder digitalen Objekt, wie z.B. einem digitalen Inhalt, verknüpft werden. Insbesondere ist das in Reaktion auf das Hochladen des digitalen Inhalts aus dem Segment erstellte CreatorNFT zumindest mit dem hochgeladenen digitalen Inhalt verknüpft. Dazu umfasst das CreatorNFT den digitalen Inhalt direkt oder in Form eines Hashwerts, der basierend auf dem digitalen Inhalt erstellt wird, oder dergleichen. Sobald die Erstellung des CreatorNFTs durch das Konsensusprotokoll der jeweiligen DLT bestätigt wurde, ist die Zuordnung des digitalen Inhalts zu dem CreatorNFT unveränderlich und permanent (bis zu einem eventuellen Auflösen oder Vernichten durch einen Besitzer des CreatorNFT) in der DLT festgehalten. Die Erstellung eines NFT, insbesondere eines mit einem Objekt / digitalen Inhalt verbundenen NFT wird häufig auch als „Minting“ des NFT bezeichnet. Insbesondere wird das CreatorNFT von dem SmartContract der VolumeDAO oder des übergeordneten CMV erzeugt. Eine Vernichtung eines NFT bzw. eine Unmöglichmachung eines Besitzes des NFT für jedermann wird häufig auch als „Burning“ des NFT bezeichnet. Ein Auslösen eines NFT, d.h. ein Auflösen des Zusammenhangs zwischen dem NFT und dem ihm zugeordneten Objekt wird häufig auch als „Redeeming“ des NFT bezeichnet. Insbesondere kann das CreatorNFT unter Verwendung einer kleinsten möglichen Einheit eines DLT- Tokens erstellt werden. Das DLT-Token bildet einen unterliegenden Vermögenswert aus. Für manche Anwendungen kann der unterliegende Vermögenswert auch erhöht werden, beispielsweise den tatsächlichen Wert des digitalen Inhalts zum Zeitpunkt der Erstellung beinhalten etc.

CreatorNFTs sind vorzugsweise zumindest einer, bevorzugt genau einer, Besitzeradresse innerhalb der DLT zugeordnet. Alternativ ist jedoch auch denkbar, dass ein CreatorNFT mit mehr als einer DLT-Besitzeradresse verknüpft ist oder dass mehrere Nutzer Zugriff auf eine einzelne DLT-Besitzeradresse und somit auf das CreatorNFT haben. Diese dem CreatorNFT zugeordnete Besitzeradresse kann z.B. durch einen Versand, ein Handeln oder einen Tausch des CreatorNFT änderbar sein. Alternativ kann das CreatorNFT jedoch auch unversendbar ausgebildet sein. Die DLT ist vorzugsweise als eine dezentralisierte DLT ausgebildet. Alternativ kann die DLT auch nur teilweise dezentralisiert (über wenige Knoten verteilt) oder zentralisiert ausgebildet sein. Die DLT ist vorzugsweise als eine öffentlich einsehbare DLT ausgebildet. Alternativ ist denkbar, dass die DLT zumindest eine Zugangsbeschränkung aufweist. Vorzugsweise ist das NFT über die DLT öffentlich einsehbar. Vorzugsweise ist die dem NFT zugeordnete Besitzeradresse über die DLT öffentlich einsehbar. Vorzugsweise ist die Zuordnung des NFT zu der Besitzeradresse über die DLT öffentlich einsehbar.

Wenn das CreatorNFT ein Governance-Token des VolumeDAO ausbildet, und insbesondere wenn das erstellte CreatorNFT an eine DLT-Adresse der DLT versandt wird, welche einem Nutzer zugeordnet ist, der den jeweiligen digitalen Inhalt hochgeladen hat, kann vorteilhaft eine lokale Selbstverwaltung der digitalen Inhalte, insbesondere durch mit dem jeweiligen Segment verbundene Nutzer, ermöglicht werden. Ein Governance Token ist insbesondere ein Token der DLT, welches seinem Inhaber (dem Nutzer mit Zugriff auf die DLT-Adresse, der das Governance Token zugeordnet ist) die Möglichkeit gibt, Entscheidungen zu beeinflussen, die Regeln und/oder eine Organisation der DAO (der VolumeDAO des jeweiligen Segments, in dem das CreatorNFT erstellt wurde), insbesondere ein Kernprotokoll der DAO sowie Änderungen von Governance-Parametern der DAO betreffen. Insbesondere verleihen die Governance Token eine relative Stimmrechtsmacht innerhalb der jeweiligen VolumeDAO, welche vorzugsweise abhängig ist von einem Anteil an Governance Token, die sich im Besitz eines Nutzers befinden an einer (ggf. durch ein Minting von neuen Governance Token bei einem Hochladen von weiteren digitalen Inhalten erweiterbaren) Gesamtheit aller Governance Token der jeweiligen VolumeDAO. Beispielsweise erhält jeder Nutzer pro Governance Token, das sich unter seiner Kontrolle befindet, eine Stimme in der VolumeDAO. Zudem ist denkbar, dass jeder Inhaber einer Mindestzahl an Governance Token ein Recht erhält, bestimmte Themen zur Abstimmung innerhalb der VolumeDAO vorzuschlagen. Es ist denkbar, dass eine Stimmkraft eines NFTs (CreatorNFT / FollowerNFT) innerhalb der VolumeDAO direkt von der Reputationsstufe abhängt, die dem jeweiligen NFT bei dessen Erstellung zugewiesen wurde.

Zusätzlich wird vorgeschlagen, dass zu jedem innerhalb des Segments hochgeladenen weiteren digitalen Inhalt ein weiteres CreatorNFT innerhalb der DLT erzeugt wird, welches insbesondere mit dem jeweiligen weiteren digitalen Inhalt verknüpft wird, und welches insbesondere ebenfalls ein Governance Token des VolumeDAO ausbildet. Dadurch kann vorteilhaft ein selbstverwaltetes Ökosystem von Content Management Systemen mit segmentspezifischen Regularien geschaffen werden. Vorteilhaft kann eine hohe Flexibilität und/oder Benutzerfreundlichkeit erreicht werden. Es ist denkbar, dass eine Gesamtzahl an Governance Token pro VolumeDAO begrenzt oder unbegrenzt ist oder dass eine Begrenzung der Gesamtzahl an Governance Token durch Abstimmung innerhalb der jeweiligen VolumeDAO selbst festlegbar ist.

Wenn die Segmente, insbesondere die Segmenten zugeordneten digitalen Inhalte, insbesondere die die digitalen Inhalte umfassenden CreatorNFTs, ferndurchsuchbar sind, kann vorteilhaft ein dreidimensionaler Wissensraum geschaffen werden, welcher beispielsweise von Suchmaschinen oder von intelligenten Kl-Such-Bots des Web 4.0 gezielter durchsuchbar ist. Beispielsweise können die CreatorNFTs ähnlich einer DLT-basierten NFT-Marktplatzsuche durchsuchbar sein. Dadurch kann eine unabhängige, manipulationssichere und/oder zensurfreie Suchmöglichkeit innerhalb des Metaversums ermöglicht werden. Darunter, dass digitale Inhalte „ferndurchsuchbar“ sind soll insbesondere verstanden werden, dass die digitalen Inhalte und/oder deren zugeordnete CreatorNFTs von außerhalb der jeweiligen Segmente, insbesondere von Maschinen und/oder Nutzern, die sich in dem real existierenden Raum außerhalb der jeweiligen Segmente befinden, durchsucht werden können.

Außerdem wird vorgeschlagen, dass zumindest einem der Segmente ein, insbesondere weiterer, Nutzer als Follower zugeordnet wird, insbesondere durch die Verfahrensschritte a) Empfangen einer Registration eines neuen Followers für eines der Segmente, beispielsweise durch einen übergeordneten Smart Contract des Metaversums, b) Überprüfen, ob bereits eine dem Segment zugeordnete und auf die DLT aufgesetzte VolumeDAO existiert und c) Erstellen einer neuen VolumeDAO für das Segment innerhalb der DLT, in dem Fall dass noch keine dem Segment zugeordnete VolumeDAO existiert. Dadurch kann vorteilhaft eine einfache, effiziente und/oder benutzerfreundliche Umsetzung des CMV erreicht werden. Die Erstellung des VolumeDAO kann in diesem Fall analog zu der vorbeschriebenen Erstellung eines VolumeDAO bei einem ersten Hochladen eines digitalen Inhalts ablaufen. Insbesondere ist für die Registrierung als Follower kein Hochladen / Bereitstellen eines digitalen Inhalts notwendig. Insbesondere kann die Registrierung als Follower von außerhalb des Segments erfolgen. Insbesondere kann zur Überprüfung, ob bereits eine, einem der Segmente zugeordnete und auf die DLT aufgesetzte VolumeDAO existiert, die dem Segment zugeordnete DLT- Adresse nach mit ihr verknüpften Smart Contracts durchsucht werden. Wenn bereits ein oder mehrere Smart Contracts existieren, die der dem Segment zugeordneten DLT-Adresse zugeordnet sind, kann dann, z.B. durch Analyse des öffentlich einsehbaren Codes der Smart Contracts, ermittelt werden, ob diese Smart Contracts zu einer DAO, insbesondere einer VolumeDAO, zugehörig sind oder ob sie andere Aufgaben erfüllen.

Ferner wird vorgeschlagen, dass bei einem Nachweis eines Aufenthalts eines Followers des Segments an einem Ort im real existierenden Raum, welcher diesem Segment im virtuellen Raum überlagert ist, ein Follower-Non-Fungible- Token (FollowerNFT) innerhalb der DLT erzeugt wird, welches vorteilhaft an eine DLT-Adresse der DLT versandt wird, welche dem Follower, der seinen Aufenthalt innerhalb des Segments nachgewiesen hat, zugeordnet ist und/oder welches vorteilhaft ein, insbesondere weiteres, Governance-Token des VolumeDAO ausbildet. Dadurch kann eine besonders vorteilhafte lokale Selbstverwaltung der digitalen Inhalte, insbesondere durch mit dem jeweiligen Segment verbundene Nutzer (Contributor und Follower), ermöglicht werden. Beispielsweise können die Contributor und die Follower darüber entscheiden, welche Arten von digitalen Inhalten in einem Segment hochgeladen und/oder konsumiert werden würfen. Vorteilhaft kann ein selbstverwaltetes Ökosystem von Content Management Systemen (CMS) mit segmentspezifischen Regularien geschaffen werden. Vorteilhaft kann dadurch eine hohe Flexibilität und/oder Benutzerfreundlichkeit erreicht werden. Vorteilhaft kann ein von einer übergreifenden Kontrollinstanz unabhängiges, insbesondere kleinteiliges, CMV/CMS geschaffen werden, welches insbesondere besonders resistent gegenüber Zensur oder anderweitige externen Einflussnahmen ist. Insbesondere können die FollowerNFT-Governance Token, insbesondere hinsichtlich einer Stimmrechtsmacht, gleichwertig sein wie die CreatorNFT-Governance Token. Alternativ können sich die mit den jeweiligen Governance Token verbundenen Teilhaberechte an der Gestaltung des Segments / des VolumeDAO unterscheiden. Beispielsweise könnte dem CreatorNFT- Governance Token eine andere Stimmrechtsmacht, insbesondere eine höhere Stimmrechtsmacht, zugewiesen werden als dem FollowerNFT-Governance Token. Beispielsweise könnten den Inhabern von CreatorNFTs Befugnisse innerhalb des jeweiligen VolumeDAO zugewiesen werden, welche Inhaber von FollowerNFTs nicht besitzen (z.B. ein Vorschlagsrecht für Abstimmungen innerhalb des VolumeDAO). Es ist zudem auch denkbar, dass jedes Segment (neben uneditierbarem von Nutzern hochgeladenem Content) editierbare Informationen umfasst, beispielsweise ähnlich zu einer lokalisierten Wikipedia. Diese editierbaren Informationen können dann beispielsweise nur von Nutzern verändert, gelöscht und/oder erstellt werden, welche zumindest ein Governance Token der VolumeDAO des Segments besitzen. Löschungen, Erstellungen und/oder Änderungen an den editierbaren Informationen können in der VolumeDAO zur Abstimmung gebracht werden.

Außerdem wird vorgeschlagen, dass jedem der Segmente des das Metaversum bildenden virtuellen Raums ein, insbesondere übergeordnetes, Volumen-Non- Fungible-Token (VolumeNFT) der DLT zugeordnet ist, welches räumliche (Real- )Koordinaten umfasst, die das jeweilige Segment definieren und das jeweilige Segment mit dem realen Raum verknüpfen. Dadurch kann vorteilhaft ein Hauptmetaversum zur Verfügung gestellt werden, welches eins-zu-eins mit der Geosphäre der Erde korrespondiert. Dieses Hauptmetaversum enthält kleinere Metaversen in Form der Segmente mit den VolumeDAOs. Die Anordnungen dieser kleineren Metaversen innerhalb des Hauptmetaversums sind dann vorteilhaft unwiderruflich mit der physischen Ebene verbunden. Vorteilhaft kann dadurch ein ortsbezogenes Content Management System erhalten werden. Vorteilhaft kann nun eine umfassende, aber blitzschnelle Suchmaschine bereitgestellt werden, die es ermöglicht, nach digitalen Inhalten zu suchen, die auf NFTs indexiert sind, da jedes der Metaversen, jedes der Segmente und/oder jede der VolumeDAOs über das VolumeNFT dauerhaft mit einem realen Standort auf der Erde verbunden ist. Die VolumeNFTs können DLT-Adressen zugeordnet sein, welche sich unter der Kontrolle von Entitäten befinden. Beispielsweise können sich die VolumeNFTs im Besitz einer Organisation befinden, welche das CMS eingerichtet hat. Beispielsweise können die VolumeNFTs von Dritten erworben werden. Dabei ist denkbar, dass ein Nachweis über einen Besitz oder eine Berechtigung des mit dem jeweiligen Segment verknüpften real existierenden Raums bei der Übertragung des Besitzes an dem zugehörigen VolumeNFT berücksichtigt wird. Alternativ könnten die VolumeNFTs einer Burn-Adresse der DLT zugeordnet sein, auf welche niemand Zugriff besitzt. Insbesondere umfasst das VolumeNFT die räumlichen Realkoordinaten direkt und öffentlich einsehbar, oder als Hash oder dergleichen oder in verschlüsselter Form. Darunter, dass das VolumeNFT „übergeordnet“ ausgebildet ist soll insbesondere verstanden werden, dass das VolumeNFT von einem übergeordneten Smart Contract des gesamten Metaversums stammt und insbesondere nicht von einem der Smart Contracts der in den Segmenten gebildeten einzelnen VolumeDAOs. Insbesondere existiert eine bijektive Abbildung zwischen physischen Orten und VolumeNFTs.

Wenn das VolumeNFT kein Governance-Token des Volume DAO ausbildet, kann vorteilhaft eine hohe Dezentralität und Unabhängigkeit des CMS/CMV erreicht werden. Vorteilhaft hat dadurch der Besitzer des VolumeNFT keinen Einfluss auf den Inhalt und die Abläufe innerhalb des zugehörigen Segments, außer er nimmt selbst aktiv an der zugehörigen VolumeDAO teil, indem er CreatorNFTs und/oder FollowerNFTs der VolumeDAO besitzt, die er insbesondere ausschließlich über den vorbeschriebenen regulären Weg erhalten kann. Vorteilhaft hat eine Eigentumsübertragung an dem VolumeNFT keinen Einfluss auf die VolumeDAO oder die von der VolumeDAO verwalteten digitalen Inhalte. Vorteilhaft wird dadurch eine Einflussnahme von außerhalb auf lokale Vorgänge erschwert, insbesondere da nur den Entitäten Governance Token für das VolumeDAO zugeteilt werden, welche tatsächlich nachweislich zumindest einmal vor Ort gewesen sind. Beispielsweise müsste eine ausländische Organisation, welche Einfluss auf ein lokales VolumeDAO in den Vereinigten Staaten nehmen möchte, eine große Zahl an Personen an den Ort des Segments schicken und/oder eine große Zahl an bereits existierenden CreatorNFTs und/oder FollowerNFTs der lokalen VolumeDAO von, insbesondere überwiegend lokal verwurzelten Personen, erwerben, um genug Stimmrechtsmacht für eine wesentliche Einflussnahme auf das VolumeDAO zu besitzen. Die Inhaber der VolumeNFTs könnten somit insbesondere nicht über Vorschläge in der VolumeDAO abstimmen, sie könnten jedoch die einzigen sein, die neue Vorschläge zur Änderung der Governance der zugehörigen VolumeDAO einbringen können, über die dann innerhalb der VolumeDAO von den Inhabern der FollowerNFTs und/oder der CreatorNFTs abgestimmt werden kann.

Alternativ ist jedoch auch denkbar, dass das VolumeNFT ein Governance Token der VolumeDAO ausbildet. Zudem ist alternativ denkbar, dass bei einer Vernichtung („burning“) eines zu einem Segment zugehörigen VolumeNFT, insbesondere automatisch, ein neues VolumeNFT für das Segment oder eine Mehrzahl neuer VolumeNFT für jeweils Teilvolumen des Segments erzeugt werden. Dadurch kann vorteilhaft eine hohe Flexibilität erreicht werden. Außerdem ist denkbar, dass bei einer Zurücknahme einer Bereitstellung eines digitalen Inhalts aus einem Segment das zugehörige CreatorNFT vernichtet wird oder sein Stimmrecht in der VolumeDAO des Segments verliert.

Weiterhin wird vorgeschlagen, dass die jeweiligen Governance-Token und/oder das VolumeNFT zwischen DLT-Adressen der DLT, insbesondere frei, transferierbar sind. Dadurch können vorteilhaft Eigenschaften hinsichtlich einer Vielseitigkeit, einer Gestaltungsfreiheit und/oder einer Benutzerfreundlichkeit erreicht werden. Insbesondere können die Governance-Token und/oder das VolumeNFT auf N FT-Marktplätzen, vorzugsweise frei, gehandelt werden. Darunter, dass die Governance-Token und/oder das VolumeNFT „frei“ transferierbar oder handelbar sind soll insbesondere verstanden werden, dass die die Governance-Token und/oder das VolumeNFT auch an Entitäten übertragen werden können, welche sich außerhalb der Segmente befinden und/oder welche das Segment nie in dem real existierenden Raum besucht haben.

Zusätzlich ist denkbar, dass weitere NFTs existieren, die den jeweiligen VolumeDAOs zuordenbar sind und welche die Funktion eines Governance Token der VolumeDAO erfüllen können oder nicht. Beispielsweise könnte es ein MarketingNFT geben, welches eine Berechtigung zu einem Schalten von Marketing und/oder Werbung innerhalb eines Segments regelt. Dieses MarketingNFT hätte dann beispielsweise keine Governance Token Funktion. Wie alle NFTs kann auch das MarketingNFT vernichtet (burned), aufgelöst (redeemed) oder übertragen werden, wodurch die zugrundeliegenden Werberechte in dem jeweiligen Segment manipuliert werden. Außerdem könnte es beispielsweise ein InsuranceNFT geben, über welches ein Versicherer eine Haftpflichtversicherung für einen Nutzer, welcher digitale Inhalte hochlädt, anbieten kann. Die InsuranceNFT könnte dann mit bestimmten digitalen Inhalten und mit einer Versicherungspolice verknüpft sein. Der Versicherer könnte dann beispielsweise (über einen Smart Contract) von mittels des digitalen Inhalts erzielten Erlösen eine Gebühr, z.B. 1%, bekommen und übernimmt im Gegenzug Haftungsschäden, die z.B. durch mögliche Urheberrechtsverletzungen entstehen können. Ein an der VolumeDAO teilnehmender Nutzer hätte dadurch vorteilhaft besonders einfach die Möglichkeit, diese Option anzuwählen, und der Versicherer müsste nicht jeden einzelnen digitalen Inhalt prüfen, da er ja ebenfalls von den Community Guidelines profitiert, die im VolumeDAO und/oder der übergeordneten DAO verankert sind. Der Versicherer hätte also die Möglichkeit, Haftung auszuschließen für Verstöße gegen die grundlegenden Werte in der VolumeDAO und/oder der übergeordneten DAO und übernimmt nur die Risiken, die übrig bleiben. Das InsuranceNFT bildet kein Governance Token der VolumeDAO aus. Ferner wird ein Content Management System (CMS), insbesondere ein ortsbezogenes, vorzugsweise dezentralisiertes, Content Management System, zumindest zur Verwaltung von digitalen Inhalten (Content) innerhalb des mit der Distributed Ledger Technologie (DLT), wie z.B. einer Blockchain oder einem Tangle, verknüpften Metaversums, insbesondere mittels des Content Management Verfahrens, vorgeschlagen, wobei der durch das Metaversum definierte virtuelle Raum in eine Anzahlnebeneinander und/oder übereinander angeordnete Segmente, insbesondere Volumensegmente, aufgeteilt ist, und wobei digitale Inhalte einzelnen Segmenten zugeordnet werden, und wobei zumindest einem der Segmente eine auf die DLT aufgesetzte Decentralized Autonomous Organization (VolumeDAO) zugeordnet ist. Dadurch können vorteilhaft Eigenschaften hinsichtlich einer Vielseitigkeit, einer Gestaltungsfreiheit und/oder einer Benutzerfreundlichkeit erreicht werden. Insbesondere umfasst das CMS zumindest ein Schnittstellengerät, welches als ein elektronisches (Compu- ter-)Gerät ausgebildet sein kann und welches vorzugsweise mit einer, insbesondere vorinstallierten, Software ausgestattet ist, die zumindest zur Ausführung des vorbeschriebenen CMV, insbesondere zu einem Hochladen und/oder Konsumieren von digitalen Inhalten und/oder zu einer Teilnahme an einer VolumeDAO vorgesehen ist. Insbesondere ist das Schnittstellengerät zu einer Kommunikation mit der DLT vorgesehen. Das Schnittstellengerät kann als ein Smartphone, als ein Tablet, als ein Notebook oder dergleichen ausgebildet sein. Insbesondere ist das Schnittstellengerät derart ausgebildet, wie es in der deutschen Patentanmeldung mit der Anmeldenummer 10 2021 112 613.4, welche hiermit vollumfänglich in die vorliegende Patentanmeldung übernommen wird, umfangreich beschrieben ist.

Insbesondere bildet das Schnittstellengerät ein Lokalisierungsgerät aus. Insbesondere ist das Schnittstellengerät zu einer geographischen Lokalisierung von räumlich positionierten digitalen Inhalten vorgesehen. Bei einem Erfassen eines digitalen Inhalts in einem Bereich einer momentanen Lokalisation des Nutzers des Schnittstellengeräts wird dieser dem Nutzer dann zum Abruf vorgeschlagen und/oder angeboten. 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 innerhalb 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. Insbesondere könnte der Bereich durch das Segment gebildet sein, in dem sich der Nutzer momentan befindet oder durch eine festgelegte Anzahl an Bereichen im Umkreis der aktuellen Lokalisation des Nutzers. 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 diese ihm dann 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. Außerdem wird vorgeschlagen, dass das Lokalisierungsgerät zu einer Bestimmung einer Momentanposition des Nutzers über eine Kommunikation mit lokal verorteten Ankerstationen vorgesehen ist, wobei zumindest eine der Ankerstationen dazu vorgesehen ist, digitale Inhalte mit lokalem Bezug, insbesondere redundant, lokal abzuspeichern und dem lokal präsenten Nutzer zum Abruf bereitzustellen, beispielsweise per UWB, Bluetooth, WLAN oder dergleichen. Dadurch kann vorteilhaft ein besonders effizientes CMS geschaffen werden, in dem Übertragungsbandbreite, Indizierungsaufwand in der Suchmaschine, Speicher- und/oder insbesondere Energiebedarf minimiert werden können, vorzugsweise ohne einen Nutzerkomfort vor Ort zu schmälern. Dies kann zudem vorteilhaft einen in zentralisierten Strukturen ansonsten mit der Datenmenge stark steigenden Energiebedarf begrenzen. Insbesondere werden die digitalen Inhalte redundant auch in der DLT oder entfernt von der Ankerstation abgespeichert, um ein Risiko eines Datenverlusts gering zu halten.

Zusätzlich wird ein Metaversum, insbesondere des Content Management Systems, vorgeschlagen, welches eine Vielzahl an Sub-Metaversen umfasst, welche jeweils durch ein Segment des das Metaversum definierenden virtuellen Raums gebildet sind und welche jeweils durch eine der auf die Distributed Ledger Technologie (DLT), wie z.B. einer Blockchain oder einem Tangle, aufgesetzten VolumeDAOs dezentral verwaltet sind. Vorteilhaft kann ein dezentral organisierter dreidimensionaler und der realen Welt überlagerter Wissensraum geschaffen werden, welcher insbesondere mit freiem, von jedermann erstelltem Wissen gefüllt werden kann.

Außerdem wird ein Computerprogrammprodukt, umfassend Befehle, die bei einer Ausführung des Programms durch einen Computer, beispielsweise ein Smartphone, ein Tablet, ein Notebook oder ein Schnittstellengerät, diesen veranlassen, die Schritte des Content Management Verfahrens auszuführen, vorgeschlagen. Insbesondere weist der Computer zumindest einen Prozessor und einen Speicher mit dem in der Speichereinheit gespeicherten Programm auf. Das erfindungsgemäße Content Management Verfahren, das erfindungsgemäße Content Management System, das erfindungsgemäße Metaversum und das erfindungsgemäße Computerprogrammprodukt sollen hierbei nicht auf die oben beschriebene Anwendung und Ausführungsform beschränkt sein. Insbesondere kann das erfindungsgemäße Content Management Verfahren, das erfindungsgemäße Content Management System, das erfindungsgemäße Metaversum und das erfindungsgemäße Computerprogrammprodukt 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 schematisch ein Metaversum eines erfindungsgemäßen Content Management Systems (CMS),

Fig. 2 ein vereinfachtes schematisches Schaubild des CMS,

Fig. 3 einen Teil eines schematischen Ablaufdiagramms eines Content Management Verfahrens (CMV) und

Fig. 4 einen weiteren Teil des Ablaufdiagramms des CMV. Beschreibung der Ausführungsbeispiele

Die Fig. 1 zeigt ein Metaversum 20 eines erfindungsgemäßen Content Management Systems (CMS 48). Das Metaversum 20 definiert einen virtuellen Raum 24. Der virtuelle Raum 24 ist dem real existierenden Raum überlagert. Der virtuelle Raum 24 ist weltkugelumspannend ausgebildet. Der virtuelle Raum 24 ist in eine Vielzahl an nebeneinander und übereinander angeordnete Segmente 26, 28 aufgeteilt. Die Segmente 26, 28 bilden jeweils Volumensegmente, z.B. Würfel, aus. Die Segmente 26, 28 sind alle identisch groß und identisch geformt. Den Segmenten 26, 28 können jeweils mehrere digitale Inhalte 10 zugeordnet werden. Die Segmente 26, 28 sind ferndurchsuchbar. Die den Segmenten 26, 28 zugeordneten digitalen Inhalte 10 sind ferndurchsuchbar. Das Metaversum 20 umfasst eine Vielzahl an Sub-Metaversen 38, 40. Die Sub-Metaversen 38, 40 sind jeweils durch ein Segment 26, 28 des gesamten das Metaversum 20 definierenden virtuellen Raums 24 gebildet. Jedes der Sub-Metaversen 38, 40 ist jeweils durch eine auf eine Distributed Ledger Technologie (DLT 16), wie z.B. einer Blockchain oder einem Tangle, aufgesetzte Decentralized Autonomous Organization (VolumeDAO 14) dezentral und eigenständig gegenüber anderen Sub-Metaversen 38, 40 verwaltet. Jedem der Segmente 26, 28 des das Metaversum 20 bildenden virtuellen Raums 24 wird ein übergeordnetes Volumen- Non-Fungible-Token (VolumeNFT 36) der DLT 16 zugeordnet. Das VolumeNFT 36 umfasst räumliche (Real-)Koordinaten, die das jeweilige Segment 26, 28 definieren und das jeweilige Segment 26, 28 mit dem real existierenden Raum verknüpfen. Das VolumeNFT 36 bildet dabei kein Governance-Token des VolumeDAO 14 aus. Das VolumeNFT 36 ist frei transferierbar.

Die Fig. 2 zeigt ein sehr vereinfachtes schematisches Schaubild des CMS 48. Das CMS 48 ist zu einer Verwaltung von digitalen Inhalten 10 vorgesehen. Das CMS 48 ist zu einer Verwaltung von digitalen Inhalten 10 innerhalb des Metaversums 20 vorgesehen. Das CMS 48 ist zu einer Verwaltung von digitalen Inhalten 10 innerhalb der Sub-Metaversen 38, 40 vorgesehen. Das CMS 48 ist zu einer Ausführung eines Computerprogrammprodukts vorgesehen, welches ein in der Folge beschriebenes Content Management Verfahren (CMV) umsetzt. Das CMS 48 ist zu einer Aufnahme und Ausgabe der digitalen Inhalte 10 an einen Nutzer 12 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. Das CMS 48 ist dezentral ausgebildet. Die Verwaltung der digitalen Inhalte 10 des dezentralen CMS 48 erfolgt dezentral über die 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 zentralisiert und/oder nichtöffentlich ausgebildet sein. Die DLT 16 ist vorzugsweise als ein IOTA™- Tangle ausgebildet. In der Fig. 2 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. 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 der VolumeDAOs 14 zugehörig, welche auf die DLT 16 aufgesetzt ist. Der Smart Contract 18 ist zu einer Verwaltung der digitalen Inhalte 10, insbesondere der Aufnahme und der Ausgabe der digitalen Inhalte 10, innerhalb der VolumeDAO 14 vorgesehen. Der Smart Contract 18 ist zu einer Steuerung von Abspiel-Freigaben für die digitalen Inhalte 10 innerhalb der VolumeDAO 14 vorgesehen. Der Smart Contract 18 ist zu einer Steuerung einer Integration von neuen digitalen Inhalten 10 in ein spezifisches CMS 48 des VolumeDAO 14 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 empfangen. Der Smart Contract 18 kann DLT- Antworttransaktionen an weitere DLT-Adressen der DLT 16 versenden. Auf die DLT 16 können viele Smart Contracts 18 vieler VolumeDAOs 14 aufgesetzt sein. 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 32 zuordenbaren, Inhalte-Abspielgerät 54 des CMS 48 und/oder einem, einem weiteren Nutzer 12 zuordenbaren Inhalte-Erstellungsgerät 52 vorgesehen. Prinzipiell wäre auch vorstellbar, dass die Inhalte-Abspielgeräte 54 und/oder die Inhalte-Erstellungsgeräte 52 direkt und unabhängig von Schnittstellengeräten 22 mit der DLT 16 kommunizieren. Das Schnittstellengerät 22 ist einem Nutzer 12, 32 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, 32 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, 32 vorgesehen. Das Lokalisierungsgerät 50 ist zu einer Bestimmung der Ortskoordinaten, an denen sich der Nutzer 12, 32 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, 32 zugeordneten Smartphone, empfangen. Das Schnittstellengerät 22 ist dazu vorgesehen, die ermittelten Lokalisierungen des Nutzers 12, 32 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, 32 auf digitale Inhalte 10, die sich in einem Bereich der Lokalisierung des Nutzers 12, 32 befinden, z.B. in einem Segment 26, 28, in dem sich der Nutzer 12, 32 momentan aufhält, 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, 32 vorgesehen. Das Lokalisierungsgerät 50 kann dazu vorgesehen sein, mit einer oder mehreren Ankerstationen 82 zu kommunizieren. Diese Kommunikation dient hauptsächlich zu der Lokalisierung der Momentanposition des Nutzers 12, 32, kann jedoch auch zur lokalen Übertragung von digitalen Inhalten 10 dienen. Die Ankerstation 82 ist in diesem Fall dazu vorgesehen, digitale Inhalte 10 redundant zur DLT 16 oder als Teil der DLT 16 lokal abzuspeichern.

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 identisch mit dem Schnittstellengerät 22 ausgebildet sein. Das Inhalte-Erstellungsgerät 52 kann mit dem Inhalte-Abspielgerät 54 identisch sein. In der beispielhaften Darstellung von Fig. 2 sind Inhalte-Erstellungsgerät 52 und Inhalte-Abspielgerät 54 jedoch verschieden und getrennt voneinander ausgebildet und insbesondere unterschiedlichen Nutzern 12, 32 zugeordnet.

Die Fig. 3 zeigt schematisch einen Teil eines Ablaufdiagramms des CMV. Das CMV ist als ein ortsbezogenes dezentralisiertes CMV ausgebildet. Das CMV ist zu einer Verwaltung von digitalen Inhalten 10 innerhalb des mit einer DLT 16 verknüpften Metaversums 20 vorgesehen. Die digitalen Inhalte 10 werden in dem CMV einzelnen Segmenten 26, 28 zugeordnet. In dem CMV werden zumindest den Segmenten 26, 28, denen digitale Inhalte 10 zugeordnet sind, jeweils auf die DLT 16 aufgesetzte VolumeDAOs 14 zugeordnet. Die VolumeDAOs 14 der einzelnen Segmente 26, 28 sind jeweils eigenständig und unabhängig voneinander. In zumindest einem Verfahrensschritt 42 betritt der Nutzer 12 eines der Segmente 26, 28. Dabei bewegt er sich im real existierenden Raum. In zumindest einem weiteren Verfahrensschritt 44 wird die geographische Position des Nutzers 12 ermittelt und/oder bestätigt. Die Ermittlung der geographischen Position des Nutzers 12 erfolgt über das Lokalisierungsgerät 50. Wenn der Aufenthalt des Nutzers 12 in dem Segment 26, 28 zuverlässig bestätigt ist, erhält der Nutzer 12 in einem weiteren Verfahrensschritt 46 die Erlaubnis einen digitalen Inhalt 10, der dann dem Segment 26, 28 zugeordnet werden soll, hochzuladen. In zumindest einem Verfahrensschritt 56 lädt der Nutzer 12 den digitalen Inhalt 10 hoch. Dabei kann der Nutzer 12 den digitalen Inhalt 10 beliebig innerhalb des Segments 26, 28 platzieren. In zumindest einem weiteren Verfahrensschritt 58 wird der neu in/aus dem Segment 26, 28 hochgeladene digitale Inhalt 10 durch die DLT 16 empfangen oder es wird eine Information, dass in/aus dem Segment 26, 28 ein digitaler Inhalt 10 hochgeladen wurde, von der DLT 16 empfangen. In dem Verfahrensschritt 58 erfolgt bei dem Empfang des hochgeladenen digitalen Inhalts 10 eine Zuordnung des digitalen Inhalts 10 zu dem jeweiligen Segment 26, 28 in dem virtuellen Raum 24 durch einen Rückgriff auf die in dem Verfahrensschritt 44 erfolgte Lokalisierung des das Hochladen initiierenden Nutzers 12 im durch den virtuellen Raum 24 überlagerten real existierenden Raum.

In zumindest einem weiteren Verfahrensschritt 60 wird in Reaktion auf das Hochladen des digitalen Inhalts 10 aus dem Segment 26, 28 ein Creator-Non- Fungible-Token (CreatorNFT 30) innerhalb der DLT 16 erzeugt. In dem Verfahrensschritt 60 wird der digitale Inhalt 10 mit dem CreatorNFT 30 auf der DLT 16 verknüpft. Das CreatorNFT 30 wird somit nur durch Nutzer 12 gemintet, welche das Segment 26, 28 im real existierenden Raum besucht haben. Das CreatorNFT 30 ist jedoch dennoch frei transferierbar. In zumindest einem weiteren Verfahrensschritt 62 wird überprüft, ob bereits eine dem Segment 26, 28 zugeordnete und auf die DLT 16 aufgesetzte VolumeDAO 14 existiert. In dem Verfahrensschritt 62 wird überprüft, ob bereits ein CreatorNFT 30 (oder ein FollowerNFT 34, siehe Fig. 4) zu dem Segment 26, 28 existiert. In zumindest einem Verfahrensschritt 64 wird eine neue VolumeDAO 14 für das Segment 26, 28 innerhalb der DLT 16 erstellt, falls die Überprüfung aus dem Verfahrensschritt 62 ergibt, dass bisher noch keine dem Segment 26, 28 zugeordnete VolumeDAO 14 existiert oder dass noch kein dem Segment 26, 28 zugeordnetes CreatorNFT 30 (oder FollowerNFT 34) existiert. In zumindest einem weiteren Verfahrensschritt 76 wird das erstellte CreatorNFT 30 an eine DLT-Adresse der DLT 16 versandt wird, welche dem Nutzer 12 zugeordnet ist, der den jeweiligen digitalen Inhalt 10 hochgeladen hat. Das CreatorNFT 30 bildet ein Governance-Token des VolumeDAO 14 aus. In Folgeverfahrensschritten kann dann zu jedem innerhalb des Segments 26, 28 hochgeladenen weiteren digitalen Inhalt 10’ jeweils ein weiteres CreatorNFT 30’ innerhalb der DLT 16 erzeugt werden, welches mit dem jeweiligen weiteren digitalen Inhalt 10’ verknüpft wird und welches ebenfalls ein Governance-Token des VolumeDAO 14 ausbildet.

Die Fig. 4 zeigt schematisch einen weiteren Teil des Ablaufdiagramms des CMV. Der Ablauf der Verfahrensschritte mit den Bezugszeichen 42’ und 44’ gleicht den bereits im Zusammenhang mit der Fig. 3 erläuterten Verfahrensschritten mit den Bezugszeichen 42 und 44, wobei der Nutzer 32 nun nicht die Absicht hat einen digitalen Inhalt 10 hochzuladen, sondern lediglich einem Segment 26, 28 / einem Sub-Metaversum 38, 40 als Follower zu folgen. Wenn der Aufenthalt des Nutzers 32 in dem Segment 26, 28 zuverlässig bestätigt ist, wird in einem weiteren Verfahrensschritt 66 ein Folgestatus des Nutzers 32 bezüglich des Segments 26, 28, in dem der Nutzer 32 sich aktuell befindet, ermittelt. Dabei wird ermittelt, ob der Nutzer 32 dem Segment 26, 28 bereits folgt oder nicht. Der Folgestatus ist für den Nutzer 32 ortsunabhängig für jedes der Segmente 26, 28 des Metaversums 20 änderbar. Wenn in dem Verfahrensschritt 66 ermittelt wird, dass der Nutzer 32 dem Segment 26, 28 noch nicht folgt, wird der Nutzer 32 in zumindest einem weiteren Verfahrensschritt 78 angefragt, ob er/sie Follower des Segments 26, 28 werden möchte. Wenn der Nutzer 32 dies bestätigt, wird eine Registration des Nutzers 32 als Follower des Segments 26, 28 initiiert. In zumindest einem Verfahrensschritt 68 wird die Registration des neuen Followers für das Segment 26 in dem CMS 48 empfangen. Durch die Registration wird dem Segment 26, 28 der Nutzer 32 als Follower zugeordnet. In zumindest einem weiteren Verfahrensschritt 70 wird - der positive Nachweis des Aufenthalts des Followers des Segments 26 an einem Ort im real existierenden Raum, welcher diesem Segment 26, 28 im virtuellen Raum 24 überlagert ist, vorausgesetzt - ein Follower- Non-Fungible-Token (FollowerNFT 34) innerhalb der DLT 16 erzeugt. Das FollowerNFT 34 wird somit nur durch Nutzer 32 gemintet, welche das Segment 26, 28 im real existierenden Raum besucht haben. Das FollowerNFT 34 ist jedoch dennoch frei transferierbar.

In zumindest einem weiteren Verfahrensschritt 72 wird überprüft, ob bereits eine dem Segment 26, 28 zugeordnete und auf die DLT 16 aufgesetzte VolumeDAO 14 existiert. In dem Verfahrensschritt 72 wird überprüft, ob bereits ein FollowerNFT 34 oder ein CreatorNFT 30 zu dem Segment 26, 28 existiert. In zumindest einem Verfahrensschritt 74 wird eine neue VolumeDAO 14 für das Segment 26, 28 innerhalb der DLT 16 erstellt, falls die Überprüfung aus dem Verfahrensschritt 72 ergibt, dass bisher noch keine dem Segment 26, 28 zugeordnete VolumeDAO 14 existiert oder dass noch kein dem Segment 26, 28 zugeordnetes FollowerNFT 34 (oder CreatorNFT 30) existiert. In zumindest einem weiteren Verfahrensschritt 80 wird das erstellte FollowerNFT 34 an eine DLT-Adresse der DLT 16 versandt, welche dem Nutzer 32 zugeordnet ist, der seinen Aufenthalt innerhalb des Segments 26, 28 nachgewiesen hat. Das FollowerNFT 34 bildet ein weiteres Governance-Token des VolumeDAO 14 aus. In Folgeverfahrensschritten wird dann zu jedem neuen Follower, der seinen Aufenthalt in dem Segment 26, 28 nachgewiesen hat, ein weiteres FollowerNFT 34’ innerhalb der DLT 16 erzeugt, welches mit dem jeweiligen neuen Follower zugesandt wird und welches ebenfalls ein Governance-Token des VolumeDAO 14 ausbildet.

Bezugszeichen

10 Digitaler Inhalt

12 Nutzer

14 VolumeDAO

16 DLT

18 Smart Contract

20 Metaversum

22 Schnittstellengerät

24 Virtueller Raum

26 Segment

28 Segment

30 CreatorNFT

32 Nutzer

34 FollowerNFT

36 VolumeNFT

38 Sub-Metaversum

40 Sub-Metaversum

42 Verfahrensschritt

44 Verfahrensschritt

46 Verfahrensschritt

48 CMS

50 Lokalisierungsgerät

52 Inhalte-Erstellungsgerät

54 Inhalte-Abspielgerät

56 Verfahrensschritt

58 Verfahrensschritt

60 Verfahrensschritt

62 Verfahrensschritt

64 Verfahrensschritt

66 Verfahrensschritt Verfahrensschritt Verfahrensschritt Verfahrensschritt Verfahrensschritt Verfahrensschritt Verfahrensschritt Verfahrensschritt Ankerstation