Titel

Verfahren zur Kommunikation zwischen einer Dritkomponente auf einem

Nutzergerät und einer Dienstkomponente in der Cloud sowie Netzwerkanordnung zur Umsetzung des Verfahrens

Stand der Technik

Die Erfindung betrifft ein Verfahren mit den Merkmalen des Anspruchs 1 sowie eine Netzwerkanordnung mit den Merkmalen des Anspruchs 11, ein Computerprogramm mit den Merkmalen des Anspruchs 12 und ein Maschinenlesbares Speichermedium.

Bei der Verteilung von Apps werden oftmals Cloud-Lösungen favorisiert, wobei die Apps über einen Anbieter in der Cloud, wie zum Beispiel Google Play Store, verteilt werden. Nach der Verteilung sind die Apps weitgehend unabhängig von dem Anbieter und nutzen die von der App vorgesehenen Kommunikationspartner.

Die Druckschrift DE 10 2018 219 067 Al, die wohl den nächstkommenden Stand der Technik bildet, beschreibt ein System und ein Verfahren zur lokalen Komposition einer Datenseite mit personenbezogenen Nutzerdaten für eine Menge von Diensten, auf die der Nutzer zugreift und die auf eine Menge von Servern bereitgestellt werden.

Offenbarung der Erfindung

Im Rahmen der Erfindung wird ein Verfahren mit den Merkmalen des Anspruchs 1, eine Netzwerkanordnung mit den Merkmalen des Anspruchs 11, ein Computerprogramm mit den Merkmalen des Anspruchs 12 sowie ein maschinenlesbares Speichermedium mit den Merkmalen des Anspruchs 13 vorgeschlagen. Bevorzugte oder vorteilhafte Ausführungsformen der Erfindung ergeben sich aus den Unteransprüchen, der nachfolgenden Beschreibung sowie den beigefügten Figuren.

Gegenstand der Erfindung ist ein Verfahren zur Kommunikation zwischen einer Drittkomponente auf einem Nutzergerät und einer Dienstkomponente in der Cloud.

Unter einem Nutzergerät wird insbesondere ein UE - User Equipment verstanden. Das Nutzergerät kann insbesondere als Mobiltelefon, Tablet, Computer, aber auch als Fahrzeug, Fertigungsmaschine, Arbeitsmaschine, Roboter etc. ausgebildet sein. Unter Nutzergerät werden somit insbesondere alle Endgeräte verstanden, welche das Ablaufen der Drittkomponente ermöglichen.

Unter der Drittkomponente wird eine Anwendungssoftware, ein Anwendungsprogramm, eine Software, ein Computerprogramm und/oder eine App verstanden, welche auf dem Nutzergerät ablaufen kann.

Unter Cloud wird insbesondere eine IT- Infrastruktur verstanden, die beispielsweise über das Internet verfügbar gemacht wird. Insbesondere ist die Cloud als ein Rechnernetz ausgebildet. Insbesondere kann die Cloud verschiedene Servicemodelle, im Speziellen Infrastructure as a Service (laaS), Platform as a Service (PaaS), Software as a Service (SaaS) und/oder Function as a Service (FaaS) zur Verfügung stellen.

In der Cloud wird mindestens ein Dienst durch eine Dienstkomponente angeboten. Der Dienst kann eine Verarbeitung darstellen. Das einfachste Beispiel der Verarbeitung ist eine Weiterleitung von Daten. Alternativ oder ergänzend sind unterschiedliche Typen von Cloudverarbeitungskomponenten als Dienstkomponenten vorgesehen, die den mindestens einen Dienst umsetzen. Dies umfasst beispielsweise Cloudverarbeitungsdienste zur Visualisierung, Cloudverarbeitungsdienste zur Weiterleitung oder Cloudverarbeitungsdienste zur Aggregation von Daten. Unter der Dienstkomponente wird eine Anwendungssoftware, ein Anwendungsprogramm, eine Software, ein Computerprogramm und/oder eine App verstanden, welche in der Cloud ablaufen kann.

Das Verfahren ermöglicht eine Kommunikation, insbesondere einen Datenaustausch, zwischen der Drittkomponente auf dem Nutzergerät und der Dienstkomponente in der Cloud. Dabei kann die Kommunikation nur unidirektional, insbesondere von der Drittkomponente zu der Dienstkomponente, oder bidirektional erfolgen, so dass Daten von der Drittkomponente zu der Dienstkomponente und Daten von der Dienstkomponente zu der Drittkomponente gesendet werden. Die Daten können beliebig ausgebildet sein und insbesondere auch Bilder, Videos, akustische Informationen, Nachrichten, insbesondere Kontrollnachrichten umfassen.

Die Dienstkomponente ist mit einer Daten-ID ausgestattet, welche zusammen mit der Dienstkomponente signiert wird. Insbesondere erfolgt die Signierung über ein Zertifikat. Das Zertifikat ist insbesondere als ein kryptographisches und/oder digitales Zertifikat ausgebildet, welches einen öffentlichen Teil und einen privaten Teil, insbesondere einen öffentlichen Schlüssel und einen privaten Schlüssel, aufweist.

Die Signierung mit dem Zertifikat erfolgt insbesondere über den privaten Teil des Zertifikats und kann über den öffentlichen Teil des Zertifikats geprüft werden. Beispielsweise ist der öffentliche Teil bei einer Zertifizierungsstelle hinterlegt.

Die Drittkomponente stellt Komponentendaten bereit. Beispielsweise kann die Drittkomponente über das Nutzergerät Eingangssignale und/oder Eingangsdaten aufnehmen, diese verarbeiten und als Komponentendaten bereitstellen. Es ist vorgesehen, dass die Komponentendaten mit der Daten-ID gekennzeichnet werden, um gekennzeichnete Komponentendaten zu erzeugen. Insbesondere werden die Komponentendaten mit der Daten-ID datentechnisch verbunden. Die gekennzeichneten Komponentendaten, umfassend die Komponentendaten und die Daten-ID, werden, insbesondere über einen Endpunkt, in die Cloud übertragen.

Es ist vorgesehen, dass die gekennzeichneten Komponentendaten der Dienstkomponente mit der Daten-ID in der Cloud zugeordnet werden. Insbesondere werden die gekennzeichneten Komponentendaten zu der Dienstkomponente mit der Daten-ID, die sich in den gekennzeichneten Komponentendaten befindet, in der Cloud weitergeleitet.

Es ist dabei eine Überlegung der Erfindung, dass durch die Kennzeichnung der Daten mit der Daten-ID eine Zuordnung in der Cloud und eine angepasste Verarbeitung mit der Dienstkomponente, die mit der Daten-ID signiert ist, möglich ist. Es ist somit eine eindeutige Zuordnung der Daten, insbesondere der Komponentendaten, zu der Dienstkomponente möglich.

Durch diese Vorgehensweise ist die Netzwerkanordnung in der Lage, beliebige Daten zu verarbeiten, ohne dass auf kompatible oder standardisierte Datentypen geachtet werden muss. Ein besonderer Vorteil der Erfindung ist, dass die Verarbeitung der Daten unabhängig von der Kompatibilität zu anderen Komponenten oder Standards erfolgen kann. Dabei kann die Relation zwischen der Nutzgeräte- und Cloudverarbeitung unterschiedlich gestaltet sein. Diese können eine einfache Weiterleitung sein. Es sind aber auch z. B. Kompression / Dekompression oder Analyse und Visualisierung denkbar. Die Dienstkomponente in der Cloud als Dienst kann z.B. auch eine Visualisierung spezieller App-Daten und/oder Komponentendaten als Teil eines Datendashboards sein, welches die Daten von mehreren Drittkomponenten von dem gleichen Nutzergerät oder von mehreren Nutzergeräten anzeigen kann.

Bei einer bevorzugten Weiterbildung der Erfindung ist die Drittkomponente mit einer Komponenten-ID signiert. Insbesondere erfolgt die Signierung über das oder ein weiteres Zertifikat. Das Zertifikat ist insbesondere als ein kryptographisches und/oder digitales Zertifikat ausgebildet, welches einen öffentlichen Teil und einen privaten Teil, insbesondere einen öffentlichen Schlüssel und einen privaten Schlüssel aufweist.

Die Signierung mit der Komponenten-ID erfolgt insbesondere über den privaten Teil des Zertifikats und kann über den öffentlichen Teil des Zertifikats geprüft werden. Beispielsweise ist der öffentliche Teil bei einer Zertifizierungsstelle hinterlegt. Die Komponenten-ID kann unterschiedliche Signierdaten aufweisen. Bei einer bevorzugten Realisierung der Erfindung weist das Nutzergerät eine Geräteverwaltungskomponente auf. Die Geräteverwaltungskomponente kann auch als Device Manager oder als Gerätemanager bezeichnet werden. Es ist vorgesehen, dass die Geräteverwaltungskomponente mit einem Geräteverwaltungsserver in der Cloud kommuniziert. Der Geräteverwaltungsserver kann auch als Device Server bezeichnet werden. Es ist bevorzugt vorgesehen, dass die gekennzeichneten Komponentendaten über die Geräteverwaltungskomponente und den Geräteverwaltungsserver zu der Dienstkomponente in der Cloud geleitet werden.

Bei einer bevorzugten Ausgestaltung der Erfindung erfolgt die Datenübertragung der gekennzeichneten Komponentendaten über die

Geräteverwaltungskomponente und den Geräteverwaltungsserver über eine einzige Verbindung. Insbesondere stellt der Geräteverwaltungsserver einen Endpunkt bereit, wobei die Geräteverwaltungskomponente insbesondere ausschließlich mit dem Endpunkt kommuniziert. Besonders bevorzugt ist diese Verbindung als eine gesicherte Verbindung ausgebildet. Beispielsweise ist diese Verbindung als ein VPN-Verbindung ausgebildet. Durch diese Ausgestaltung wird erreicht, dass nur eine einzelne, insbesondere gesicherte Verbindung in die Cloud zu dem Geräteverwaltungsserver gehalten werden muss, über die die Übertragung der Komponentendaten möglich ist. Damit wird eine Netzwerkanordnung beschrieben, in dem das Nutzergerät über wenige, vorzugsweise über eine einzige Verbindung zu der Cloud und/oder der Außenwelt betrieben werden kann. Dies ermöglicht die genaue Überprüfung der Kommunikation des Nutzergeräts und vereinfacht den Aufwand, um Firewall regeln einzu richten.

Diese Verbindung erlaubt es, den Fluss der Komponentendaten und weiteren Daten zu kontrollieren, besonders mit Bezug auf Durchsatz, Overhead und Latenz. Dies ist insbesondere im Unternehmensumfeld von Vorteil, wenn viele unkontrollierte Verbindungen zu Bedenken bezüglich der IT-Sicherheit führen könnten. Insbesondere gibt die Drittkomponente die Komponentendaten nun nicht direkt, sondern über die Geräteverwaltungskomponente in die Cloud. Die Geräteverwaltungskomponente ist hierbei in der Lage, die Komponentendaten zu kontrollieren, speziell im Hinblick auf Datenmenge und Latenz. Beispielsweise kann die Geräteverwaltungskomponente auf Kosten der Latenz mehrere Dateien bündeln, um den Overhead zu reduzieren. Speziell kann diese Kontrolle auch in Abhängigkeit der für das Nutzergerät erworbene Lizenz passieren, so dass bei Vorliegen einer Basislizenz zugunsten des reduzierten Overheads entschieden wird, während bei Vorliegen einer erweiterten Lizenz zugunsten einer geringeren Latenz entschieden wird.

Bei einer möglichen Weiterbildung der Erfindung sendet die Dienstkomponente Kontrollnachrichten über den Geräteverwaltungsserver und die Geräteverwaltungskomponente zu der Drittkomponente. Insbesondere wird die gleiche, vorzugsweise gesicherte Verbindung wie bei der Übertragung der gekennzeichneten Komponentendaten verwendet.

Es ist ferner besonders bevorzugt, dass die Drittkomponente über den Geräteverwaltungsserver und die Geräteverwaltungskomponente zwecks Installation und/oder Update auf das Nutzergerät übertragen wird. Besonders bevorzugt wird die Drittkomponente zusammen mit der Daten-ID übertragen.

In einer besonders bevorzugten Konstellation werden somit die gekennzeichneten Komponentendaten, Kontrollnachrichten und die Drittkomponente zur Installation und/oder zum Update über die gleiche, insbesondere gesicherte Verbindung übertragen. Mit dieser Architektur ist sichergestellt, dass die Übertragung der Daten hinsichtlich der IT-Sicherheit in einfacher Weise abzusichern ist. Ferner wird durch die Nutzung der Daten-ID die Zuordnung der Komponentendaten zu der jeweiligen Dienstkomponente sichergestellt, so dass die IT-Sicherheit auch dahingehend erhöht wird, dass die Komponentendaten und weiteren Daten zu dem richtigen Empfänger geleitet werden.

Bei einer möglichen Ausgestaltung der Erfindung ist die Dienstkomponente und die Drittkomponente mit dem gleichen Zertifikat und/oder mit einem Zertifikat von dem gleichen Entwickler signiert. Vorzugsweise umfasst die Daten-ID als Information die Komponenten-ID, so dass eine strenge und damit sichere Zuordnung zwischen der Drittkomponente, der Dienstkomponente und den Komponentendaten gegeben ist. Bei einer alternativen Ausgestaltung der Erfindung wird die Dienstkomponente über ein erstes Zertifikat signiert und die Drittkomponente über ein zweites Zertifikat signiert. Es ist besonders bevorzugt, dass die signierte Dienstkomponente gemeinsam mit der signierten Drittkomponente durch ein Bündelzertifikat signiert ist. In dieser Ausgestaltung kann die Zuordnung von

Daten-ID zu Dienstkomponente ausschließlich durch die Signatur des Bündelzertifikats erfolgen. Durch diese Architektur der Signaturen wird es ermöglicht, dass die Drittkomponente und die Dienstkomponente durch unterschiedliche Zertifikate signiert werden und die Zusammenführung durch das Bündelzertifikat erfolgt. Es ist ferner möglich, dass bereits existierende und ggfs. durch ein Fremdzertifikat signierte Dienstkomponenten mit dem Bündelzertifikat in das Verfahren einbezogen werden können. Das Fremdzertifikat stammt von einem anderen Entwickler. Weitere Merkmale. Vorteile und Wirkungen der Erfindung ergeben sich aus der nachfolgenden Beschreibung bevorzugter Ausführungsbeispiels sowie der beigefügten Figuren. Diese zeigen:

Figur 1 ein erstes Ausführungsbeispiel der Erfindung einer Netzwerkanordnung zur Ausführung eines Verfahrens zur Kommunikation in einer schematischen

Blockdarstellung;

Figur 2 ein zweites Ausführungsbeispiel der Erfindung einer Netzwerkanordnung zur Ausführung eines Verfahrens zur Kommunikation in einer schematischen Blockdarstellung;

Figur 3 ein drittes Ausführungsbeispiel der Erfindung einer Netzwerkanordnung zur Ausführung eines Verfahrens zur Kommunikation in einer schematischen Blockdarstellung;

Figur 4 ein viertes Ausführungsbeispiel der Erfindung einer Netzwerkanordnung zur Ausführung eines Verfahrens zur Kommunikation in einer schematischen Blockdarstellung; Figur 5 ein fünftes Ausführungsbeispiel der Erfindung einer Netzwerkanordnung zur Ausführung eines Verfahrens zur Kommunikation in einer schematischen Blockdarstellung;

Figur 6 ein sechstes Ausführungsbeispiel der Erfindung einer Netzwerkanordnung zur Ausführung eines Verfahrens zur Kommunikation in einer schematischen Blockdarstellung;

Figur 7 ein siebtes Ausführungsbeispiel der Erfindung einer Netzwerkanordnung zur Ausführung eines Verfahrens zur Kommunikation in einer schematischen Blockdarstellung.

Gleiche oder einander entsprechende Komponenten sind in den Figuren mit den gleichen Bezugszeichen gezeigt und beschrieben.

Die Figur 1 zeigt in einer schematischen Blockdarstellung eine Netzwerkanordnung 1 als ein Ausführungsbeispiel der Erfindung. Die Netzwerkanordnung 1 weist einen Nutzergerät 2 sowie Module in einer Cloud 3 auf.

Das Nutzergerät 2 ist als ein Endgerät, wie zum Beispiel ein Handy oder aber als ein beliebiges anderes Endgerät ausgebildet. Es kann Eingangssignale 19, wie zum Beispiel Bilder, Videosequenzen, Tonsequenzen, Sensormesswerte oder auch Eingangsdaten über entsprechende Schnittstellen aufnehmen.

Das Nutzergerät 2 weist eine Drittkomponente 4 auf, wobei die Drittkomponente 4 als ein Computerprogramm, insbesondere als eine App ausgebildet ist. Die Drittkomponente 4 kann von dem Hersteller des Betriebssystems des Nutzergeräts 2 stammen oder auch von einem anderen Anbieter. Die Drittkomponente 4 nimmt die Eingangssignale 19 vorzugsweise digitalisiert auf und wandelt diese in Komponentendaten 20 als Ausgangsdaten von der Drittkomponente 4.

Das Nutzergerät 2 weist eine Geräteverwaltungskomponente 5 auf, wobei die Geräteverwaltungskomponente 5 auch als Device Manager oder als Gerätemanager bezeichnet werden kann. Die Komponentendaten 20 werden über die Geräteverwaltungskomponente 5 über eine Verbindung 6 in die Cloud 3 übertragen. Die Verbindung 6 kann als eine gesicherte Verbindung, insbesondere als ein VPN-Kanal ausgebildet sein.

In der Cloud 3 sind als Module ein Geräteverwaltungsserver 7 und ein Dienstmodul 8 sowie ein Komponentenverteilungsmodul 9 vorgesehen. Die Module können als Softwaremodule und/oder als Hardwaremodule zentralisiert oder dezentralisiert in der Cloud 3 angeordnet sein. Das Dienstmodul 8 weist eine Dienstkomponente 10 auf, wobei die Dienstkomponente 10 als ein Computerprogramm, insbesondere als eine App ausgebildet ist.

Das Komponentenverteilungsmodul 9 dient zur Verteilung der Drittkomponente 4 an das Nutzergerät 2 und von der Dienstkomponente 10 an das Dienstmodul 8. Die Drittkomponente 4 wird zunächst an den Geräteverwaltungsserver 7 geliefert, über den Geräteverwaltungsserver 7 wird die Drittkomponente 4 oder ein Update davon über die Verbindung 6 an das Nutzergerät 2 geliefert.

Die Drittkomponente 4 oder mehrere Varianten davon, welche beispielsweise unterschiedlichen technischen Ausstattungen des Nutzergeräts 2 zugeordnet sind, sind über ein Zertifikat 11 mit einer Komponenten-ID 12 signiert S. Die Dienstkomponente 10 ist bei dem Ausführungsbeispiel in der Figur 1 über das gleiche Zertifikat 11 mit einer Daten-ID 13 signiert S.

Das Nutzergerät 2 kennzeichnet die Komponentendaten 20 der Drittkomponente 4 mit der Daten-ID, so dass gekennzeichnete Komponentendaten 21 erzeugt werden. Die Kennzeichnung mit der Daten-ID kann durch die Drittkomponente 4 oder wie in der Figur 1 gezeigt durch die Geräteverwaltungskomponente 5 erfolgen. Über die Verbindung 6 werden die gekennzeichneten Komponentendaten 21 von der Geräteverwaltungskomponente 5 in die Cloud 3 zu dem Geräteverwaltungsserver 7 und nachfolgend zu dem Dienstmodul 8 mit der Dienstkomponente 10 geleitet, welche die Daten-ID der gekennzeichneten Komponentendaten aufweist. Mit dieser Architektur wird erreicht, dass die Verteilung der Drittkomponente 4 und die Übergabe der gekennzeichneten Komponentendaten über die gleiche Verbindung 6 erfolgt. Durch die Kennzeichnung der Komponentendaten mit der Daten-ID wird erreicht, dass die gekennzeichneten Komponentendaten 21 oder die Komponentendaten 20 in der Cloud 3 an das Dienstmodul 8 mit der entsprechenden Dienstkomponente 10 mit der gleichen Daten-ID weitergeleitet wird, so dass die Zuordnung der Komponentendaten 20 zu der Dienstkomponente 10 deterministisch sichergestellt ist.

Aus dem Stand der Technik sind Drittkomponenten für Geräte (Apps) und grundsätzlich Softwaremodule und Verteilungsmechanismen bekannt (z.B. Docker images, OSGI bundles). Weiterhin sind aus Android "App Bundles" bekannt, welche signierte Bündel von Softwarekomponenten sind, aus welchen nur eine Teilmenge auf ein Gerät installiert werden muss, wobei sich diese Teilmenge aus den Merkmalen des Gerätes ergibt, auf welches die Software installiert wird. Schließlich ist aus Android auch das Konzept von Multi-APK bekannt, bei dem mehrere Apps grundsätzlich verfügbar sind, aber nur jene Version der App installiert wird, welche von dem Entwickler für das entsprechende Gerät optimiert wurde.

Die Drittkomponenten werden von einem Softwareentwickler geschrieben und dann mittels eines Zertifikats signiert. Hierbei ist selbstverständlich der geheime Schlüssel nur dem Softwareentwickler selbst bekannt. Der öffentliche Teil des Zertifikats ist bei einem Dienst zur Verteilung / zum Vertrieb von Apps hinterlegt, wodurch die Herkunft der Software bestätigt werden kann. Über einen Endpunkt in der Cloud kommuniziert ein Gerät nun mit diesem Verteildienst, über welchen die Apps auf dem Gerät installiert werden (z.B. Google Play Store). Daten, welche die App sendet, werden in der Regel über einen separaten Server versendet (z.B. WhatsApp).

Eine Kommunikation mit beliebigen Endpunkten stellt manche Systeme jedoch vor größere Schwierigkeiten, da eine Kommunikation mit beliebigen Endpunkten aus Sicherheitsgründen nicht erwünscht ist.

Figur 1 zeigt ein nur teilweise aus dem Stand der Technik bekanntes System. Die Geräteverwaltungskomponente 5 auf dem Nutzergerät 2 verbindet dieses mit dem Geräteverwaltungsserver 7 in der Cloud 3. Der Geräteverwaltungsserver 7 ist mit einem System zur Verteilung und Verwaltung von Drittkomponenten 4, dem Komponentenverteilungsmodul 8 verbunden. Ein Entwickler kann nun die Drittkomponente 4 für das Nutzergerät 2 entwickeln und diese Geräteverwaltungskomponente (Komponentenverteilungsmodul 8) in der Cloud 3 übergeben. Zur Identifizierung des Entwicklers wird auf das insbesondere kryptografische Zertifikat 11 zurückgegriffen, von welchem der öffentliche Teil der Verwaltungskomponente (Komponentenverteilungsmodul 8) im Zuge eines erstmaligen Anmeldevorgangs bekannt gemacht worden ist. Der Besitzer des Nutzergeräts 2 kann nun über die Cloud 3 die Drittkomponente 4 beziehen und auf dem Nutzergerät 2 installieren lassen. Die Installation wird über den Geräteverwaltungsserver 7 orchestriert. Je nach Gerätetyp oder zur Verfügung stehender Funktionalität auf dem Nutzergerät 2 kann hierbei eine von einer Vielzahl von möglichen Varianten der Drittkomponente 4 zum Einsatz kommen.

Bekannte Umsetzungen dieses Prinzips sind die Ökosysteme von Apple und Google, mit dem AppStore für iOS, bzw. dem PlayStore für Android. In diesen Systemen ist jede der Drittkomponenten 4 in der Regel für die Kommunikation selbst verantwortlich und kommuniziert mit eigenen Servern, wie aus der Vielzahl an verfügbaren Messengern ersichtlich ist.

Die Ausführungsbeispiele in den Figuren befasst sich mit dem Nutzergerät 2, wobei Drittkomponenten 4 nachträglich installiert werden können und welches möglicherweise in einer gesicherten Umgebung zum Einsatz kommt. Das Nutzergerät 2 erfasst und verarbeitet Eingangsdaten und/oder -Signale 19 und schickt diese als Komponentendaten 20 bzw. 21 an die Cloud 3. Dabei soll die bevorzugt einzige Verbindung 6 in die Cloud 3 verwendet werden. Dies ermöglicht die genauere Überprüfung der Kommunikation des Nutzergeräts 2 und vereinfacht den Aufwand, um Firewallregeln einzurichten. Ein Gedanke ist eine Kennzeichnung von Dienstkomponenten 10 in der Cloud 3 durch den Entwickler, die Kennzeichnung der durch die Drittkomponente 4 auf dem Nutzergerät 2 erzeugten Komponentendaten 20, sowie eine Bündelung beider Komponenten mit Hilfe kryptographischer Signaturen S. Durch die Kennzeichnung der Komponentendaten mit der Daten-ID zur Umsetzung in die gekennzeichneten Komponentendaten 21 ist eine Zuordnung der Komponentendaten 20 in der Cloud 3 und eine angepasste Verarbeitung durch die Dienstkomponente 4 mit der gleichen Daten-ID möglich.

Durch diese Vorgehensweise ist die Netzwerkanordnung 1 in der Lage, beliebige Daten zu verarbeiten, ohne dass auf kompatible oder standardisierte Datentypen geachtet werden muss. Dabei muss nur mindestens oder genau eine einzelne (gesicherte) Verbindung 6 in die Cloud 3 (zum Geräteverwaltungsserver 7) gehalten werden, über die nun auch die Übertragung von Komponentendaten möglich ist. Diese Verbindung erlaubt es, den Fluss der Daten zu kontrollieren, besonders mit Bezug auf Durchsatz, Overhead und Latenz. Dies ist besonders im Unternehmensumfeld von Vorteil, wenn viele, unkontrollierte Verbindungen zu Bedenken bezüglich der IT Sicherheit führen könnten.

Ein besonderer Vorteil ist, dass die Verarbeitung der Komponentendaten 20 unabhängig von der Kompatibilität zu anderen Komponenten oder Standards erfolgen kann, da die Komponentendaten 20 der entsprechenden, kompatiblen Dienstkomponente 10 zugeordnet werden. Dabei kann die Relation zwischen der Nutzgeräte- und Cloudverarbeitung unterschiedlich gestaltet sein. Diese können eine einfache Weiterleitung sein. Es sind aber auch z. B. Kompression / Dekompression oder Analyse und Visualisierung denkbar. Die Dienstkomponente 10 in der Cloud 3 kann z.B. auch eine Visualisierung spezieller Komponentendaten als Teil eines Datendashboards sein, welches die Daten von mehreren Drittkomponenten 4 anzeigen kann.

Es wird die Netzwerkanordnung 1 beschrieben, in der das Nutzergerät 2 über möglichst wenige, vorzugsweise über eine einzige, Verbindung 6 in die Außenwelt betrieben werden soll. Dies ermöglicht die genauere Überprüfung der Kommunikation des Nutzgerätes 2 und vereinfacht den Aufwand, um Firewallregeln einzurichten. Auf dem Nutzgerät 2 befinden sich ein oder mehrere Apps als Drittkomponente 4, die ein Eingangssignal und/oder -Signal 19, beispielsweise ein Videosignal oder eine Benutzereingabe verarbeiten. Die Apps erzeugen Ausgangssignale in Form digitaler Daten als Komponentendaten 20.

Die Apps geben die Daten 20 nun nicht direkt, sondern über einen Gerätemanager als Geräteverwaltungskomponente 5 in die Cloud 3. Der Gerätemanager ist hierbei in der Lage, die Daten zu kontrollieren, speziell in Hinblick auf Datenmenge und Latenz. Beispielsweise kann der Gerätemanager auf Kosten der Latenz mehrere Daten bündeln, um den Overhead zu reduzieren. Speziell kann diese Kontrolle auch in Abhängigkeit der für das Nutzgerät erworbenen Lizenz passieren, so dass bei Vorliegen einer Basislizenz eher zu Gunsten des reduzierten Overheads entschieden wird, während bei Vorliegen einer erweiterten Lizenz zu Gunsten einer geringeren Latenz entschieden wird. Um die Komponentendaten 20 in der Cloud 3 zuzuordnen und weiter zu verarbeiten, markieren die Apps, also die Drittkomponente 4 oder die Geräteverwaltungskomponente 5 die Komponentendaten 20 mit der Daten-ID, welche in der Cloud 3 durch die empfangende Stelle ausgewertet wird.

Der oder ein weiterer Entwickler erstellt nun eine Verarbeitungskomponente als Dienstkomponente 10 für die Cloud 3, signiert diese mit seinem Zertifikat 11 und stellt sie der Cloud 3 zur Verfügung. Diese Verarbeitungskomponente ist für die Verarbeitung einer Daten-ID bestimmt und gekennzeichnet. Über diese Daten-ID kann die Cloud 3 nun die spezifische Verarbeitung für die Komponentendaten 20 vornehmen, indem mittels der Verarbeitungskomponente die Komponentendaten 20 verarbeitet werden. Somit wird mittels der Data-ID eine Weiterleitung durch den Geräteverwaltungsserver 7 an die richtige Verarbeitungseinheit als Dienstmodul 8 mit der Dienstkomponente 10 in der Cloud 3 ermöglicht.

In der Cloud 3 angelangt werden die Komponentendaten an eine verarbeitende Instanz übergeben, welches anhand von der Daten-ID entscheidet, welche Dienstkomponente 10 für die Komponentendaten 20 auszuführen ist. Diese Dienstkomponenten 10 werden so wie die Apps von Entwicklern programmiert und entsprechend mit einer kryptografischen Signatur mit der Daten-ID versehen. Es sei anzumerken, dass eine App auf dem Nutzergerät 2 auch unterschiedliche Komponentendaten 20 mit jeweils eindeutiger Daten-ID erzeugen kann.

Das einfachste Beispiel der Verarbeitung durch die Dienstkomponente 10 ist eine simple Weiterleitung der Komponentendaten 20, wie dies in der Figur 2 gezeigt ist. Hierbei werden die Komponentendaten von dem Dienstmodul 8 mit der Dienstkomponente 10 mit der entsprechenden Daten-ID beispielsweise an einen vorgebbaren Server 14 weitergeleitet.

Es ist möglich, dass unterschiedliche Typen von Dienstkomponenten 10 und/oder Dienstmodulen 8 unterstützt werden, beispielsweise Cloudverarbeitungsmodule zur Visualisierung, Cloudverarbeitungsmodulen zur Weiterleitung oder Cloudverarbeitungsmodulen zur Aggregierung. Auch ist es möglich, dass die Cloudverarbeitungsmodule wiederrum den Geräteverwaltungsserver 7 verwenden, um Kontrollnachrichten 22 an die Drittkomponente zuzustellen, wie dies beispielhaft in der Figur 3 gezeigt ist. Insbesondere wird für die Kontrollnachrichten 22 die Verbindung 6 genutzt, so dass weiterhin nur eine einzige Verbindung 6 zum Einsatz kommt. Die Kontrollnachrichten werden von der Dienstkomponente 10 versandt und sind mit der Komponenten-ID 12 gekennzeichnet. Über den Geräteverwaltungsserver 7 werden die Kontrollnachrichten an das Nutzergerät 2 gesandt. Dabei kann die Komponenten-ID 12 zum einen die Zustellung zu dem gewünschten Nutzergerät, insbesondere zu der gewünschten Drittkomponente mit der gleichen Komponenten-ID sicherstellen. Zum andern kann die Komponenten-ID 12 die Kontrollnachricht kennzeichnen und damit absichern.

Die Daten-ID ist ein zentrales Element, da es die Verarbeitung auf dem Nutzergerät 2 an die Verarbeitung in der Cloud 3 koppelt. Es ist ebenfalls möglich, dass die Komponentendaten 20 vor der Verarbeitung zunächst in einer Datenbank gespeichert werden. Dies ist besonders dann nützlich, wenn es sich bei der Cloudverarbeitung um eine Visualisierung handelt.

Die Daten-ID ist vorzugsweise eine hierarchische Struktur aus Basisdatentyp, Komponenten-ID, Spezialisierung und/oder Versionsnummer. Der Basisdatentyp erlaubt es, eine geeignete Aufbewahrung in einer Datenbank auszuwählen. Die Komponenten-ID erlaubt die Zuordnung zu einer Drittkomponente 4, die Spezialisierung erlaubt der Drittkomponente 4 eine Unterscheidung spezifischer Daten und die Versionsnummer schließlich erlaubt eine spätere Verarbeitung, welche besonders dann nützlich ist, wenn die Daten in einer Datenbank abgespeichert werden.

Die Geräteverwaltungskomponente 5 prüft vorzugsweise die Komponenten-ID in der Daten-ID (oder fügt diese hinzu), um zu verhindern, dass eine Drittkomponente 4 eine Daten-ID derart setzt, dass eine ungewollte Verarbeitung durch eine andere Cloudverarbeitungskomponente, insbesondere Dienstkomponente 10 vorgenommen wird, was unter Umständen zu Sicherheitsproblemen führen kann. Gleichermaßen prüft die Cloud 3 vorzugsweise, dass die Dienstkomponente 10 durch denselben Entwickler signiert wurde, wie die durch die Daten-ID identifizierte Komponenten-ID, was verhindert, dass andere Drittkomponenten 4 Komponentendaten durch eine nicht zuständige Dienstkomponente 10 verarbeiten lassen. (Diese Prüfung kann einmalig erfolgen).

In der Figur 4 ist der gleiche Aufbau wie in der Figur 1 dargestellt. Die Ergänzungen aus den Figuren 2 und 3 können in gleicher Weise auch bei dem Aufbau in der Figur 4 eingesetzt werden. In Abgrenzung zu den vorhergehenden Figuren werden die Drittkomponente 4 und die Dienstkomponente 10 mit unterschiedlichen Zertifikaten 11 signiert S. Somit kann die Drittkomponente 4 von einem ersten Entwickler und die Dienstkomponente 10 von einem zweiten Entwickler mit jeweils unterschiedlichen Zertifikaten 11 signiert S werden. Die signierten Komponenten 4, 10 werden gemeinsam über ein Bündelzertifikat 15 gemeinsam signiert mit der Signatur S.

Die in den vorhergehenden Figuren beschriebene Netzwerkanordnung 2 nutzt dasselbe Zertifikat 11 für alle zusammengehörigen Komponenten 4 und 10. Über dieses gemeinsame Zertifikat 11 werden die zusammengehörigen Komponenten identifiziert.

Signatur von Komponentenbündeln:

Eine Variante ist in Figur 4 gezeigt, wobei diese implizite Zusammengehörigkeit durch eine weitere Signatur als Bündelzertifikat 15 gelöst ist, so dass prinzipiell drei Zertifikate 11, 11, 15 zum Einsatz kommen, je eins für die einzelnen Komponenten 4, 10 und eins über die Sammlung der Komponenten 4, 10. Dies erlaubt es, existierende Zertifikate und Methoden zur Signierung der einzelnen Komponenten zu verwenden, obwohl typischerweise mindestens zwei Signaturen identisch sind. Dies löst insbesondere das Problem der Rückwärtskompatibilität. Die an das Nutzergerät 2 verteilte Drittkomponente 4 verhält sich identisch zu dem Fall, in dem es keine Cloudverarbeitung gibt. Diese Eigenschaft gilt entsprechend für die Cloudverarbeitung. Somit ist es auch möglich, die Cloudverarbeitung an Drittkomponenten 4 auszulagern, welche bestimmte Signaturen erfordern, deren Prüfung der Komponentenverwaltung nicht möglich ist. Beispielsweise falls die Verarbeitung auf einer "fremden" Cloud stattfindet. Zusätzlich ist es möglich, bestehende Komponenten zur Datenverarbeitung in der Cloud unverändert dem Bündel hinzuzufügen, beispielsweise um eine Rückwärtskompatibilität sicherzustellen, oder um die Komponenten anderer Entwickler lizenziert nutzen zu können. Dadurch kann beispielsweise eine Lösung für ein komplexes Szenario, welches mehrere Drittkomponenten 4 und Cloudkomponenten 10 erfordert, zertifiziert werden, beispielsweise, um bestimmte Verarbeitungsgarantien zuzusichern.

Schließlich ist es auch möglich, als Teil des Bündels mit dem Bündelzertifikat 15 die Verarbeitung durch andere Komponenten zuzulassen, ohne diese direkt mitzuliefern. Dies ist besonders dann von Vorteil, wenn z.B. bestehende Visualisierungen freigeschaltet werden sollen, wie dies in der Figur 5 gezeigt ist. Hier wird die Daten-ID 13 der Dienstkomponente 10 durch einen anderen Entwickler als existierende Daten-ID 13‘ bereitgestellt und über das Bündelzertifikat 15 eingebunden. Die Dienstkomponente 10 selbst wird nicht signiert, stattdessen wird nur ein Verweis auf die Dienstkomponente 10 gegeben.

Durch die nun festere Kopplung der Komponenten über das Bündelzertifikat 15 ist es zudem möglich, die Komponenten-ID der Drittkomponente 4 zu entnehmen und automatisiert in die Daten-ID einfließen zu lassen, ohne dass der Entwickler dies explizit tun muss.

Ausgegliederte Verarbeitung:

Die in Figur 5 gezeigte Variante ist um mehrere Komponentenklassen erweiterbar, wie dies in der Figur 6 dargestellt ist. Beispielsweise kann zur Reduktion des Datenverkehrs ein lokaler Verarbeitungsknoten 16 mit einer Verarbeitungskomponente 17 installiert werden, oder eine Zwischenverarbeitung, etwa eine Kompression der Daten in der Verarbeitungskomponente 17, stattfinden. Der Verarbeitungsknoten 16 kann unterschiedlich ausgestaltet sein. Es kann sich um eine physikalische Recheneinheit, eine virtuelle Maschine, oder auch nur um Zeit auf einer Cloud 3 oder Edge Cloud handeln. Dieses Gerät kann zusammen mit den Geräten auf einem Gelände verbaut sein ("on-premise") oder von einem Dritten beispielsweise in einem nahen Rechenzentrum zur Verfügung gestellt werden ("off-premise", nicht gezeigt). Auch kann es sich um dedizierte Ressourcen, oder um Teile von Drittsystemen, beispielsweise Systemen zur Verwaltung der Geräte, handeln.

Eine Verarbeitung-ID 18 der Verarbeitungskomponente 17 verhält sich analog zur Daten-ID in der Cloud 3. Insbesondere wird die Verarbeitung-ID 18 mittels des Bündelzertifikats 15 signiert. Die Verarbeitungskomponente 17 prüft analog zu den beschriebenen Mechanismen die Daten-ID und fordert fehlende Verarbeitungskomponenten ggfs, aus der Cloud 3 an.

Wie in der Figur 7 gezeigt ist, kann die Verarbeitungskomponente 17, welche die Komponentendaten der Drittkomponente 4 entgegennimmt und lokal weiterverarbeitet, die Daten-ID ändern. Dies ermöglicht die Kennzeichnung bereits (vor-)verarbeiteter Daten, so dass ein hybrider Einsatz der Komponenten möglich ist. Der Entwickler signiert hierzu zwei Cloudverarbeitungskomponenten, die lokale Verarbeitungskomponente 17 und die Drittkomponente 4. Die Daten- IDs der Cloudverarbeitungskomponenten als Dienstkomponente 10, 10‘ sind derart gestaltet, dass eine die Komponentendaten der Drittkomponente 4 direkt empfängt (Daten-ID 13A) und eine die Komponentendaten der lokalen Verarbeitungskomponente 16 empfängt (Daten-ID 13B). Die Verarbeitung-ID der lokalen Verarbeitungskomponente entspricht hierbei der Daten-ID A.

Alternativ ist es auch möglich, das Dienstmodul in der Figur 6 direkt in der Cloud 3 laufen zu lassen, sofern die benutzte Technik dies erlaubt.

Bestehende Systeme

Ein besonderer Vorteil der Nutzung von Komponentenbündeln mit einem Bündelzertifikat 15 ist, dass Systeme verwendet werden können, die bestimmte Zertifikate benötigen, z.B. weil die Komponente von einem Fremdhersteller kommt. Die Zuordnung in der Cloud 3 ist nach wie vor möglich. Jedoch sind die Prüfungen der IDs der Komponenten mit hoher Wahrscheinlichkeit nicht in dem existierenden System implementiert. Daher muss der Geräteverwaltungsserver 7 in der Cloud die Verknüpfung, welche Daten in welcher Komponente zu verarbeiten sind, ggfs, explizit vornehmen.

Figur 1 zeigt den Grundmechanismus. Ein Entwickler fertigt mehrere, unterschiedliche Komponenten für unterschiedliche Zwecke an (Verarbeitung auf dem Gerät und Verarbeitung in der Cloud) und signiert diese digital. Über eine Daten-ID, welche die an die Cloud verschickten Daten annotieren, wird eine Verarbeitung durch die entsprechende, für die Daten-ID zuständige Komponente in der Cloud ausgelöst. Figur 2 zeigt exemplarisch die Umsetzung des Anwendungsfalls. Figur 3 zeigt die Ausprägung mit bidirektionaler Kommunikation, welche den Cloudverarbeitungskomponenten ermöglicht, Kontrollnachrichten an das Gerät zuzustellen. Figur 4 zeigt die Ausprägung mit einem Komponentenbündel. Es können bestehende Zertifikate für die Signatur der Einzelkomponenten zum Einsatz kommen. Die Sammlung der Komponenten ist dann mit einem weiteren Zertifikat unterschrieben. Figur 5 zeigt die Nutzung existierender Cloudverarbeitungsmodule, etwa um Standarddatentypen zu visualisieren. Figur 6 zeigt die Nutzung von Komponentenbündeln für die Verarbeitung auf mehreren Geräten. Figur 7 zeigt die Nutzung von Komponentenbündeln in hybrider Nutzung, bei der sowohl eine separate Verarbeitung auf einem separaten Gerät, als auch die gesammelte Verarbeitung in der Cloud möglich ist.