EP4010871A1 - Verfahren zur bereitstellung von diensten für iot-vorrichtungen - Google Patents

Verfahren zur bereitstellung von diensten für iot-vorrichtungen

Info

Publication number
EP4010871A1
EP4010871A1 EP21743126.1A EP21743126A EP4010871A1 EP 4010871 A1 EP4010871 A1 EP 4010871A1 EP 21743126 A EP21743126 A EP 21743126A EP 4010871 A1 EP4010871 A1 EP 4010871A1
Authority
EP
European Patent Office
Prior art keywords
service
service provider
services
lot
lot device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP21743126.1A
Other languages
English (en)
French (fr)
Inventor
Christian Seiler
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
Daimler AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Daimler AG filed Critical Daimler AG
Publication of EP4010871A1 publication Critical patent/EP4010871A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0645—Rental transactions; Leasing transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06315—Needs-based resource requirements planning or analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Qualifying participants for shopping transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5015—Service provider selection
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00—Economic sectors
    • G16Y10/40—Transportation

Definitions

  • the invention relates to a method for providing services for a plurality of connected IoT devices and a computer program product comprising a code device.
  • objects are given a unique identity and can communicate with one another or receive commands.
  • WO 2019/057330 A1 discloses a method for using a computer unit of an autonomously movable vehicle and a vehicle designed to carry out such a method. Provision is made for computing power of the computer unit to be made available to at least one external computer network and/or a computer network during a charging process of an electrical energy store in the vehicle.
  • the "Ocean Protocol” offers a two-way marketplace for data based on distributed ledger technology (DLT). Thereby, the unsolved problem remains how data provisioning for millions of consumer-owned connected IoT devices, such as connected vehicles, can be handled in advance on the data provider side.
  • DLT distributed ledger technology
  • the object of the present invention is to provide a concept with a holistic approach to the management and monetization of any type of service that a connected loT device can provide for any decentralized marketplace, to monetize its service offering on this marketplace in a secure and trusted manner.
  • this object is achieved by a method for providing services for a plurality of connected loT devices, wherein a loT device as a service provider entity or as a service provider entity (SPI) is configured and the loT device provides a plurality of services, and wherein the services are based on data generated by the loT device, on computing resources of the loT device, on space and/or transport capacities of the loT device, on energy resources of the loT device and/or or on the electrical energy storage capacity of the loT device.
  • a loT device as a service provider entity or as a service provider entity (SPI) is configured and the loT device provides a plurality of services
  • the services are based on data generated by the loT device, on computing resources of the loT device, on space and/or transport capacities of the loT device, on energy resources of the loT device and/or or on the electrical energy storage capacity of the loT device.
  • Some non-limiting examples of this could be the provision of computing power or storage capacity.
  • the transport of people and goods e.g. by a robotaxi, can also be offered, as well as the provision of lounges of any kind for people (e.g. as sleeping, relaxing or seating) or for goods.
  • the interior of vehicles could be used, e.g. the interior of a van as an interim storage room during the distribution or delivery of goods.
  • Provision of a platform e.g. in the form of energy supply and transport from A to B, for modules that transport people or goods, for example, can also be considered.
  • a management layer for service provision campaigns is provided in order to record service provisioning properties of the individual service provider entities (SPI) and combine them in a service provider entity-specific service provisioning profile (SPP).
  • the management layer for service provision campaigns advantageously causes the decoupling of the service provider entities (SPI) from the marketplaces and thus from the service users.
  • the service provisioning profile (SPP) includes technical capabilities of the service provider instances (SPI), user settings of the owner and/or the user of the service provider instance and usage patterns that an artificial intelligence service automatically derives from the use of the Service Provider Instance (SPI) derives.
  • the service provider entity is coupled to the available marketplaces and a monetization service is provided to customers who operate the service provider entities.
  • an automated process is carried out, after which a user accepts an offer from the service provider entity.
  • service providers and service users negotiate a smart contract or an intelligent contract.
  • the idea according to the invention is thus advantageously flexible and expandable.
  • the identities of the persons involved or of service providers and service users are preferably known and trustworthy.
  • the customer identification process is carried out using biometric and/or other characteristics of the person or user in order to identify him. This clearly identifies the customer for this use case of assigning the correct customer role.
  • the object is achieved by a computer program product comprising code means suitable for carrying out the steps of a method according to the first aspect of the invention when run on a computer.
  • An idea of the present invention is based on designing a connected IoT device, for example a connected vehicle, as a service provider entity capable of providing various services that can be monetized. These services are preferably based on data that the IoT device generates, on the computing resources and/or on the electrical energy storage capacity that the IoT device is equipped with.
  • any kind of service based on the resources and capabilities of the connected IoT devices can be managed and monetized by the inventive idea.
  • the handling of the services is independent of the type of service and is designed for a maximum of automation while maintaining a maximum of reliability and trust for the respective owners or operators of the service provider entities as well as for the users of the service.
  • the idea according to the invention is based on the application of the "economy of things" in connection with a connected loT device that interacts with end customers, such as passenger vehicles or other transport systems.
  • machines will be able to carry out business transactions automatically, autonomously and without direct human intervention.
  • this also works in the opposite direction, for example if the vehicle itself uses external services, such as in particular: when receiving energy; when using infrastructure, such as road tolls; when loading and unloading cargo; for cleaning services and for repair and maintenance services.
  • these services can be operated through the same marketplaces, but with the opposite role of consumer and not service provider.
  • Fig. 1 shows the concept of the ocean protocol marketplace according to the prior art
  • FIG. 3 shows an onboard context management system with multiple aggregation levels (rows) and multiple domain perspectives (columns) in another possible embodiment
  • FIG. 4 shows a holistic concept for monetizing the provision of services for IoT devices with identity management in another possible embodiment.
  • 2 shows an IoT device, such as a road vehicle, which is designed as a service provider entity 7 (SPI1) in a first preferred exemplary embodiment of the invention.
  • SPI1 service provider entity 7
  • the service monetization management system 16 and the customer management system 15 are located in the backend 14 of the original equipment manufacturer (OEM).
  • OEM original equipment manufacturer
  • parts of the service management systems or modules mentioned are also located in the cloud.
  • a centralized service monetization management system 16 (Service Monetization Management System, SMMS) integrates the service provider instance 7 with the corresponding customers from the customer management system 15.
  • SMMS 16 integrates several decentralized marketplaces that can develop independently of each other, as they are different types of services or even completely different industries and market characteristics.
  • these decentralized marketplaces are based on distributed ledger technology (DLT).
  • DLT distributed ledger technology
  • the data 20, energy 21 and computing marketplace 22 are all decentralized and based on DLT 17, 18, 19.
  • Two data consumers 23, 24 are on the decentralized data marketplace 20
  • one energy storage consumer 25 is on the decentralized energy marketplace 21
  • two computing resource consumers 26 are on the decentralized computing marketplace 22.
  • these marketplaces will be permissioned and private networks on the one hand, while others are designed to be permissionless and public networks at the same time. Even the chosen variant of the DLT could differ significantly, with all of these variants being encapsulated in the SMMS.
  • the service management functions for the service provider entity SPI1 are located in the "digital twin" of the service provider entity SPI1 in the backend or in the cloud of the original equipment manufacturer (OEM). In such an architecture, these management functions have interfaces to the "physical twin", the real loT instance, in order to exchange the relevant data.
  • API stands for an "Application Programming Interface”.
  • a service campaign management system should be established that is able to orchestrate between the service product offerings in the service marketplaces, the service provider entities (SPIs), and the service customers. This is a function contained within the SMMS.
  • the service operation process will preferably be performed as follows:
  • the OEM defines the service product, establishes a service campaign, and communicates the service offering to the appropriate marketplace.
  • the service provider entities create, maintain and communicate their service procurement profiles or service provisioning profiles (SPP) to the SMMS on a regular basis.
  • SPP service provisioning profiles
  • all details are described in a generic and semantically correct manner, which services are offered by the specific service provider instances under all relevant aspects.
  • the SPP contains the hard technical parameters and capabilities of the service provider instances, such as available data points, quality and update details, energy storage capacities, computing capacities, etc.
  • the owner or operator of the service provider instance SPI defines which services and to what extent and in what time frame are available.
  • the SPPs are analyzed and filtered by the SMMS that match the service campaign criteria.
  • the SMMS sends the request to a service provider entity that is able and available to provide the requested service.
  • the service is delivered by a service provider entity and paid for by the corresponding service consumer at the end of the delivery phase.
  • the service provider entity receives the money itself, and the relevant owner or operator will benefit from this additional revenue stream.
  • tokens could also be exchanged as a currency substitute, which then can be exchanged back into real currencies in the corresponding amount. This means that micropayments can also be easily made possible.
  • FIG. 3 shows an onboard context management system with multiple aggregation levels (rows) and multiple domain perspectives (columns) in a second preferred embodiment of the invention.
  • the onboard context management system 28 as part of the service provider entity SPI is extended in such a way that it offers a data source for any type of data service product.
  • the "data recorder" element 37 in this diagram serves as an interface to the onboard context data that is the source for a data service product monetized by the owner/operator of the service provider entity SPI.
  • the onboard context management system 28 has in its respective rows applications 29, context 30, meaning 31 and raw sensor data 32, the raw sensor data 32 transforming the data into "information” before transforming it into “knowledge”. and “wisdom” are transformed.
  • Other objects, individuals and their behavior 33, weather conditions and trends 34, traffic conditions and trends 35, personal behavior 36 and the already mentioned data recorder 37 are listed in the columns.
  • the owner financed the purchase of the vehicle and is the investor of this asset; the lessee signed a contract with the owner to own the vehicle for a period of time; the driver holds the keys and thus defines where the vehicle is going and who gets into the vehicle as a passenger; and the passenger to whom the driver allows access to a specific seat or location in the vehicle.
  • the passenger determines where the vehicle is going, e.g. in a taxi, whereas in other preferred embodiments the route is predetermined, e.g. in a bus. Every vehicle needs at least the role of owner, while some vehicles do not need the role of driver when it comes to fully autonomous robo-cars or robo-buses. Often, some of these roles are combined into a single person.
  • a clear definition of who gets which part of the revenue generated by the vehicle is preferably helpful for the monetization of the vehicle data, especially if the roles are distributed among different parties.
  • This definition of the revenue share should preferably be defined in advance and made transparent for all participants in the "customer vs. OEM" ecosystem. These definitions should preferably be defined within each data campaign by the OEM and should preferably be implemented in the corresponding smart contracts.
  • a definition of the term revenue share is: OEM: 30%, the owner: 30%, the tenant: 20%, the driver: 10%, and all passengers together: 10%.
  • a definition of the term revenue share is: A hired taxi driver who has no passengers on board: 20%, a private customer who buys a vehicle and drives alone: 70%, and a private customer who leases a vehicle and drives alone drives: 40%.
  • FIG. 4 shows a holistic concept for monetizing the provision of services for IoT devices with identity management in a third preferred exemplary embodiment of the invention.
  • FIG. 4 differs from FIG. 2 by the use of self-determined identity technology, which is implemented in the on-board identity management system 12 and communicates with an application in the person's or user's personal smartphone 13 . As soon as the person moves into the appropriate role, for example when entering the vehicle "Checked In”, role and identity are matched and revenue sharing management is done.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Bereitstellung von Diensten für eine Mehrzahl von verbundenen loT-Vorrichtungen und ein Computerprogrammprodukt umfassend eine Codeeinrichtung. Beim erfindungsgemäßen Verfahren wird eine loT-Vorrichtung als eine Dienstanbieter-Instanz (7) ausgestaltet und die loT-Vorrichtung stellt eine Mehrzahl von Diensten bereit, wobei die Dienste auf von der loT-Vorrichtung erzeugten Daten basieren, auf Rechenressourcen der loT-Vorrichtung und/oder auf der elektrischen Energiespeicherkapazität der loT-Vorrichtung.

Description

Verfahren zur Bereitstellung von Diensten für loT-Vorrichtungen
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-lnterface“).
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.

Claims

Patentansprüche Verfahren zur Bereitstellung von Diensten für eine Mehrzahl von verbundenen loT- Vorrichtungen dadurch gekennzeichnet, dass eine loT-Vorrichtung als eine Dienstanbieter-Instanz (7) ausgestaltet wird und die loT-Vorrichtung eine Mehrzahl von Diensten bereitstellt, 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. Verfahren zur Bereitstellung von Diensten nach Anspruch 1, dadurch gekennzeichnet, dass eine Verwaltungsschicht für Dienstbereitstellungkampagnen bereitgestellt wird, um Service-Provisioning-Eigenschaften der einzelnen Dienstanbieter-Instanzen (7) zu erfassen und in einem Dienstanbieter-Instanz-spezifischen Service-Provisioning- Profil zusammenzufassen. Verfahren zur Bereitstellung von Diensten nach Anspruch 2, dadurch gekennzeichnet, dass das Service-Provisioning-Profil technische Fähigkeiten der Dienstanbieter- Instanzen (7), Nutzereinstellungen des Eigentümers und/oder des Nutzers der Dienstanbieter-Instanz (7) und Nutzungsmuster, die ein Dienst der künstlichen Intelligenz automatisch aus der Nutzung der Dienstanbieter-Instanz (7) ableitet, umfasst. Verfahren zur Bereitstellung von Diensten nach Anspruch 3, dadurch gekennzeichnet, dass die Dienstanbieter-Instanz (7) mit den verfügbaren Marktplätzen (20, 21 , 22) gekoppelt wird und ein Monetarisierungsdienst für Kunden, die die Dienstanbieter- Instanzen (7) betreiben, bereitgestellt wird. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein automatisierter Ablauf durchgeführt wird, nach dem ein Nutzer ein Angebot der Dienstanbieter-Instanz (7) akzeptiert. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
Dienstanbieter und Dienstnutzer einen Smart Contract aushandeln. Computerprogrammprodukt umfassend eine Codeeinrichtung, die geeignet zum Ausführen der Schritte eines Verfahrens nach einem der Ansprüche 1 bis 6 ist, wenn es auf einem Computer ausgeführt wird.
EP21743126.1A 2020-08-31 2021-07-08 Verfahren zur bereitstellung von diensten für iot-vorrichtungen Withdrawn EP4010871A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020005328.9A DE102020005328A1 (de) 2020-08-31 2020-08-31 Verfahren zur Bereitstellung von Diensten für loT-Vorrichtungen
PCT/EP2021/068940 WO2022042919A1 (de) 2020-08-31 2021-07-08 Verfahren zur bereitstellung von diensten für iot-vorrichtungen

Publications (1)

Publication Number Publication Date
EP4010871A1 true EP4010871A1 (de) 2022-06-15

Family

ID=76971876

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21743126.1A Withdrawn EP4010871A1 (de) 2020-08-31 2021-07-08 Verfahren zur bereitstellung von diensten für iot-vorrichtungen

Country Status (3)

Country Link
EP (1) EP4010871A1 (de)
DE (1) DE102020005328A1 (de)
WO (1) WO2022042919A1 (de)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017008956A1 (de) 2017-09-25 2018-03-01 Daimler Ag Verfahren zur Nutzung einer Rechnereinheit
DE102018110494B4 (de) * 2018-05-02 2025-07-10 Vc Viii Polytech Holding Aps Datenabruf- und Abrechnungsverfahren für Windparks sowie Gerät mit Maschine zu Maschine Sensordatentransaktion mit Datenmarktplatz
DE102019004611A1 (de) * 2019-07-01 2020-01-23 Daimler Ag Einrichtung zum Parken
DE102020003010A1 (de) * 2020-05-19 2020-07-16 Daimler Ag Ad hoc soziales Netzwerk

Also Published As

Publication number Publication date
WO2022042919A1 (de) 2022-03-03
DE102020005328A1 (de) 2022-03-03

Similar Documents

Publication Publication Date Title
DE102019129050A1 (de) Systeme und verfahren zur gemeinsamen nutzung von fahrzeugen über peer-to-peer-netzwerke
DE102016220592A1 (de) Kritische-Spitzen-Preisermittlungs-Bedarfsreaktions-Teilnehmerbewertung
DE102020120720A1 (de) Ladesystem
WO2019242975A1 (de) Verfahren und vorrichtung zum vereinbaren einer zusammenarbeit zwischen einem ersten system und einem zweiten system
Fridgen et al. Chancen und herausforderungen von dlt (blockchain) in mobilität und logistik
EP3701447A1 (de) Vorrichtung und verfahren zum gemeinsamen verwenden eines servicemobils
DE102018208701A1 (de) Vorrichtung und Verfahren zur Unterstützung eines Kunden bei der Anforderung eines Servicemobils
DE102020200230A1 (de) Mittel zur Verarbeitung von fahrzeugspezifischen Fahrzeugdaten
EP4010871A1 (de) Verfahren zur bereitstellung von diensten für iot-vorrichtungen
EP3857405B1 (de) Datenbanksystem für ein soziales netzwerk mit verwendung von blockchain-technologie
EP3701448A1 (de) Verfahren zur leistungserfassung in verbindung mit mobilen dienstleistungen
DE102015120093B4 (de) Kommunikationsplattform zum digitalen Datenaustausch, generische Anwendungsprogrammierschnittstelle für eine derartige Kommunikationsplattform, Verfahren zum Betreiben und Verwendung einer derartigen Kommunikationsplattform
EP3766033A1 (de) System und verfahren zum dezentralen durchführen von transaktionen
WO2023036840A1 (de) Dezentrales flotten-steuerungssystem und dezentrales flotten-steuerungsverfahren
DE102016224768A1 (de) System und Verfahren zum Steuern von Transportvorgängen
DE102020105275A1 (de) Assistenzsystem zur Reichweitenerhöhung eines elektrischen Fahrzeugs
DE112020006013T5 (de) Ein system zur investitionsförderung und verfahren dafür
DE102019127632A1 (de) Verfahren und vorrichtung zum einstellbaren routing mehrerer fahrzeuge
DE10197183T5 (de) Computerverfahren und Server zum Vermitteln von digitalem Inhalt zwischen einem Käufer und einem Verkäufer
DE102019008838A1 (de) Mobile Dienstinfrastruktur
DE69936512T2 (de) Verbesserungen in oder in bezug auf telekommunikations-übertragungs-systeme
DE102018214684A1 (de) Vorrichtung und Verfahren zur Unterstützung eines Konsumenten bei der Auswahl eines Servicemobils
CH709007A2 (de) Service Bus zur Integration verteilter Informations- und Kommunikationsdienste in die Anwendungslandschaft eines kleinen oder mittelständischen Unternehmens.
WO2020108800A1 (de) Chat-order
DE10211715A1 (de) Verfahren zur Erzeugung eines Paketauftrags in einem elektronischen Marktplatz

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220307

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: MERCEDES-BENZ GROUP AG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220803

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20221024