Die Erfindung betrifft ein Verfahren zur Bereitstellung von Diensten für eine Mehrzahl von verbundenen loT-Vorrichtungen und ein Computerprogrammprodukt umfassend eine Codeeinrichtung.

Im Internet der Dinge (Internet of Things, loT) bekommen Gegenstände eine eindeutige Identität und können miteinander kommunizieren oder Befehle entgegennehmen.

Aus der WO 2019/057330 A1 sind ein Verfahren zur Nutzung einer Rechnereinheit eines autonom bewegbaren Fahrzeuges und ein zum Durchführen eines solchen Verfahrens ausgebildetes Fahrzeug bekannt. Es ist vorgesehen, dass bei einem Ladevorgang eines elektrischen Energiespeichers des Fahrzeuges eine Rechenleistung der Rechnereinheit zumindest einem externen Computernetzwerk und/oder einem Computerverbund zur Verfügung gestellt wird.

Fig. 1 zeigt das bekannte Konzept eines Marktplatzes nach dem sogenannten „Ocean Protocol“. Dabei sind Datenbereitsteller bzw. -anbieter 1 , Marktplatz 2 und Datenkonsument bzw. -Verbraucher 3 dargestellt. Daten 4, Service-Daten 5 und Tokens 6 werden jeweils zwischen Datenbereitsteller 1 und Marktplatz 2 bzw. zwischen Marktplatz 2 und Datenkonsument 3 zur Verfügung gestellt. Das „Ocean Protocol“ bietet einen zweiseitigen Marktplatz für Daten an, die auf Distributed Ledger-Technologie (DLT) basieren. Dabei bleibt das ungelöste Problem wie eine Datenbereitstellung für Millionen endkundeneigener verbundener loT-Vorrichtungen, wie beispielsweise verbundene Fahrzeuge, im Vorfeld auf der Seite der Datenanbieter gehandhabt werden kann.

Die Aufgabe der hier vorliegenden Erfindung liegt darin, ein Konzept mit ganzheitlichem Ansatz zur Verwaltung und Monetarisierung jeglicher Art von Diensten bereitzustellen, die eine verbundene loT-Vorrichtung für jeden dezentralen Marktplatz bereitstellen kann, um sein Dienstangebot auf diesem Marktplatz auf sichere und vertrauenswürdige Weise zu monetarisieren.

Diese Aufgabe wird durch den Gegenstand der unabhängigen Patentansprüche gelöst. Vorteilhafte Ausgestaltungen sind in den Unteransprüchen definiert.

Gemäß einem ersten Aspekt der Erfindung wird diese Aufgabe durch ein Verfahren zur Bereitstellung von Diensten für eine Mehrzahl von verbundenen loT-Vorrichtungen gelöst, wobei eine loT-Vorrichtung als eine Dienstanbieter-Instanz bzw. als eine Service Provider-Instanz (SPI) ausgestaltet wird und die loT-Vorrichtung eine Mehrzahl von Diensten bereitstellt, und wobei die Dienste auf von der loT-Vorrichtung erzeugten Daten basieren, auf Rechenressourcen der loT-Vorrichtung auf Raum- und/oder Transportkapazitäten der loT-Vorrichtung, auf Energieressourcen der loT-Vorrichtung und/oder auf der elektrischen Energiespeicherkapazität der loT-Vorrichtung.

Einige nicht einschränkende Beispiele hierfür könnten die Bereitstellung von Rechenleistung oder Speicherkapazität sein. Auch der Transport von Personen und Gütern durch z.B. durch ein Robotaxi kann angeboten werden, ebenso die Bereitstellung von Aufenthaltsräumen jeglicher Art für Personen (z.B. als Schlaf-, Relax- oder Sitzgelegenheit) oder für Waren. Dazu könnten z.B. die Innenräume von Fahrzeugen genutzt werden, z.B. der Innenraum eines Vans als Zwischenlager-Raum während der Distribution oder Auslieferung von Waren. Ferner kann an eine Bereitstellung einer Plattform, z.B. in Form von Energieversorgung und Transport von A nach B, für Module, die z.B. Personen oder Güter befördern, gedacht werden.

Gemäß einer vorteilhaften Weiterbildung wird eine Verwaltungsschicht für Dienstbereitstellungkampagnen bereitgestellt, um Service-Provisioning-Eigenschaften der einzelnen Dienstanbieter-Instanzen (SPI) zu erfassen und in einem Dienstanbieter- Instanz-spezifischen Service-Provisioning-Profil (SPP) zusammenzufassen. Die Verwaltungsschicht für Dienstbereitstellungkampagnen bewirkt vorteilhafterweise die Entkoppelung der Dienstanbieter-Instanzen (SPI) von den Marktplätzen und damit von den Dienstleistungs-Nutzern. Gemäß einer vorteilhaften Weiterbildung umfasst das Service-Provisioning-Profil (SPP) technische Fähigkeiten der Dienstanbieter-Instanzen (SPI), Nutzereinstellungen des Eigentümers und/oder des Nutzers der Dienstanbieter-Instanz und Nutzungsmuster, die ein Dienst der künstlichen Intelligenz automatisch aus der Nutzung der Dienstanbieter- Instanz (SPI) ableitet. Vorzugsweise wird die Dienstanbieter-Instanz mit den verfügbaren Marktplätzen gekoppelt und ein Monetarisierungsdienst für Kunden, die die Dienstanbieter-Instanzen betreiben, bereitgestellt.

Gemäß einer anderen vorteilhaften Weiterbildung wird ein automatisierter Ablauf durchgeführt, nach dem ein Nutzer ein Angebot der Dienstanbieter-Instanz akzeptiert.

Gemäß einer anderen vorteilhaften Weiterbildung handeln Dienstanbieter und Dienstnutzer einen Smart Contract bzw. einen intelligenten Vertrag aus. Damit ist die erfindungsgemäße Idee vorteilhafterweise flexibel und erweiterbar. Vorzugsweise sind die Identitäten der beteiligten Personen bzw. von Dienstanbietern und Dienstnutzern bekannt und vertrauenswürdig.

Gemäß einer anderen vorteilhaften Weiterbildungen wird der Kundenidentifizierungsprozess anhand biometrischer und/oder anderer Merkmale der Person bzw. des Nutzers durchgeführt, um ihn zu identifizieren. Damit wird der Kunde für diesen Anwendungsfall der Zuweisung der richtigen Kundenrolle eindeutig identifiziert.

Gemäß einem zweiten Aspekt der Erfindung wird die Aufgabe durch ein Computerprogrammprodukt umfassend eine Codeeinrichtung gelöst, die geeignet zum Ausführen der Schritte eines Verfahrens nach dem ersten Aspekt der Erfindung ist, wenn es auf einem Computer ausgeführt wird.

Eine Idee der vorliegenden Erfindung beruht darauf, eine verbundene loT-Vorrichtung, beispielsweise ein verbundenes Fahrzeug, als eine Dienstanbieter-Instanz auszugestalten, die in der Lage ist, verschiedene Dienste bereitzustellen, die monetarisierbar sind. Diese Dienste basieren vorzugsweise auf Daten, die die loT- Vorrichtung erzeugt, auf den Rechenressourcen und/oder auf der elektrischen Energiespeicherkapazität, mit der die loT-Vorrichtung ausgestattet ist. Vorteilhafterweise kann jede Art von Dienst, der auf den Ressourcen und Fähigkeiten der verbundenen loT-Vorrichtungen basiert, durch die erfindungsgemäßen Idee verwaltet und monetarisiert werden. Die Handhabung der Dienste ist unabhängig von der Art des Dienstes und ist auf ein Höchstmaß an Automatisierung bei gleichzeitiger Aufrechterhaltung eines Höchstmaßes an Zuverlässigkeit und Vertrauen für die entsprechenden Eigentümer bzw. Betreiber der Dienstanbieter-Instanzen sowie für die Nutzer des Dienstes ausgerichtet.

Die erfindungsgemäße Idee basiert auf der Anwendung der "Economy of Things" im Zusammenhang mit einer verbundenen loT-Vorrichtung, die mit Endkunden, wie Personenfahrzeugen oder anderen Transportsystemen, interagiert. Insbesondere werden Maschinen in die Lage versetzt, Geschäftstransaktionen automatisch, selbstständig und ohne direkten Eingriff eines Menschen durchzuführen. Dies funktioniert natürlich auch in umgekehrter Richtung, wenn beispielsweise das Fahrzeug selbst Dienste von außen in Anspruch nimmt, wie insbesondere: beim Empfang von Energie; bei der Nutzung der Infrastruktur, beispielsweise Straßenbenutzungsgebühren; beim Be- und Entladen von Fracht; bei Reinigungsdiensten und bei Reparatur- und Wartungsdienstes. Vorteilhafterweise können diese Dienste über die gleichen Marktplätze betrieben werden, jedoch mit der entgegengesetzten Rolle als Verbraucher und nicht als Dienstleister.

Nachfolgend wird die Erfindung anhand dreier bevorzugten Ausführungsbeispiele unter Bezugnahme auf die Zeichnung weiter im Detail erläutert.

Dabei zeigen:

Fig. 1 das Konzept des Ozeanprotokoll-Marktplatzes gemäß dem Stand der Technik;

Fig. 2 ein beispielhaftes ganzheitliches Konzept zur Monetarisierung von loT- Vorrichtungen in einer möglichen Ausgestaltung;

Fig. 3 ein Onboard-Kontextmanagementsystem mit mehreren Aggregationsebenen (Zeilen) und mehreren Domänenperspektiven (Spalten) in einer anderen möglichen Ausgestaltung; und

Fig. 4 ein ganzheitliches Konzept zur Monetarisierung der Dienstbereitstellung für loT- Vorrichtungen mit Identitätsmanagement in einer anderen möglichen Ausgestaltung. Fig. 2 zeigt eine loT-Vorrichtung, wie beispielsweise ein Straßenfahrzeug, die als Dienstanbieter-Instanz 7 (SPI1) ausgestaltet ist in einem ersten bevorzugten Ausführungsbeispiel der Erfindung. In diesem ersten bevorzugten Ausführungsbeispiel der Erfindung befinden sich mehrere Service-Managementsysteme 10, wie Rechen- 8, Energie- 9 oder Datenressourcen 11 , zusammen mit dem Service-Managementsystem 10 der Dienstanbieter-Instanz 7 an Bord. Im Backend 14 des Erstausrüsters (Original Equipment Manufacturer, OEM) befinden sind das Dienstmonetarisierungsmanagement- System 16 und das Kundenmanagementsystem 15.

In anderen bevorzugten Ausführungsbeispielen befinden sich Teile der genannten Service-Management-Systeme bzw. -module auch in der Cloud.

Ein zentralisiertes Dienstmonetarisierungsmanagement-System 16 (Service Monetisation Management System, SMMS) integriert die Dienstanbieter-Instanz 7 mit den entsprechenden Kunden aus dem Kundenmanagementsystem 15. Darüber hinaus integriert das SMMS 16 mehrere dezentralisierte Marktplätze, die sich unabhängig voneinander entwickeln können, da sie unterschiedliche Arten von Dienstleistungen oder sogar völlig unterschiedliche Branchen und Marktmerkmale bedienen können.

Um einen möglichst hohen Automatisierungsgrad zu erreichen und gleichzeitig das Vertrauen der entsprechenden Marktteilnehmer zu erhalten, bauen diese dezentralen Marktplätze auf der Distributed-Ledger-Technologie (DLT) auf. Der Daten- 20, der Energie- 21 und der Rechen-Marktplatz 22 sind alle dezentral und basieren auf DLT 17, 18, 19. Zwei Datenkonsumenten 23, 24 sind auf dem dezentralen Daten-Marktplatz 20, ein Energiespeicherkonsument 25 ist auf dem dezentralen Energie-Marktplatz 21 und zwei Rechenressourcen-Konsumenten 26 sind auf dem dezentralen Rechen-Marktplatz 22.

In anderen bevorzugten Ausführungsbeispielen werden diese Marktplätze einerseits erlaubte und private Netzwerke sein, während andere gleichzeitig als erlaubnisfreie und öffentliche Netzwerke konzipiert sind. Selbst die gewählte Variante der DLT könnte sich deutlich unterscheiden, wobei alle diese Varianten im SMMS eingekapselt werden. In anderen bevorzugten Ausführungsbeispielen befinden sich die Service-Management- Funktionen für die Dienstanbieter-Instanz SPI1 im "digitalen Zwilling" der Dienstanbieter- Instanz SPI1 im Backend oder in der Cloud des Erstausrüsters (OEM). In einer solchen Architektur haben diese Management-Funktionen Schnittstellen zum "physikalischen Zwilling", der realen loT-lnstanz, um die relevanten Daten auszutauschen.

Um dieses System funktionsfähig zu machen, sollten vorzugsweise mehrere Voraussetzungen definiert werden:

Erstens sollte eine Nachfrage nach einem bestimmten Service oder Dienst bestehen, den der OEM definiert und den die verbundene Dienstanbieter-Instanz liefert. Die Geschäftsparameter rund um dieses Dienstprodukt müssen entsprechend definiert werden: Preismodell, Service-Levels und Dienstqualitätsdefinitionen, rechtliche Aspekte, Zahlungsprozesse usw. Diese geschäftlichen Aspekte müssen geklärt und Vertragsdetails für die konkreten Dienstleistungsprodukte in den bevorzugten Ausführungsbeispielen im Vorfeld definiert werden.

Zweitens sollte ein Geschäftsrahmen geschaffen werden, der alle Aspekte der Geschäftsbeziehung zwischen dem OEM und dem Kundenstamm der API-Flotte abdeckt, die zu Geschäftspartnern werden, sobald der Dienst in Betrieb genommen wird. Dies ist ebenfalls ein Bereich, der in den bevorzugten Ausführungsbeispielen abgedeckt wird. Dabei steht API für eine „Schnittstelle zur Anwendungsprogrammierung“(„Application-Programming-lnter face“).

Drittens sollte ein Dienstkampagnen-Managementsystem eingerichtet werden, das in der Lage ist, zwischen den Dienstproduktangeboten auf den Dienstmarktplätzen, den Dienstanbieter-Instanzen (SPIs) und den Dienstkunden zu orchestrieren. Dies ist eine Funktion, die innerhalb des SMMS enthalten ist.

Sobald diese Vorbedingungen definiert sind, wird der Dienstbetriebsprozess vorzugsweise wie folgt durchgeführt werden:

Erstens: Der OEM definiert das Dienstprodukt, richtet eine Dienstkampagne ein und kommuniziert das Dienstangebot an den entsprechenden Marktplatz. Zweitens: Die Dienstanbieter-Instanzen (SPIs) erstellen, pflegen und kommunizieren ihre Dienstbeschaffungsprofile bzw. Service-Provisioning-Profile (SPP) regelmäßig gegenüber dem SMMS. Innerhalb dieser Profile werden in generischer und semantisch korrekter Weise alle Details beschrieben, welche Dienstleistungen von den konkreten Dienstanbieter-Instanzen unter allen relevanten Aspekten angeboten werden. Als Grundlage enthält die SPP die harten technischen Parameter und Fähigkeiten der Dienstanbieter-Instanzen, wie verfügbare Datenpunkte, Qualitäts- und Update-Details, Energiespeicherkapazitäten, Rechenkapazitäten usw. Der Eigentümer bzw. der Betreiber der Dienstanbieter-Instanz SPI definiert, welche Dienste in welchem Umfang und in welchem Zeitrahmen zur Verfügung stehen.

Drittens: Basierend auf den verfügbaren Dienstanbieter-Instanzen der Flotte der OEMs, die am Marktplatzsystem teilnehmen, werden die SPPs durch das SMMS analysiert und gefiltert, die den Kriterien der Dienstkampagne entsprechen.

Viertens: Sobald vom Marktplatz eine Anfrage zu einem bestimmten Dienstprodukt eingeht, sendet das SMMS die Anfrage an eine Dienstanbieter-Instanz, die in der Lage und verfügbar ist, die angeforderte Dienstleistung zu erbringen.

Fünftens: Der Dienst wird von einer Dienstanbieter-Instanz geliefert und am Ende der Lieferphase vom entsprechenden Dienstkonsumenten bezahlt.

Sechstens: Der vordefinierte Anteil der in den intelligenten Verträgen (Smart Contracts) der entsprechenden Marktplatzlösungen definierten Einnahmen wird vom SMMS auf das Konto des Kunden, der Eigentümer bzw. der Betreiber der Dienstanbieter-Instanz ist, überwiesen.

In einigen anderen bevorzugten Ausführungsbeispielen ist es möglich, mit der eigenen digitalen Identität und dem eigenen Konto der Dienstanbieter-Instanz zu arbeiten. In diesem Fall erhält die Dienstanbieter-Instanz das Geld selbst, und der entsprechende Eigentümer bzw. Betreiber wird von dieser zusätzlichen Einnahmequelle profitieren. Alternativ könnten auch Tokens als Währungsersatz ausgetauscht werden, die sich dann in entsprechender Menge wieder in reale Währungen umtauschen lassen. Somit können auch Micropayments einfach ermöglicht werden.

Fig. 3 zeigt ein Onboard-Kontextmanagementsystem mit mehreren Aggregationsebenen (Zeilen) und mehreren Domänenperspektiven (Spalten) in einem zweiten bevorzugten Ausführungsbeispiel der Erfindung. Das Onboard-Kontextmanagementsystem 28 als Teil der Dienstanbieter-Instanz SPI wird dermaßen erweitert, dass es eine Datenquelle für jede Art von Datendienstprodukt bietet. Das Element "Datenrekorder" 37 in diesem Diagramm dient als Schnittstelle zu den Onboard-Kontextdaten, die die Quelle für ein Datendienstprodukt sind, das vom Eigentümer bzw. vom Betreiber der Dienstanbieter- Instanz SPI monetarisiert wird.

Das Onboard-Kontextmanagementsystem 28 gemäß dem zweiten bevorzugten Ausführungsbeispiel der Erfindung weist in seinen jeweiligen Zeilen Anwendungen 29, Kontext 30, Bedeutung 31 und rohe Sensordaten 32 auf, wobei die rohen Sensordaten 32 die Daten in „Informationen“ transformieren, bevor diese in „Wissen“ und „Weisheit“ transformiert werden. In den Spalten sind andere Objekte, Individuen und deren Verhalten 33, Wetterbedingungen und -trends 34, Verkehrsbedingungen und -trends 35, eigenes Verhalten 36 und der bereits genannte Datenrekorder 37 aufgeführt.

In anderen bevorzugten Ausführungsbeispielen gibt es keinen einzigen Kunden, der das verbundene Fahrzeug ganz allein besitzt, betreibt und nutzt. Es gibt dabei zumindest die folgenden Kundenrollen, die zu berücksichtigen sind:

Der Eigentümer hat den Kauf des Fahrzeugs finanziert und ist der Investor dieses Vermögens; der Pächter unterzeichnete einen Vertrag mit dem Eigentümer, um das Fahrzeug für eine bestimmte Zeit zu besitzen; der Fahrer hält die Schlüssel und definiert damit, wohin das Fahrzeug fährt und wer als Passagier in das Fahrzeug einsteigt; und der Passagier bzw. Fahrgast, dem der Fahrer den Zugang zu einem bestimmten Sitz oder einer bestimmten Stelle im Fahrzeug gewährt. In einigen bevorzugten Ausführungsbeispielen bestimmt der Fahrgast, wohin das Fahrzeug fährt, beispielsweise in einem Taxi, wohingegen in anderen bevorzugten Ausführungsbeispielen die Route vorgegeben ist, beispielsweise in einem Bus. Jedes Fahrzeug braucht zumindest die Rolle des Eigentümers, wobei einige Fahrzeuge nicht die Rolle eines Fahrers benötigen, wenn es sich um völlig autonome Robo-Autos oder Robo-Busse handelt. Oftmals sind einige dieser Rollen in einer einzigen Person kombiniert.

Vorzugsweise ist für die Monetarisierung der Fahrzeugdaten, insbesondere wenn die Rollen auf verschiedene Parteien verteilt sind, eine klare Definition hilfreich, wer welchen Teil der Einnahmen, die das Fahrzeug generiert, erhält.

Es ist eine Idee der vorliegenden Erfindung eine statische Definition des Einnahmeanteils vorzuschlagen, die unabhängig von den konkreten Dateninhalten oder von der Datenmenge ist. Diese Definition des Umsatzanteils sollte vorzugsweise im Vorfeld definiert und für alle Teilnehmer des Ökosystems "Kunde vs. OEM" transparent gemacht werden. Diese Definitionen sollten vorzugsweise innerhalb jeder Datenkampagne durch den OEM definiert werden und sollten vorzugsweise in den entsprechenden intelligenten Verträgen bzw. Smart Contracts umgesetzt werden.

In einem anderen bevorzugten Ausführungsbeispiel lautet eine Definition des Begriffs Einnahmeanteil: OEM: 30%, der Eigentümer: 30%, der Pächter: 20 %, der Fahrer: 10% und alle Passagiere zusammen: 10%.

In wieder anderen bevorzugten Ausführungsbeispielen lautet eine Definition des Begriffs Einnahmeanteil: Ein angestellter Taxifahrer, der keine Fahrgäste an Bord hat: 20%, ein Privatkunde, der ein Fahrzeug kauft und allein fährt: 70%, und ein Privatkunde, der ein Fahrzeug least und allein fährt: 40%.

Fig. 4 zeigt ein ganzheitliches Konzept zur Monetarisierung der Dienstbereitstellung für loT-Vorrichtungen mit Identitätsmanagement in einem dritten bevorzugten Ausführungsbeispiel der Erfindung. Fig. 4 unterscheidet sich von Fig. 2 durch den Einsatz selbstbestimmter Identitätstechnologie, die in das bordeigene Identity- Management-System 12 implementiert ist und mit einer Anwendung im persönlichen Smartphone 13 der Person bzw. des Nutzers kommuniziert. Sobald sich die Person beispielsweise beim Einsteigen in das Fahrzeug in die entsprechende Rolle "eingecheckt" hat, werden Rolle und Identität abgeglichen und die Verwaltung der Einnahmebeteiligung erfolgt.