I. Das Klagepatent A A1. Die Klägerin ist die allein

Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
I.
A1.
Seite A-1
Das Klagepatent A
Die Klägerin ist die allein verfügungsberechtigte Inhaberin des Europäischen Patents
EP 989 712 B1 (nachfolgend als „Klagepatent A“ bezeichnet), das laut Deckblatt ein
„Verfahren und Anordnung zur Herstellung sicherer Verbindungen über Einwegskanäle“ betrifft. Die Anmeldung des Klagepatents A datiert vom 21.09.1999. Die Europäische Anmeldung wurde am 29.03.2000 veröffentlicht. Der Veröffentlichungstag
des Klagepatents A und der Tag der Bekanntmachung des Hinweises auf die Patenterteilung war der 06.04.2005. Wir überreichen eine Kopie des Klagepatents A – für das
Gericht dreifach – als
Anlage EIP A1.
A2.
Der deutsche Teil des erteilten Europäischen Patents ist in Deutschland validiert und
trägt die Nummer DE 699 24 573 T2. Wir überreichen hierzu – für das Gericht wiederum in dreifacher Ausführung – als
Anlage EIP A1a
die entsprechende Veröffentlichung und als
Anlage EIP A2
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-2
einen aktuellen Online-Registerauszug des Deutschen Patent- und Markenamts. Das
Patent steht in Deutschland in Kraft.
BEWEIS:
A3.
Auskunft des Deutschen Patent- und Markenamtes
Zu berücksichtigen ist, dass die Absatznummerierung der Übersetzung des Europäischen Klagepatents A (Anlage EIP A1a) nicht mit der englischen Fassung des Europäischen Patents (Anlage EIP A1) übereinstimmt. So fehlt dem deutschen Teil des
Klagepatents A der Absatz [0001], so dass der Übersetzung die Bezugnahme auf die
US-Patente fehlt und sie mit dem Absatz [0002] der englischen Fassung beginnt.
Den folgenden Ausführungen liegt insofern die englische Fassung des Europäischen
Patents (Anlage EIP A1) zugrunde.
A4.
Das Klagepatent A ist kürzlich von der früheren Inhaberin, der Unwired Planet LLC,
auf die Klägerin übertragen worden. Eine Kopie der Übertragungsvereinbarung fügen wir als Teil des
Anlagenkonvoluts EIP A3
bei.
A5.
Aus dem Übertragungsvertrag (Anlagenkonvolut EIP A3) auf Seite 1 unter 1. (D)
geht hervor, dass zusammen mit dem Patent auch alle Ansprüche zur Durchsetzung
des Patents, insbesondere vergangene, gegenwärtige und zukünftige Schadensersatzansprüche an die Klägerin abgetreten worden sind.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
A6.
Seite A-3
Die Abtretung des Klagepatents A ergibt sich aus folgender Passage des Übertragungsvertrages (vgl. Seite 1, 1.):
„Assignment. Assignor hereby assigns, conveys and
transfers to Assignee its right, title, and interest in and
to all of the patents and patent applications set forth on
Schedule Attached hereto (collectively, the Assigned
Patents”), in each case, subject to all existing encumbrances. (…)”
Auf Deutsch:
“Übertragung. Der Zedent tritt ab, übereignet und überträgt hiermit an den Zessionar den Anspruch, das Eigentum und sein Interesse bezüglich sämtlicher Patente und
Patentanmeldungen, welche im beigefügten Anhang A
genannt werden (zusammen als „die übertragenen Patente“ bezeichnet), in jedem Einzelfall, vorbehaltlich
sämtlicher existierenden Belastungen. (…)“
A7.
Das Klagepatent A ist Teil der „übertragenen Patente“ im Sinne dieser Vereinbarung.
Dies ergibt sich aus der Seite 2 des Anhangs zum Übertragungsvertrag (Anlagenkonvolut EIP A3), wo das Klagepatent A (mit einem Kreuz gekennzeichnet) aufgelistet ist.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
A8.
Seite A-4
Bezüglich der Übertragung der Schadensersatzansprüche führt der Vertrag aus (Seite
1, Nr. 1 (D)):
„The foregoing assignment includes, without limitation,
the rights of Assignor, if any, to (…)
and (D) all causes of action, remedies and other enforcement rights relating to the Assigned Patents including the right to initiate and maintain legal proceedings
in respect of any past, present or future infringements
thereof and to seek and recover damages or other compensation in respect of such infringements (…).”
Auf Deutsch:
“Die voranstehende Übertragung umfasst ebenfalls,
ohne Einschränkung, das Recht des Zedenten (…) und
(D) alle Klagegründe, Rechtsmittel und andere Durchsetzungsrechte, die mit den übertragenen Patenten im
Zusammenhang stehen, insbesondere ein rechtliches
Vorgehen bezüglich vergangener, gegenwärtiger oder
zukünftiger Verletzungshandlungen zu initiieren und
aufrechtzuerhalten und damit auch die Geltendmachung
von Schadensersatzansprüchen und anderer Kompensationen hinsichtlich dieser Verletzungshandlungen (…).“
A9.
Ursprünglich war die Openwave Systems Inc. Inhaberin des Klagepatents A. Im Mai
2012 benannte sich die Openwave Systems Inc. in Unwired Planet Inc. um. Damit
war die Unwired Planet Inc. berechtigt, mit Vertrag vom 14. September 2012 das
Klagepatent A auf ihre Tochtergesellschaft, die Unwired Planet LLC, zu übertragen,
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-5
welche ihrerseits das Klagepatent A, wie oben dargestellt, auf die Klägerin übertragen hat. Der entsprechende Übertragungsvertrag zwischen der Unwired Planet Inc.
und der Unwired Planet LLC samt Anhang ist der Klage ebenfalls als Teil des Anlagenkonvoluts EIP A3 beigefügt. Der Übertragungsvertrag zwischen der Unwired
Planet Inc. und der Unwired Planet LLC beinhaltet zudem die Abtretung sämtlicher
Ansprüche zur Durchsetzung des Patents, insbesondere vergangener, gegenwärtiger
und zukünftiger Schadensersatzansprüche (vgl. S. 1 des Übertragungsvertrages vom
14. September 2012 in Anlagenkonvolut EIP A3).
II.
1.
Gegenstand des Klagepatents A
Allgemeiner technischer Hintergrund und relevanter Stand der Technik
Daten für Mobiltelefone
A10. Wie sich aus Absatz [0002] des Klagepatents A ergibt, bezieht sich das Patent auf
den Bereich drahtlose Netzwerke und insbesondere die sichere Datenübertragungen
über drahtlose Netzwerke. Hierbei, und wie in Absatz [0003] des Patents dargestellt,
interagiert ein Mobilfunkgerät mit einem drahtlosen Netzwerk, um Nachrichten von
einem anderen Netzwerk zu empfangen oder anzufordern. Ein solches anderes Netzwerk kann z. B. das Internet sein.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-6
A11. Wie in Absatz [0004] des Klagepatents A dargestellt, kommuniziert das Mobilfunkgerät mit einem Server, um diese Daten zu erhalten. Wie weiterhin in Absatz [0004]
dargestellt, wird der Server sodann tätig, um Nachrichten an das Mobilfunkgerät zu
senden oder von diesem zu empfangen. Diese Nachrichten können beispielweise
„Mitteilungen, elektronische Mail, neue Daten, Konfigurationsinformation, Datendateien, Bibliotheksdateien, Programmdateien etc.
...Anforderungen für Information (z.B. bestimmte Daten), die von den
mobilen Vorrichtungen zum Server übertragen werden“
sein.
A12. Das Klagepatent A verweist auf zwei US-Patentanmeldungen mit den Nummern US
09/071,235 und US 09/070668, die beide am 30. April 1998 angemeldet wurden. Die
spätere Patentanmeldung wurde unter der Patentnummer US 6,314,108 eingetragen
und ist als
Anlage EIP A4
beigefügt, ebenso wie eine Übersetzung der relevanten Passagen derselben als
Anlage EIP A4a.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-7
A13. In Spalte 1 der Anlage EIP A4 werden weitergehende Informationen zu einer Kupplung der Mobilfunkgeräte mit dem Internet gegeben sowie auf die Darstellung 1 dieses Patents verwiesen:
„FIG. 1 ist ein Blockdiagramm eines herkömmlichen Kommunikationssystems 100, das zum Koppeln eines mobilen Kommunikationsgeräts mit dem Internet geeignet ist. Insbesondere umfasst das
Kommunikationssystem 100 eine mobile Kommunikationsvorrichtung
102, die über ein Trägernetzwerk 104 mit einem Netzwerk-Gateway
106 verbindet. Das Netzwerk-Gateway 106 ermöglicht die Kopplung
der mobilen Kommunikationsvorrichtung 102 mit dem Internet 108.
Gewöhnlich werden verschiedene Computersysteme mit Computern,
die einen Anwendungsserver A 110 und einen Anwendungsserver B
112 unterstützen, verbunden oder sind Teil des Internets 108. Die
Hauptfunktion des Netzwerk-Gateway 106 besteht darin, Datenanforderungen von dem Trägernetzwerk 104 zu empfangen und sie in Hypertext Transfer Protocol (HTTP)-Anfragen für die Verwendung mit
dem Internet 108 zu konvertieren. Ebenso empfängt das Netzwerk-Gateway 106 auch HTTP-Antworten von dem Internet 108 und konvertiert
sie in Datenantworten mit einem Format (z. B. Protokoll), das für die
Verwendung mit dem Trägernetzwerk 104 geeignet ist.
Herkömmlicherweise ist das Netzwerk-Gateway 106 in der Lage, ein
einzelnes Trägernetzwerk 104 mit dem Internet 108 zu koppeln.“
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-8
A14. Aus dem vorstehenden ergibt sich, dass ein Gateway den Zugang von Mobilfunkgeräten zu Daten im Internet in einem konventionellen Netzwerk im Prioritätszeitpunkt
des Patents erleichterte.
A15. Dass ein solches Gateway erforderlich ist, um das Mobilfunkgerät mit dem Internet
zu verbinden, ergibt sich aus einem allgemeinen Erfordernis im Prioritätszeitpunkt
des Klagepatents A, da die Protokolle, die von Computern für die Nutzung des Internets (TCP/IP und HTML) verwendet werden, in Protokolle für Mobilfunkgeräte
umgewandelt werden müssen. Dies war beispielsweise deshalb notwendig, weil in
Bezug auf die oben genannten Protokolle zum damaligen Zeitpunkt andere Ressourcenanforderungen bestanden als bei Mobilfunkgeräten.
A16. Aus diesem Grund gründeten im Jahr 1997 die Phone.Com (ein früherer Name der
Muttergesellschaft der Klägerin), Ericsson, Nokia und Motorola das sogenannte
„WAP Forum“, um unter anderem einen einheitlichen Standard für den Internetzugang von einem Mobilfunkgerät zu entwerfen. Die konzeptionelle Lösung wurde am
30. April 1998 öffentlich gemacht, als das WAP Forum die „Wireless Application
Protocol Architecture Specification“ herausgab, von der wir eine Kopie beifügen als
Anlage EIP A5.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-9
A17. Abschnitt 6.2, den wir unten wiedergeben, zeigt die Komplexität der Struktur dieses
Modells.
A18. Übersetzen lässt sich das obige Modell wie folgt:
Inhalt
Kodierte Antwort
Antwort (Inhalt)
Figur 2 WAP-Programmiermodell
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-10
A19. An demselben Tag, als das WAP Forum die Strukturspezifikation veröffentlichte,
gab sie auch eine sogenannte „Wireless Application Protocol Wireless Transport
Layer Security Specification“ heraus, die als Stand der Technik in Absatz [0008] des
Klagepatents A zitiert ist. Das Sicherheitsprotokoll, das dort beschrieben ist, war dafür gedacht, eine sichere Kommunikation zwischen dem Gateway (später als „WAPServer“ bezeichnet) und dem Mobilfunkgerät zu ermöglichen. Der entsprechende
Verbindungskanal (zwischen Mobilfunkgerät und Gateway) ist ein Zweiwege-Kommunikationskanal.
BEWEIS:
Sachverständigengutachten
Zweiwege-Datenkanal
A20. Wie sich aus Absatz [0011] des Klagepatents A ergibt, in dem das Patent von einer
sicheren Datenübertragung spricht, kann ein Mobiltelefon mit zwei unterschiedlichen Arten von Datenkanälen mit einem Server verbunden werden. Des Weiteren
haben diese zwei Kanäle offensichtlich verschiedene Eigenschaften:
-
Der erste Kanal ist ein Zweiwege-Datenkanal/Breitbandkanal;
-
Der zweite Kanal ist ein Einweg-Datenkanal/Schmalbandkanal.
A21. Diese zwei Arten von Kanälen haben unterschiedliche Datenübertragungsraten, und
aus diesem Grund wird der Kanal mit der geringeren Datenübertragungsrate (der
Einweg-SMSC-Kanal) als sogenannter Schmalbandkanal bezeichnet, wohingegen
der Kanal mit der höheren Datenübertragungsrate (der Zweiwege-IWF-Kanal) als
Breitbandkanal bezeichnet wird.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-11
A22. Wie oben und in Absatz [0008] des Klagepatents A beschrieben, kann der Zweiwege-Kanal durch die Nutzung von Protokollen wie beispielsweise WTLS gesichert
werden, wie dies auch das WAP Forum vorgeschlagen hat; das Klagepatent A beschäftigt sich mit der Sicherung des Einweg-Kanals.
A23. Absatz [0011] des Klagepatents A erläutert ferner, wie diese zweifache Verbindungsgestaltung in einem GSM-Mobilfunknetz (oder auch sogenanntes „2G“-Netz)
angewendet werden kann. Das Klagepatent A erklärt, dass ein Mobiltelefon mit einem Server mit Hilfe eines Kanals verbunden werden kann, der durch ein Kurznachrichtendienstzentrum (SMSC – Small Message Service Centre) führt, und mit Hilfe
eines zweiten Kanals, der durch eine Zwischenarbeitsfunktion (IWF – Interworking
Function) führt.
A24. In dieser Gestaltung wird der erste Kanal (der durch das Kurznachrichtendienstzentrum führt) zum Senden von Kurznachrichten (SMS – small message service, so genannte Textnachrichten) zwischen dem Server und dem Mobiltelefon genutzt.
Obwohl solche Kurznachrichten von und an Mobiltelefone gesendet werden können,
wird dieser Kanal aufgrund der zeitlich begrenzten Natur der Verbindung zwischen
Gerät und Server als Einweg-Kanal bezeichnet. Die Verbindung, über welche die
Kurznachricht gesendet wird, besteht nur so lange, wie die Nachricht vom Kurznachrichtendienstzentrum an den Empfänger unterwegs ist. Falls der Empfänger der
Nachricht mit einer zweiten Kurznachricht antwortet, kehren sich die Rolle von Sender und Empfänger um, und eine neue Verbindung muss in die umgekehrte Richtung
hergestellt werden, um eine Nachricht zu senden. Die Zwischenarbeitsfunktion ermöglicht dem 2G-Mobilfunkgerät in diesem Beispiel, mit dem Internet zu kommunizieren. Dieser Kanal wird als Zweiwege-Datenkanal bezeichnet, da Daten in zwei
Richtungen innerhalb dieser Kommunikationssitzung zwischen Sender und Empfänger ausgetauscht werden können.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-12
A25. Die Vorteile, die mit dieser Struktur des Zweiwege-Kanals in Verbindung gebracht
werden, beruhen hauptsächlich auf den Kosten der Nutzung eines Zweiwege-/Breitband-Kanals. Die Kosten werden in Absatz [0011] des Patents beschrieben:
„Eine Verwendung eines Zweiwegekanals veranlasst oft, dass für die
mobile Vorrichtung Belastungen (d. h. Gebühren) von einem Träger
auferlegt werden, der den Service bzw. Dienst zu der mobilen Vorrichtung liefert. Im Gegensatz dazu ist eine Verwendung von einem
Schmalbandkanal mit einem Weg oft ohne Kosten oder mit festen Kosten ungeachtet einer Verwendung verfügbar.“
A26. Diesbezüglich enthält Anlage EIP A4 Verweise auf zahlreiche weitere US Patente,
einschließlich der US-Anmeldung Nr. 09/071,379, mit dem Titel „Method and System for Integrating Narrowband and Wideband data transports“, als Patent mit der
Nr. US 6,138,158 eingetragen. Die entsprechende Schrift reichen wir als
Anlage EIP A6
ein, samt einer deutschen Übersetzung der relevanten Passagen als
Anlage EIP A6a.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-13
A27. Zeilen 35-67 der Spalte 1 dieses Patents geben weitere Hintergrundinformationen
dazu, welche Daten der Nutzer eines Mobilfunkgeräts regelmäßig empfangen
möchte:
„Zum Beispiel kann ein Reisender die Abflugzeit des nächsten verfügbaren Fluges anfordern, wenn er auf dem Weg zu einem Flughafen ist,
oder ein Händler kann Aktien zu einem bestimmten Preis erwerben.
Die relevanten Informationen aus diesen Anfragen oder Transaktionen
können die Fluggesellschaft und die Flugnummer für den Reisenden
ebenso wie die Titelbezeichnung, die Anzahl von Aktien und den Kaufpreis für den Händler umfassen. Um zeitnah und regelmäßig informiert
zu werden, besteht eine Möglichkeit darin, die Informationsanfragen
elektronisch an ein Mobilgerät zu kommunizieren, das an ein drahtloses Datennetz angeschlossen ist. Das drahtlose Datennetz verbindet
beispielsweise über einen Proxy-Server mit einem FluginformationsServer oder Aktienkurs-Server, von dem die gewünschten Fluginformationen bzw. der aktuelle Aktienkurs durch das mobile Gerät bei Bedarf
abgerufen werden.
Alternativ kann der Reisende bzw. der Händler vorzugsweise über jede
verfügbare, unmittelbare Fluginformation bzw. über einen Aktienkurs
informiert werden, der einen vorgegebenen Vorzugspreis erreicht hat.
Es ist jedoch zuweilen störend, den Reisenden bzw. den Händler über
jegliche aktualisierte Änderungen der Flugdaten bzw. des aktuellen
Aktienkurses zu informieren, vor allem über den Aktienkurs während
der Handelszeiten, der jede Sekunde aktualisiert wird. Es besteht daher
großer Bedarf an einer Lösung zum Informieren von Nutzern über alle
Aktualisierungen zu von diesen gewünschten Informationen und um
Nutzern zu ermöglichen, bei Bedarf aktualisierte Informationen abzurufen. Ferner muss in einem leitungsvermittelten Netzwerk, wie GSM,
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-14
ein mobiles Gerät über einen Breitbandkanal eine Schaltung in einer
Betreiber-Infrastruktur erstellen, bevor eine Kommunikation mit irgendeinem Server über das Netzwerk entsteht. Die Verbindung kann,
ähnlich wie bei einer Telefonleitung, zeitaufwendig und kostspielig für
die Nutzer sein. Somit bevorzugen Nutzer in der Regel, eine Kontrolle
über die Kommunikation ihrer mobilen Geräte durch die Betreiber-Infrastruktur beim Zugriff auf aktualisierte Informationen von einem
Web-Server zu haben.“
A28. Anlage EIP A6 zeigt auch, dass die Verbindung zwischen Mobiltelefon und Server
durch einen Schmalband-Kanal genutzt werden kann, um Benachrichtigungen an das
Mobiltelefon zu schicken und den Nutzer des Geräts darüber zu informieren, dass
aktualisierte Informationen für das Gerät auf dem Server vorhanden sind, und um
sich mit dem Breitband-Kanal zu verbinden. Diese Nutzung beider Kanäle ermöglicht die Kontrolle über den Zugang zum Breitband-Kanal, um aktualisierte Informationen zu erhalten, und gleichzeitig ermöglicht sie die Kontrolle darüber,
inwieweit sich der Nutzer eines Mobiltelefons hierdurch Kosten aussetzt.
Sicherheit
A29. Nimmt man das Beispiel aus Absatz [0011] des Patents, die Schaffung einer dualen
Kanalstruktur, die ein Mobiltelefon mit einem Server verbindet, und innerhalb welcher diese beiden Kanäle genutzt werden, um Benachrichtigungen und Daten an ein
Mobiltelefon zu übermitteln (wie oben beschrieben), führt dies zu Sicherheitsrisiken,
die in einem Kurznachrichtenkanal nicht notwendigerweise immer vorhanden sind,
und die auch nicht in einer konventionellen Zweiwege-Kanalstruktur vorhanden
sind.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-15
A30. Diese Sicherheitsrisiken resultieren daraus, dass der Einweg-Kanal dazu genutzt
wird, um den Nutzer eines Mobiltelefons mit aktualisierten Informationen von einem
Webserver (statt von einem anderen Mobiltelefon mit einer bekannten Nummer) zu
versorgen und hierdurch die Möglichkeit entsteht, dass die Benachrichtigung eine
Verbindung zu einem Webserver über einen Zweiwege- und/oder Breitband-Kanal
und entsprechende Kosten auslöst.
A31. Diesbezüglich sollte vermieden werden, dass der Nutzer falsche oder ungewollte Informationen erhält, damit sich das Gerät nicht unnötigerweise über einen Breitbandkanal mit einem Server verbindet und hierdurch überflüssige Kosten anfallen, oder
aber um zu verhindern, dass das Gerät an einen unerwünschten Server weitergeleitet
wird. Insofern besteht also die Notwendigkeit, die Benachrichtigungen zunächst zu
authentifizieren. Hierfür müssen solche Benachrichtigungen, die über den Schmalband- und/oder Einweg-Kanal übermittelt werden, zunächst geschützt und/oder authentifiziert werden.
A32. Obwohl es, wie oben bereits beschrieben und in den Absätzen [0008] bis [0010]
ausgeführt, möglich ist, den Zweiwege-Datenkanal durch Verschlüsselung und Signaturtechniken zu sichern, welche als sogenannte „Handshake“-Prozedur (oder auch
WTLS) bekannt ist, ist eine solche Handshake-Prozedur zur Sicherung eines Einweg-Kanals offensichtlich nicht möglich, da die Kommunikation nur in eine Richtung
möglich
ist
und
die
relevanten
Parameter
während
einer
Kommunikationssitzung nicht zwischen dem Sender und dem Empfänger ausgetauscht werden können. Es kommt hinzu, dass derartige Handshake-Prozeduren auch
aufgrund der verschiedenen Eigenschaften von Schmalband- und Breitband-Kanälen
(beispielsweise die reduzierte Datenübertragungsrate bei einem Schmalbandkanal)
bei einem Schmalband-Kanal unerwünscht sind.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-16
A33. Das Klagepatent A führt aus, dass die Publikation MEHROTA ET AL: "MOBILITY
AND SECURITY MANAGEMENT IN THE GSM SYSTEM AND SOME PROPOSED
FUTURE IMPROVEMENTS" PROCEEDINGS OF THE IEEE, IEEE. NEW
YORK, US, vol. 86, no. 7, July 1998 (1998-07), Seiten 1480-1497, XP000854168
ISSN: 0018-9219, veröffentlicht im Juli 1998, einen sogenannten Handshake zwischen einem Zugangsserver, verbunden mit einem Netzwerkzugangspunkt, und einem Mobiltelefon beschreibt, um eine sichere Verbindung zwischen dem mobilen
Endgerät und dem Netzwerkzugangspunkt herzustellen. Neben dem Handshake besteht keine Notwendigkeit, zusätzliche Daten zwischen dem Mobilkunden und dem
Netzwerkzugangspunkt oder dem Zugangsserver auszutauschen. Vielmehr besteht
der Sinn des Herstellens einer sicheren Verbindung ausschließlich darin, einen Kontakt und Handshake zwischen dem Mobiltelefon und dem Netzwerkzugangspunkt
herzustellen. Die Verbindung ist insofern sowohl bezüglich des Datenaustausches
als auch hinsichtlich des Umfangs der Verbindung begrenzt. Das zuvor genannte
Dokument ist als
Anlage EIP A7
beigefügt, ebenso wie eine deutsche Übersetzung der relevanten Passagen als
Anlage EIP A7a.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
2.
Seite A-17
Erfindungsgemäße Lösung
A34. Das Klagepatent A lehrt, gezielt Daten zu schützen, die in einem Schmalbandund/oder Einweg-Kanal zwischen einem Klienten und einem (Ziel)Server übertragen
werden.
A35. Die erfindungsgemäße Lösung sieht die Nutzung eines Schmalband-/Einweg-Kanals
für die Übermittlung gesicherter Informationen ohne größere technische Eingriffe
vor. Ein Umbauen von herkömmlichen Netzen für die Nutzung mit gesicherten Daten ist nicht erforderlich. Durch den zielgerichteten Einsatz eines Breitband-/Zweiwege-Kanals kann der Austausch von Sicherheitsinformation zwischen dem
Klienten und dem Server durchgeführt werden, um beispielsweise Daten zu verschlüsseln oder zu signieren, bevor sie übertragen werden.
A36. Dies hat mehrere Vorteile. Zum einen muss der übliche Schmalband-/Einweg-Kanal,
der nicht mitbekommt, ob sicherer oder ungesicherte Daten übertragen werden, nicht
modifiziert werden.
A37. Zum anderen muss der Breitband-/Zweiwege-Kanal nur für die Zeit aufgebaut werden, bis die Sicherheitsinformationen ausgetauscht sind. Solange dann Daten über
den Schmalband-/Einweg-Kanal ausgetauscht werden, muss ein weiterer Breitband/Zweiwege-Kanal nicht in Anspruch genommen werden, nachdem die Sicherheitsinformationen ausgetauscht worden sind. Da die Nutzungsgebühren für den Breitbandkanal teuer sein und sich nach den übertragenen Daten richten können, werden durch
den Abbau des Breitbandkanals nach erfolgreichem Handshake Kosten gespart. Die
benötigte zusätzliche Kanalkapazität wird also nur für den Zeitraum bereitgestellt,
während dessen sie tatsächlich benötigt wird.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-18
A38. Da ein Breitbandkanal Daten mit einer höheren Übertragungsrate als ein Schmalbandkanal überträgt, kann der Zeitraum verkürzt werden, der für das Austauschen
der Sicherheitsinformation benötigt wird (siehe auch Absatz [0022] des Klagepatents).
A39. Die Klägerin bietet für die Richtigkeit der obigen Ausführungen zum Hintergrund
und zum fachmännischen Verständnis der technischen Lehre des Klagepatents A sowie zum Verständnis einzelner Begriffe zum
BEWEIS:
Sachverständigengutachten.
A40. Die Merkmale der patentgemäßen Lösung von Anspruch 6 des Klagepatents können
wie folgt gegliedert werden:
1.
Verfahren zum sicheren Übertragen von Daten zwischen einem Klienten und
einem Server über einen Schmalbandkanal.
2.
Der Klient und der Server sind nicht nur durch den Schmalbandkanal verbindbar, sondern auch durch einen Breitbandkanal.
3.
Der Klient und der Server werden über den Breitbandkanal verbunden.
4.
Es werden Sicherheitsinformationen zwischen dem Klienten und dem Server
über den Breitbandkanal ausgetauscht.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
5.
Seite A-19
Die vom Server zum Klienten zu übertragenden Daten werden basierend auf
der Sicherheitsinformation signiert.
6.
Die signierten Daten werden vom Server zum Klienten über den Schmalbandkanal übertragen.
7.
Wenigstens ein Teil des Schmalbandkanals und des Breitbandkanals ist drahtlos.
A41. Die Merkmale der patentgemäßen Lösung von Anspruch 7 des Klagepatents können
wie folgt gegliedert werden:
1.
Funkvorrichtung, die ein Netzwerk von Computern über eine drahtlose Verbindung verbinden kann.
2.
Die Funkvorrichtung weist einen Anzeigebildschirm auf, der Grafiken und
Text anzeigt.
3.
Die Funkverbindung enthält einen Nachrichtenpuffer, der eine Nachricht von
einem Computer am Netzwerk von Computern temporär speichert, wobei
3.1
die Nachricht ein damit verbundenes Dienstkennzeichen hat.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
4.
Seite A-20
Die Funkvorrichtung weist eine Anwendung auf, die die vom Computer am
Netzwerk von Computern empfangene Nachricht verwendet.
5.
Es ist eine kryptografische Steuerung vorgesehen, die
5.1
eine Verschlüsselung oder Signatur von abgehenden Nachrichten
steuert und
5.2
die Entschlüsselung oder Authentifizierung von ankommenden Nachrichten steuert.
5.3
Die kryptografische Steuerung arbeitet, um eine sichere Verbindung,
über die sie die ankommenden Nachrichten empfängt, durch Verwenden eines Einwegkanals aufzubauen.
5.4
Dabei wird ein dazugehöriger Zweiwegkanal verwendet, um Sicherheitsinformationen auszutauschen, die zum Aufbauen der sicheren
Verbindung über den Einwegkanal nötig ist.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-21
Die vorstehende Merkmalsgliederung von Anspruch 6 und 7 nebst einer Gegenüberstellung der deutschen und englischen Anspruchswortlaute wird – dreifach für das
Gericht – als
Anlage EIP A8
vorgelegt.
III. Verletzung des Klagepatents A
1.
Verletzungshandlungen der Beklagten in Deutschland
A42. Die Beklagten zu 1 bis 3 haben unter dem Namen „Google Cloud Messaging für
Android“ („GCM“) einen Dienst entwickelt, angeboten und angewandt, der das Klagepatent A verletzt (im Einzelnen hierzu unter 2. unten).
A43. Dieselben Beklagten haben einen Dienst unter dem Namen „Cloud to Device Messaging Service („C2DM“) angeboten, welcher das Klagepatent A ebenfalls verletzt
(im Einzelnen hierzu unter 3. unten).
A44. Sie bieten auch Smartphones und Tablets mit dem Android-Betriebssystem an, sogenannte „Google-Nexus“-Geräte. Die Google-Nexus-Geräte, die von der Beklagten
zu 1 hergestellt werden, werden mit auf dem Gerät vorinstallierten Anwendungen
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-22
(z. B. Google Play, Chrome, Google+ und Gmail) – sogenannten „Apps“ – angeboten. Die Google Nexus Geräte ermöglichen es den Nutzern, Anwendungen von einem Web-basierten Appstore auf ihr Smartphone oder Tablet herunterzuladen. Diese
Anwendungen dienen als Hilfsmittel zur Nutzung der Smartphones/Tablets, als Informationsmittel, zur Kommunikation oder auch zum Spielen. Diese Anwendungen
nutzen den C2DM-Dienst oder den GCM-Dienst, um Informationen von einem verbundenen Server zu erhalten. Die Folge ist, dass durch das Anbieten und den Verkauf
der Google-Nexus-Geräte in Deutschland das Klagepatent A verletzt wird (im Einzelnen hierzu unter 4. unten).
A45. Der Unterzeichner hat auf der Website „Google Play Store“ (play.google.com) einen
Testkauf eines Google-Nexus-4-Geräts durchgeführt. Laut Impressum der Website
wird diese von der Beklagten zu 1 betrieben. Einen entsprechenden Ausdruck fügen
wir als
Anlage EIP A9
bei.
A46. Die Rechnung für den vom Unterzeichner durchgeführten Testkauf weist die Beklagte zu 2 als Verkäuferin des Nexus 4 aus. Diese legen wir vor als
Anlage EIP A10.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-23
A47. Die Beklagten zu 1 und 2 wenden den C2DM-Dienst oder den GCM-Dienst an, um
Daten an auf Mobiltelefonen mit dem Android-Betriebssystem installierte Anwendungen zu senden. Die Anwendung dieses C2DM-Dienstes oder des GCM-Dienstes
verletzt das Klagepatent A (im Einzelnen hierzu unter 5. unten).
A48. Die Beklagte zu 3 hat in einem Telefongespräch zu einem Testkauf, welches zwischen Frau Sylvia Hoffmann und einem Mitarbeiter des Vertriebsbüros der Beklagten zu 3 in Hamburg stattgefunden hat, Google-Nexus-Geräte angeboten, indem er
auf die Play Store Website der Beklagten zu 1 verwiesen hat.
BEWEIS:
Zeugnis der Frau Sylvia Hofmann, zu laden über
die Adresse der Kanzlei Ampersand, Haydnstr. 10,
80336 München
A49. Die Beklagten zu 4 und 5 bieten Produkte wie Smartphones und Tablets mit dem
Android-Betriebssystem an. Diese Produkte werden mit auf dem Gerät vorinstallierten Anwendungen (z. B. Google Play, Chrome, Google+ und Gmail) – sogenannte
„Apps“ – angeboten. Diese Produkte ermöglichen es dem Nutzer ebenfalls, Anwendungen aus einem Web-basierten Appstore auf ihr Smartphone oder Tablet herunterzuladen. Diese Anwendungen nutzen auch den C2DM-Dienst oder den GCMDienst, um Informationen von einem verbundenen Server zu erhalten (im Einzelnen
hierzu unter 6. unten).
Die Beklagten zu 6, 7 und 9 stellen ebenfalls Produkte mit dem Android-Betriebssystem wie Smartphones und Tablets her, bieten diese an und/oder verkaufen diese
(im Einzelnen hierzu unter 7. bis 9. unten).
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
2.
Seite A-24
Benutzung der Lehre des Klagepatents A – Das „Google Cloud Messaging for
Android Service“ („GCM“)
2.1
Hintergrund zu GCM
A50. Die Beklagte zu 1 stellt auf ihrer Webseite http://developer.android.com eine detaillierte Beschreibung des GCM-Dienstes zur Verfügung. Einen Ausdruck der relevanten Webseiten fügen wir als
Anlagenkonvolut EIP A11
bei, sowie eine deutsche Übersetzung der relevanten Passagen
Anlagenkonvolut EIP A11a.
A51. Diese Webseiten zeigen, dass es sich bei dem GCM-Dienst um einen Dienst handelt,
der Daten von Servern an Android-Anwendungen auf Android-Mobiltelefone sendet, und dass das Datenvolumen, das von einem Server an eine Anwendung gesendet
werden kann, auf 4kb begrenzt ist.
„Google Cloud Messaging für Android (GCM) ist ein Dienst , mit dem Sie
Daten von Ihrem Server zu Ihrem Android-gestützten Nutzer-Gerät senden
können und auch Nachrichten von Geräten auf der gleichen Verbindung
empfangen können. Der GCM-Dienst befasst sich mit sämtlichen Aspekten
bei der Bildung einer Warteschleife von Nachrichten und Lieferung zur
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-25
Android-Zielanwendung, die auf dem Zielgerät läuft. GCM ist völlig kostenlos, ganz egal, wie groß Ihr Messaging-Bedarf ist, und es gibt keine
Kontingente.“
(Seite 1 des Anlagenkonvoluts EIP A11 und EIP A11a)
„Google Cloud Messaging für Android (GCM) ist ein kostenloser
Dienst, mit dem Entwickler Daten von Servern aus an ihre AndroidApps auf Android-Geräten sowie Upstream-Nachrichten von dem
Gerät des Nutzers zurück in die Cloud senden können. Dabei kann
es sich um eine einfache Nachricht an die Android App handeln,
dass auf dem Server neue Daten zur Übertragung bereitliegen (wie
beispielsweise eine "neue E-Mail"-Nachricht, welche die App informiert, dass sie nicht synchron mit dem anderen Ende ist), oder es
kann sich um eine Nachricht mit bis zu 4 KB Nutzdaten handeln (so
können Apps wie Instant Messaging die Nachricht direkt verarbeiten). Der GCM-Dienst befasst sich mit sämtlichen Aspekten der Bildung von Warteschleifen anstehender Nachrichten und Lieferung
zur Android-Zielanwendung, die auf dem Zielgerät läuft.“
(Seite 3 des Anlagenkonvoluts EIP A11 und EIP A11a)
A52. Die Webseiten zeigen, dass Daten auf sichere Art und Weise gesendet werden.
„Die IDs und Tokens, die in unterschiedlichen Stadien von GCM
verwendet werden, um sicherzustellen, dass alle Beteiligten authentifiziert wurden, und dass die Nachricht an die richtige Stelle gelangt.“
(Seite 3 des Anlagenkonvoluts EIP A11 und EIP A11a)
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-26
A53. Die Webseiten zeigen, dass ein Server, um eine Nachricht an eine Android-Anwendung auf einem Android-Mobiltelefon zu senden, die Benachrichtigungen über einen
von der Beklagten zu 1 betriebenen Server senden muss.
“Architektur-Überblick
Eine GCM Implementierung umfasst einen von Google bereitgestellten Verbindungsserver, einen Drittanbieter-Anwendungsserver,
der mit dem Verbindungsserver interagiert, und eine GCM-fähige
Client-App, die auf dem Android-Gerät läuft:
Grafik 1, GCM-Architektur
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-27
A54. So interagieren diese Komponenten:
-
Von Google bereitgestellte GCM-Verbindungsserver nehmen Nachrichten von einem Drittanbieter-Anwendungsserver entgegen und senden diese Nachrichten zu einer GCM-fähigen Android-App (die
"Client App"), die auf einem Gerät läuft. Derzeit stellt Google Verbindungsserver für HTTP und XMPP bereit.
-
Der Drittanbieter-Anwendungsserver ist eine Komponente, die Sie implementieren, um mit Ihrem gewählten GCM-Verbindungsserver(n) zu
arbeiten.
App-Server
senden
Nachrichten
zu
einem
GCM-
Verbindungsserver; der Verbindungsserver reiht die Nachricht in die
Warteschleife ein und speichert sie ab und sendet sie dann zum Gerät,
wenn das Gerät online ist. Für weitere Informationen siehe Implementieren GCM Server.
-
Die Client App ist eine GCM-fähige Android-App, die auf einem Gerät
läuft. Um GCM-Nachrichten zu empfangen, muss diese App sich mit
GCM registrieren und eine Registrierungs- ID bekommen. Wenn Sie
den XMPP (CCS) Verbindungsserver nutzen, kann die Client App
"Upstream"-Nachrichten zurück zum Verbindungsserver senden. Für
weitere Informationen, wie die Client App zu implementieren ist, siehe
Implementieren GCM Client.
(Seite 4 des Anlagenkonvoluts EIP A11 und EIP A11a)
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-28
A55. Die Webseiten zeigen ebenfalls, dass die GCM-Verbindungsserver der Beklagten
zu 1 einen Drosselungsmechanismus zur Verfügung stellen, indem sie ein sogenanntes „bucket scheme“ nutzen.
„Um Missbrauch vorzubeugen (wie das Versenden einer Flut von
Nachrichten zu einem Gerät) und um die Gesamteffizienz von Netzwerk und Akkulaufzeit von Geräten zu optimieren, implementiert
GCM die Drosselung von Nachrichten unter Verwendung eines Token Bucket Schemas. Nachrichten werden gedrosselt auf einer pro
Anwendung und pro collapse key (#collapsible) Basis (einschl. noncollapsible Nachrichten). Jeder application collapse key wird mit
einigen ursprünglichen Tokens gewährt und neue Tokens werden
anschließend regelmäßig gewährt. Jeder Token ist für eine einzelne
Nachricht gültig, die zum Gerät gesandt wurde. Wenn ein application collapse key seinen Vorrat an verfügbaren Tokens ausgeschöpft
hat, werden neue Nachrichten in einer anstehenden Warteschleife
gepuffert, bis neue Tokens innerhalb der Zeit der regelmäßigen Gewährung verfügbar werden. Daher kann eine Drosselung zwischen
regelmäßigen Gewährungsintervallen zur Latenzzeit von Nachrichtenübermittlung bei einem application collapse key hinzukommen,
wo eine große Anzahl von Nachrichten innerhalb einer kurzen Zeitspanne gesendet wird. Nachrichten in der Warteschleife eines application collapse key können vor dem Zeitraum der nächsten,
regelmäßigen Gewährung übermittelt werden, wenn sie mit Nachrichten ausgestattet sind, die zu einer nicht gedrosselten Kategorie
von GCM aus Gründen der Netzwerk- und Akku-Leistungsfähigkeit
gehören.“
(Seite 61 des Anlagenkonvoluts EIP A11 und EIP A11a)
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-29
A56. Das genutzte „bucket scheme“ ist ein Verweis auf die Nutzung des sogenannten Bucket-Algorithmus, dessen Mechanismus dafür bekannt ist, in einem bestimmten Kanal den Datenfluss zu reduzieren. Wir fügen als
Anlagenkonvolut EIP A12
die Wikipediaeinträge für „Token Bucket Algorithmus“ auf http://de.wikipedia.org/wiki/Token-Bucket-Algorithmus und für „Traffic-Shaping“ auf http://de.wikipedia.org/wiki/Traffic_shaping bei, von denen die folgenden Auszüge entnommen
sind:
„Der Token-Bucket-Algorithmus ist ein Algorithmus zur Verkehrsformung in paketvermittelten Datennetzen. Er reguliert
durch Netzwerk-Scheduler die mittlere Datenrate und maximale
Burst-Größe. (...)
Dem Datenstrom werden regelmäßig bestimmte Kontingente zugeteilt, die ausgenutzt oder bis zu einer gewissen Grenze angesammelt
werden können. Um die Sache anschaulicher zu machen, stellt man
sich die Zuteilung bildhaft in Form von "Wertmarken" (englisch Token) vor, die in regelmäßigen Abständen in einen metaphorischen
"Eimer" (englisch Bucket) geworfen werden. Jede Wertmarke steht
für ein bestimmtes Datenkontingent, das übertragen werden darf.
Wenn der Eimer voll ist, werden keine Wertmarken zugeteilt. (...)
Die Größe (Kapazität) des Eimers bestimmt das maximale Guthaben, das sich ansammeln kann. Dadurch wird verhindert, dass die
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-30
durchschnittliche Datenrate über einen zu langen Zeitraum überschritten wird.“
„Traffic-Shaping (auch Verkehrsformung) bezeichnet eine Art der
Warteschlangenverwaltung bei paketvermittelten Datennetzen, bei
der Datenpakete nach bestimmten Kriterien verzögert oder verworfen werden, um bestimmten Anforderungsprofilen zu genügen.
Durchgeführt wird diese Funktion von einem Netzwerk-Scheduler
und ist grundsätzlich eine Form der Datenratenbegrenzung. (...)
Die verbreitetsten Algorithmen zur Warteschlangenverwaltung sind
der Leaky-Bucket-Algorithmus und der Token-Bucket-Algorithmus.“
A57. Ferner kann den Seiten 4, 5 und 14 des Anlagenkonvoluts EIP A11 entnommen
werden, dass der GCM-Dienst der Beklagten zu 1 erfordert, dass sich die AndroidAnwendung auf dem Android-Mobiltelefon mit der entsprechenden RegistrierungsID auf dem Server anmeldet, welche sie zuvor von den GCM Servern erhalten hat.
Registrierungs- ID
Eine ID, die von den GCM-Servern an die Android-Anwendung vergeben wird, und dieser erlaubt Nachrichten zu empfangen. Sobald die Android-Anwendung die Registrierungs-ID erhalten hat, sendet sie
diese an den Drittanbieter-Anwendungsserver, welcher diese nutzt, um jedes Gerät zu identifizieren, welches sich registriert hat, um Mitteilungen für eine bestimmte Android-Anwendung zu empfangen. Anders
ausgedrückt ist die Registrierungs-ID an eine bestimmte Android-Anwendung gebunden, die sich auf einem bestimmten Gerät befindet.
(Seite 4 des Anlagenkonvoluts EIP A11 und EIP A11a)
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-31
„GCM aktivieren
Das erste Mal, wenn die Android-App die Verwendung des Nachrichtendienstes braucht, ruft sie das GoogleCloudMessaginq (/reference/com/google/android/gms/gcm/GoogleCloudMessaging.html)
Verfahren register ( ), wie in Implementieren GCM Client (client.html) erörtert. Das register ()Verfahren sendet eine Registrierungs-ID zurück. Die Android-App soll diese ID zur späteren
Verwendung abspeichern (beispielsweise um in onCreate ()zu prüfen,
ob sie bereits registriert ist).“
(Seite 5 des Anlagenkonvoluts EIP A11 und EIP A11a)
„Registrieren für GCM
Eine Android-App muss mit GCM-Servern registriert werden, bevor
sie Nachrichten empfangen kann. Wenn eine App registriert wird, bekommt sie eine Registrierungs-ID, die sie dann für künftige Verwendungen speichern kann. Im folgenden Abschnitt wird im onCreate ()
Verfahren beispielhaft bei der Haupttätigkeit der App überprüft, ob
die App bereits mit GCM und mit dem Server registriert ist:“
(Seite 14 des Anlagenkonvoluts EIP A11 und EIP A11a)
A58. Die Webseiten zeigen, dass diese Registrierungs-ID zusammen mit den Daten vom
Server auf die Android-Anwendung auf dem Android-Mobiltelefon übertragen werden muss, unabhängig davon, welche Art von Verbindung genutzt wird.
-
Dort wo der GCM-Verbindungs-Service eine HTTP-Verbindung nutzt und
die Mitteilung eine Mitteilung der Art JSON ist, muss die Registrierungs-ID
in dem „Registration_ids“-Feld enthalten sein.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
registration_ids
Seite A-32
Ein String-Array mit der Liste der Geräte (Registrierungs- IDs), die die Nachricht
empfangen. Es muss mindestens 1 und höchstens 1000 Registrierungs-IDs enthalten.
Um eine Multicast-Nachricht zu senden, müssen Sie JSON verwenden. Um eine einzelne Nachricht zu einem einzelnen Gerät zu senden, kann man ein JSON-Objekt mit
nur einer Registrierungs-ID oder Klartext (siehe unten) verwenden. Eine Anforderung
muss einen Empfänger enthalten - dies kann entweder eine Registrierungs-ID, eine
HTTP
Reihe von Registrierungs-IDs oder ein notification_key sein. Erforderlich.
(Seite 25 des Anlagenkonvoluts EIP A11 und EIP A11a)
-
Dort wo der GCM-Verbindungsserver eine HTTP-Verbindung nutzt und die
Mitteilung von der Art her eine reine Textnachricht ist, muss die Registrierungs-ID im Feld “Registration_id” enthalten sein.
„registration_id
Muss die Registrierungs-ID von dem einzelnen Gerät enthalten, das die Nachricht empfängt. Erforderlich.“
(Seite 26 des Anlagenkonvoluts EIP A11 und EIP A11a)
A59. Die Registrierungs-ID muss gleichzeitig mit den Daten übersandt werden, da der
GCM-Server ohne die Registrierungs-ID eine Übermittlung der Nachricht an das
Mobiltelefon nicht zulässt. Dass die Registrierungs-ID dazu dient, die Nachricht zu
authentifizieren, geht insbesondere aus dem Abschnitt „Wie Deregistrierung funktioniert“ des Anlagenkonvoluts EIP EIP A11 und A11a (auf Seite 62) hervor:
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-33
„Eine App kann automatisch deregistriert werden, nachdem sie von dem
Gerät deinstalliert wurde.
Jedoch geschieht dieser Prozess nicht sofort, da Android keinen Deinstallations-Rückruf bereitstellt. Was bei diesem Prozess geschieht, ist Folgendes:
1.
Der Endnutzer deinstalliert die App.
2.
Der Drittanbieter-Server sendet eine Nachricht an den GCM-Server.
3.
Der GCM-Server sendet die Nachricht an das Gerät.
4.
Der GCM-Client empfängt die Nachricht und fragt den Package-Manager darüber ab, ob es Funkempfänger gibt, die zu deren Empfang
konfiguriert sind, der false zurücksendet.
5.
Der GCM-Client informiert den GCM-Server darüber, dass die App
deinstalliert wurde.
6.
Der GCM-Server markiert die Registrierungs-ID zum Löschen.
7.
Der Drittanbieter-Server sendet eine Nachricht an GCM.
8.
GCM sendet eine NotRegistered Fehlermeldungen an den Drittanbieter-Server zurück.
9.
Der Drittanbieter löscht die Registrierungs-ID.
| Hinweis: Der GCM-Client ist das Google Cloud Messaging Framework, das auf dem Gerät vorhanden ist.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-34
Beachten Sie, dass es womöglich eine Weile dauern kann, bis die
Registrierungs-ID vollständig von GCM entfernt ist. Dadurch ist es
möglich, dass Nachrichten, die während des obigen Schritts 7 versandt werden, als Antwort eine gültige ID-Nachricht bekommen, obgleich
die
Nachricht
nicht
dem
Gerät
zugestellt
wird.
Gegebenenfalls wird die Registrierungs-ID entfernt und es erhält
der Server eine NotRegistered Fehlermeldung, ohne dass eine weitere Maßnahme vom Drittanbieter-Server angefordert wird (dieser
Prozess findet häufig statt, während die App entwickelt und getestet
wird).“
A60. Die Webseiten zeigen, wie eine Android-Anwendung auf einem Android-Mobiltelefon programmiert werden muss, um das Android-Betriebssystem dieses AndroidMobiltelefons zu nutzen, um eine Registrierungs-ID des von der Beklagten zu 1 bereitgestellten Servers zu erhalten:
DemoActivity die folgende registerInBackground ()Verfahren zum Registrieren auf. Beachten Sie, dass bei Blockieren der GCM Verfahren register()und unregister()dies in einem HintergrundThread erfolgen muss. Dieses Beispiel verwendet AsyncTask
(/reference/android/os/AsyncTask.html), um Folgendes zu erfüllen:
„Falls keine gültige Registrierungs-ID besteht, dann ruft
/**
* Registriert asynchron die App mit GCM-Servern.
* <p>
* Speichert die Registrierungs-ID und App versionCode in den
* shared preferences der App.(…)“
(Seite 16 des Anlagenkonvoluts EIP A11 und EIP A11a)
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-35
A61. Die Webseiten zeigen ferner, wie eine Android-Anwendung für ein Android-Mobiltelefon programmiert werden muss, damit das Betriebssystem dieses Mobiltelefons
die Registrierungs-ID an den verbundenen Server sendet:
„...
/**
* Sendet die Registrierungs-ID über HTTP zu Ihrem
Server, damit
* er GCM/HTTP oder CCS verwenden kann, um Nachrichten zu Ihrer
* App zu senden. Nicht für diese Demo benötigt,
da das Gerät
* Upstream-Nachrichten zu einem Server sendet,
der die Nachricht * unter Verwendung der 'from'
Adresse in der Nachricht
* zurückwirft.
*/
private void sendRegistrationIdToBackend() (
//Hier Ihre Implementierung.“
(Seite 17 des Anlagenkonvoluts EIP A11 und EIP A11a)
A62. Dieselbe Information zeigt, dass die Registrierungs-ID über eine HTTP-Verbindung
und nicht über einen Server der Beklagten zu 1 gesendet wird und damit nicht dem
GCM-Drosselungsmechanismus ausgesetzt wird.
A63. Zusammenfassend haben wir in der umseitig dargestellten Grafik eine Übersicht der
Schritte des Sendens der Daten von einem Server an eine Android-Anwendung auf
ein Android-Mobiltelefon unter Nutzung des GCM-Dienstes der Beklagten zu 1 dargestellt.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
2.2
Seite A-36
Die Verletzung des Patentanspruchs 6 des Klagepatents durch GCM
Anspruchsmerkmal 1:
Verfahren zum sicheren Übertragen von Daten zwischen einem Klienten und einem Server über einen
Schmalbandkanal.
A64. Das Verfahren ist das in Anlagenkonvolut EIP A11 beschriebene, nämlich „Google
Cloud Messaging Service“ oder auch „GCM“ der Beklagten zu 1. Die Dienste werden von den Beklagten zu 1 bis 3 zur Anwendung von Android-Anwendungen auf
einem Android-Gerät angeboten:
„Google Cloud Messaging für Android (GCM) ist ein kostenloser
Dienst, mit dem Entwickler Daten von Servern aus an ihre AndroidApps auf Android-Geräten sowie Upstream-Nachrichten von dem
Gerät des Nutzers zurück in die Cloud senden können. Dabei kann
es sich um eine einfache Nachricht an die Android App handeln,
dass auf dem Server neue Daten zur Übertragung bereitliegen (wie
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-37
beispielsweise eine "neue E-Mail"-Nachricht, welche die App informiert, dass sie nicht synchron mit dem anderen Ende ist), oder es
kann sich um eine Nachricht mit bis zu 4 KB Nutzdaten handeln (so
können Apps wie Instant Messaging die Nachricht direkt verarbeiten). Der GCM-Dienst befasst sich mit sämtlichen Aspekten der Bildung von Warteschleifen anstehender Nachrichten und Lieferung
zur Android-Zielanwendung, die auf dem Zielgerät läuft.“
(Seite 3 des Anlagenkonvoluts EIP A11 und EIP A11a)
„Die IDs und Tokens, die in unterschiedlichen Stadien von GCM
verwendet werden, um sicherzustellen, dass alle Beteiligten authentifiziert wurden, und dass die Nachricht an die richtige Stelle gelangt.“
(Seite 3 des Anlagenkonvoluts EIP A11 und EIP A11a)
A65. Mit anderen Worten, das GCM-Verfahren der Beklagten zu 1 ist ein Verfahren zur
sicheren Datenübertragung.
A66. Der Klient ist das Mobiltelefon mit dem von der Beklagten zu 1 bereitgestellten Android-Betriebssystem.
A67. Der Server ist ein Anwendungsserver, der mit einer Android-Anwendung auf diesem
Android-Mobiltelefon verbunden ist und der darauf programmiert ist, Nachrichten/Benachrichtigungen an die besagte Anwendung auf dem Android-Mobiltelefon
zu senden.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-38
A68. Der Schmalbandkanal ist die Verbindung zwischen dem Klienten und dem Server,
der über den Google-Verbindungsserver führt. Die Beklagte zu 1 beschreibt diesen
Kanal in Anlagenkonvolut EIP A11 auf den Seiten 4, 5, 9, 23, 23, 29 und 45:
Seite 4:
“Architektur Überblick
Eine GCM Implementierung umfasst einen von Google bereitgestellten Verbindungsserver, einen Drittanbieter-Anwendungsserver,
der mit dem Verbindungsserver interagiert, und eine GCM-fähige
Client-App, die auf dem Android-Gerät läuft:
A69. So interagieren diese Komponenten:
-
Von Google bereitgestellte GCM-Verbindungsserver nehmen Nachrichten
von einem Drittanbieter-Anwendungsserver entgegen und senden diese
Nachrichten zu einer GCM-fähigen Android-App (die "Client App"), die auf
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-39
einem Gerät läuft. Derzeit stellt Google Verbindungsserver für HTTP und
XMPP bereit.
-
Der Drittanbieter-Anwendungsserver ist eine Komponente, die Sie implementieren, um mit Ihrem gewählten GCM-Verbindungsserver(n) zu arbeiten.
App-Server senden Nachrichten zu einem GCM-Verbindungsserver; der Verbindungsserver reiht die Nachricht in die Warteschleife ein und speichert sie
ab und sendet sie dann zum Gerät, wenn das Gerät online ist. Für weitere
Informationen siehe Implementieren GCM Server.
-
Die Client App ist eine GCM-fähige Android-App, die auf einem Gerät läuft.
Um GCM-Nachrichten zu empfangen, muss diese App sich mit GCM registrieren und eine Registrierungs- ID bekommen. Wenn Sie den XMPP (CCS)
Verbindungsserver nutzen, kann die Client App "Upstream"-Nachrichten zurück zum Verbindungsserver senden. Für weitere Informationen, wie die Client App zu implementieren ist, siehe Implementieren GCM Client.“
Seite 5:
„Versenden einer Nachricht
Hier ist die Abfolge der Ereignisse, die eintritt, wenn der Anwendungsserver eine Nachricht sendet:
1. Der Anwendungsserver sendet eine Nachricht zu GCM-Servern.
2. Google reiht die Nachrichten in die Warteschleife ein und speichert sie
ab, falls das Gerät offline ist.
3. Wenn das Gerät online ist, sendet Google die Nachricht an das Gerät.
4. Auf dem Gerät überträgt das System die Nachricht an die angegebene
Android-App über Intent broadcast mit korrekten Berechtigungen, so
dass nur die gezielte Android-App die Nachricht bekommt. Dies weckt
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-40
die Android-App. Die Android-App braucht nicht vorher zu laufen, um
die Nachricht zu empfangen.
5. Die Android-App verarbeitet die Nachricht. Wenn die Android-App eine
nicht-triviale Verarbeitung durchführt, möchten Sie vielleicht eine
PowerManager.WakeLock ergreifen und jegliche Verarbeitung in
einem Dienst vornehmen.“
Seite 9:
„1. Entscheiden Sie, welchen von Google bereitgestellten GCMVerbindungsserver Sie verwenden wollen - HTTP oder XMPP (CCS).
Die GCM-Verbindungsserver nehmen Nachrichten von einem
Drittanbieter-Anwendungsserver (von Ihnen festgelegt) entgegen und
senden sie zu einer GCM-aktivierten Android-App (die "Client App",
auch von Ihnen festgelegt), die auf dem Gerät läuft.
2.
Implementieren Sie einen Anwendungsserver (den "Drittanbieter-Anwendungsserver"), um mit Ihrem gewählten GCM-Verbindungsserver
zu interagieren. Der Anwendungsserver sendet Daten zu einer GCMaktivierten Android Client App über den GCM-Verbindungsserver.
Für weitere Informationen zur Implementierung der Server-Seite
siehe Implementieren GCM Server.
3.
Schreiben Sie Ihre Client App. Dies ist die GCM-aktivierte AndroidApp, die auf einem Gerät läuft. Siehe Implementieren GCM Client für
weitere Informationen.“
Seite 23:
„Die Server-Seite von GCM besteht aus 2 Komponenten:
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
•
Seite A-41
Von Google bereitgestellte GCM-Verbindungsserver nehmen Nachrichten von einem Drittanbieter-Anwendungsserver entgegen und
senden sie zu einer GCM-aktivierten Android-App (die "Client App"),
die auf einem Gerät läuft. Beispielsweise stellt Google Verbindungsserver für HTTP und CCS (XMPP) bereit.
•
Drittanbieter-Anwendungsserver, den Sie implementieren müssen.
Dieser Anwendungsserver sendet Daten zu einer GCM-aktivierten
Android-App über den ausgewählten GCM-Verbindungsserver.“
Seite 24:
„Hier ist die Abfolge der Ereignisse, die auftritt, wenn der DrittanbieterAnwendungsserver eine Nachricht sendet:
1.
Der Anwendungsserver sendet eine Nachricht zu GCM-Servern.
2.
Google reiht die Nachrichten in die Warteschleife ein und speichert
sie ab, falls das Gerät offline ist.
3.
Wenn das Gerät online ist, sendet Google die Nachricht an das Gerät.
4.
Auf dem Gerät überträgt das System die Nachricht an die angegebene
Android-App über Intent broadcast mit korrekten Berechtigungen, so
dass nur die gezielte Android-App die Nachricht bekommt. Dies weckt
die Android-App. Die Android-App braucht nicht vorher zu laufen,
um die Nachricht zu empfangen.
5.
Die Android-App verarbeitet die Nachricht.“
Seite 29:
„Der GCM Cloud Verbindungsserver (CCS) ist ein Server auf Basis
von XMPP. CCS ermöglicht Drittanbieter-Anwendungsservern (bei
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-42
denen Sie für die Implementierung zuständig sind), mit Android-Geräten durch Aufbau einer anhaltenden TCP-Verbindung mit GoogleServern zu kommunizieren, die das XMPP-Protokoll verwenden.
Diese Kommunikation ist asynchron und bidirektional.“
Seite 45:
„Verbindungsserver sind von Google bereitgestellte Server, die
Nachrichten von Drittanbieter-Anwendungsservern entgegennehmen
und zu dem Gerät senden.“
A70. Der Kanal ist ein Schmalbandkanal im Sinne von Merkmal 1, da die Übertragungsrate für Daten, welche vom Server an die Android-Anwendung auf dem AndroidMobiltelefon gesendet werden, durch den in den GCM-Servern der Beklagten zu 1
enthaltenen Drosselungsmechanismus reduziert werden. Details zu dem Drosselungsmechanismus ergeben sich aus dem Anlagenkonvolut EIP A11 (auf Seite 61)
und sind oben bereits ausführlich beschrieben worden.
A71. Um zu verdeutlichen, wie der Drosselungsmechanismus die Datenübertragungsrate
zwischen Server und Klient reduziert, fügen wir als
Anlage EIP A13
den Ausdruck einer Webseite (https://www.logintc.com/blog/2013-02-08-performance-analysis-of-mobile-push-notification-networks.html) bei, auf welcher die
Auswirkung einer GCM-Drosselung auf die Zeit dargestellt wird, die benötigt wird,
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-43
um eine Mitteilung von einem bestimmten Server an ein bestimmtes Mobiltelefon
zu senden. Die relevante Passage lautet übersetzt wie folgt:
„Die Android-Plattform hat unsere Mitteilungen gedrosselt, als wir
mehr als einmal alle 180 Sekunden das Gerät per Push beanspruchten. Gemäß Android GCM-Unterlagen (http://developer.android.eom/google/gcm/adv.html#throttling)
werden
Push-
Mitteilungen auf dasselbe Gerät gedrosselt, indem das Token Bucket
(http://en.wikipedia.org/wiki/Token_bucket)
Schema
verwendet
wird. Wir haben das verstanden und unsere Daten zeigen, dass der
Eimer 20 Tokens fasst und mit einer Rate von einmal alle 180 Sekunden aufgefüllt wird. Darüber hinaus scheint der Eimer alle 0 bis
90 Minuten vollständig (willkürlich) aufgefüllt zu werden. Wenn der
Eimer keine Tokens mehr hat, werden Push-Mitteilungen verworfen,
statt in die Warteschleife zu gelangen.“
A72. Wir verweisen insofern auch auf das Anlagenkonvolut EIP A12 (wie oben bereits
zitiert) und die Nutzung des „Token Bucket Algorithmus‘“ als Verfahren zur Kontrolle der Bandbreite.
Anspruchsmerkmal 2:
Der Klient und der Server sind nicht nur durch den
Schmalbandkanal verbindbar, sondern auch durch
einen Breitbandkanal.
Anspruchsmerkmal 3:
Der Klient und der Server werden über den Breitbandkanal verbunden.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-44
A73. Der Breitbandkanal im Sinne dieses Merkmals ist der Kanal, über welchen die Android-Anwendung auf dem Android-Mobiltelefon die Registrierungs-ID an den verbundenen Anwendungsserver sendet. Die Beklagte zu 1 beschreibt diesen Prozess
im Anlagenkonvolut EIP A11, so beispielsweise auf Seite 4:
„Registrierungs-ID
Eine ID, die von den GCM-Servern an die Android-Anwendung vergeben wird, und dieser erlaubt Nachrichten zu empfangen. Sobald
die Android-Anwendung die Registrierungs-ID erhalten hat, sendet
sie diese an den Drittanbieter-Anwendungsserver, welcher diese
nutzt, um jedes Gerät zu identifizieren, welches sich registriert hat,
um Mitteilungen für eine bestimmte Android-Anwendung zu empfangen. Anders ausgedrückt ist die Registrierungs-ID an eine bestimmte Android-Anwendung gebunden, die sich auf einem
bestimmten Gerät befindet.“
Siehe ebenfalls Seiten 14 bis 17 des Anlagenkonvoluts EIP A11a, insbesondere
Seite 16:
„// Sie sollten die Registrierungs-ID über HTTP zu Ihrem Server
// senden, damit er GCM/HTTP oder CCS verwenden kann, um
// Nachrichten zu Ihrer App zu senden. Die Anfrage an Ihren
// Server sollte authentifiziert werden, wenn Ihre App Accounts
// verwendet.
sendRegistrationIdToBackend();
//
//
//
//
Bei dieser Demo: Wir brauchen sie nicht zu senden, weil das
Gerät Upstream-Nachrichten zu einem Server sendet, der die
Nachricht unter Verwendung der 'from' Adresse in der Nachricht
zurückwirft.
// Persist the regID - erneute Registrierung nicht erforderlich.
storeRegistrationId(context, regid);
) catch (IOException ex) (
msg "Error” : " ex . getMessage () ;
// Falls ein Fehler besteht, versuchen Sie nicht weiter, sich zu
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
//
//
//
//
Seite A-45
registrieren.
Fordern Sie den Nutzer auf, eine Schaltfläche erneut
anzuklicken oder gehen sie zu
exponential back-off.“
A74. Dieser Kanal ist ein Breitbandkanal im Sinne des Merkmals 2 des Klagepatents A,
da er nicht über den GCM-Server läuft und nicht dem dort angewandten Drosselungsprozess der Beklagten zu 1 ausgesetzt ist. Die Bandbreite dieses Kanals ist größer als die des Kanals, über welchen die GCM-Mitteilung/-Datei gesendet wird.
A75. Der Klient und der Server (Mobiltelefon und der verbundene Anwendungsserver)
sind zusätzlich zu dem Schmalbandkanal notwendig über einen Breitbandkanal verbunden, so dass die Registrierungs-ID vom Klienten-Mobiltelefon an den Anwendungsserver gesendet werden kann. Dieser allgemeine Prozess wird in folgender
Grafik dargestellt:
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 4:
Seite A-46
Es werden Sicherheitsinformationen zwischen dem
Klienten und dem Server über den Breitbandkanal
ausgetauscht.
A76. Die Sicherheitsinformation im Sinne dieses Merkmals ist die Registrierungs-ID.
Hierbei handelt es sich um eine Sicherheitsinformation, da diese ermöglicht, dass die
Mitteilung/Benachrichtigung authentifiziert werden kann. Ohne eine gültige Registrierungs-ID kann die Mitteilung/Benachrichtigung den GCM-Server samt Schmalband-Kanal zum Android-Mobiltelefon nicht passieren.
A77. Dies ergibt sich aus den Seiten 3 und 62 des Anlagenkonvoluts EIP A11 bzw. A11a,
von welchen auch die folgenden Passagen stammen:
„Die IDs und Tokens, die in unterschiedlichen Stadien von GCM
verwendet werden, um sicherzustellen, dass alle Beteiligten authentifiziert wurden, und dass die Nachricht an die richtige Stelle gelangt.“
(Seite 3 des Anlagenkonvoluts EIP A11 und EIP A11a)
„Eine App kann automatisch deregistriert werden, nachdem sie von dem
Gerät deinstalliert wurde.
Jedoch geschieht dieser Prozess nicht sofort, dAndroid keinen Deinstallations-Rückruf bereitstellt. Was bei diesem Prozess geschieht, ist Folgendes:
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-47
1.
Der Endnutzer deinstalliert die App.
2.
Der Drittanbieter-Server sendet eine Nachricht an den GCM-Server.
3.
Der GCM-Server sendet die Nachricht an das Gerät.
4.
Der GCM-Client empfängt die Nachricht und fragt den Package-Manager darüber ab, ob es Funkempfänger gibt, die zu deren Empfang
konfiguriert sind, der false zurücksendet.
5.
Der GCM-Client informiert den GCM-Server darüber, dass die App
deinstalliert wurde.
6.
Der GCM-Server markiert die Registrierungs-ID zum Löschen.
7.
Der Drittanbieter-Server sendet eine Nachricht an GCM.
8.
GCM sendet eine NotRegistered Fehlermeldungen an den Drittanbieter-Server zurück.
9.
Der Drittanbieter löscht die Registrierungs-ID.
| Hinweis: Der GCM-Client ist das Google Cloud Messaging - Framework, das auf dem Gerät vorhanden ist.“
(Hervorhebungen durch Unterzeichner)
(Seite 62 des Anlagenkonvoluts EIP A11 und EIP A11a)
A78. Wie bereits im Zusammenhang mit den Merkmalen 2 und 3 oben ausgeführt, wird
die Registrierungs-ID (die Sicherheitsinformation) von der Android-Anwendung auf
dem Android-Gerät an den verbundenen Server über eine normale HTTPVerbindung (beispielsweise über einen Kanal, der nicht dem Drosselungsmechanis-
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-48
mus der Beklagten zu 1 unterworfen ist) gesendet. Als solche wird die Registrierungs-ID (Sicherheitsinformation) zwischen dem Klienten und dem Server über einen Breitbandkanal ausgetauscht.
A79. Seite 4 des Anlagenkonvoluts EIP A11/A11a enthält auch eine Definition der Registrierungs-ID:
Registrierungs- ID
Eine ID, die von den GCM-Servern an die Android-Anwendung vergeben wird, und dieser erlaubt Nachrichten zu empfangen. Sobald die Android-Anwendung die Registrierungs-ID erhalten hat, sendet sie
diese an den Drittanbieter-Anwendungsserver, welcher diese nutzt, um jedes Gerät zu identifizieren, welches sich registriert hat, um Mitteilungen für eine bestimmte Android-Anwendung zu empfangen. Anders
ausgedrückt ist die Registrierungs-ID an eine bestimmte Android-Anwendung gebunden, die sich auf einem bestimmten Gerät befindet.
A80. Die Registrierungs-ID wird zur Identifizierung eines Geräts genutzt und ist damit
eine Sicherheitsinformation im Sinne des Patentanspruchs.
Anspruchsmerkmal 5:
Die vom Server zum Klienten zu übertragenden Daten werden basierend auf der Sicherheitsinformation
signiert.
A81. Bei den vom Server an den Klienten zu übertragenden Daten, handelt es sich um eine
Mitteilung, welche die Beklagte zu 1 als „Payload“ bezeichnet. Diese Daten können
ebenfalls aus einem „ping“ bestehen, der dazu dient, dass sich die Empfängeranwendung mit dem Server verbindet. Dies ergibt sich beispielsweise aus den Seiten 1 und
63 bis 64 des Anlagenkonvoluts EIP A11. Im Folgenden werden Auszüge der Seite
1 zitiert. Die Seiten 63 bis 64 enthalten weitere, detailliertere Informationen.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-49
„Versenden von Daten von Ihrem Server zu Android-gestützten Nutzer-Geräten
Dabei kann es sich um eine einfache Nachricht handeln, die Ihrer
App mitteilt, dass neue Daten zur Übertragung vom Server bereitliegen (beispielsweise ein Film, der von einem Freund hochgeladen
wurde), oder es kann sich um eine Nachricht mit bis zu 4 KB Nutzdaten handeln (so können Apps wie Instant Messaging die Nachricht
direkt verarbeiten).“
(Seite 1 des Anlagenkonvoluts EIP A11 und EIP A11a)
„Versenden von "send-to-Sync"-Nachrichten
Eine Send-to-sync-Nachricht (collapsible) ist oft eine Art "Kribbeln", womit einer mobilen Anwendung mitgeteilt wird, Daten von
dem Server zu synchronisieren. Es sei beispielsweise angenommen,
Sie haben eine E-Mail-Anwendung. Wenn ein Nutzer eine neue EMail auf dem Server empfängt, versieht der Server die mobile Anwendung mit einer "Neue E-Mail"-Meldung. Dadurch wird der Anwendung mitgeteilt, sich mit dem Server zu synchronisieren, um die
neue E-Mail abzurufen.“
(Seite 1 des Anlagenkonvoluts EIP A11 und EIP A11a)
„Versenden von Nachrichten mit Nutzdaten
Im Gegensatz zu einer Send-to-sync-Nachricht wird jede "Nachricht
mit Nutzdaten" (non-collapsible) zugestellt. Die Nutzdaten, die die
Nachricht enthält, können bis zu 4 KB betragen.“
(Seite 1 des Anlagenkonvoluts EIP A11 und EIP A11a)
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-50
A82. Wenn der Server (Anwendungsserver) eine Mitteilung/Benachrichtigung an die verbundene Anwendung auf dem Benutzergerät (Android-Mobiltelefon) senden
möchte, muss er gleichzeitig die Registrierungs-ID mitschicken, die er von diesem
Gerät über den Breitbandkanal zusammen mit der Mitteilung/Benachrichtigung erhalten hat. Hierzu wird beispielsweise auf den Seiten 4, 24, 25 und 62 des Anlagenkonvoluts EIP A11 folgendes erläutert:
Registrierungs- ID
Eine ID, die von den GCM-Servern an die Android-Anwendung vergeben wird, und dieser erlaubt Nachrichten zu empfangen. Sobald die Android-Anwendung die Registrierungs-ID erhalten hat, sendet sie
diese an den Drittanbieter-Anwendungsserver, welcher diese nutzt, um jedes Gerät zu identifizieren, welches sich registriert hat, um Mitteilungen für eine bestimmte Android-Anwendung zu empfangen. Anders
ausgedrückt ist die Registrierungs-ID an eine bestimmte Android-Anwendung gebunden, die sich auf einem bestimmten Gerät befindet.
(Seite 4 des Anlagenkonvoluts EIP A11 und EIP A11a)
A83. Dort wo der GCM-Verbindungs-Server eine HTTP-Verbindung nutzt, und die Mitteilung in Form einer JSON-Mitteilung ist, muss die Registrierungs-ID im „Registration_ids“-Feld enthalten sein.
registration_ids
Ein String-Array mit der Liste der Geräte (Registrierungs- IDs), die die
Nachricht empfangen. Es muss mindestens 1 und höchstens 1000 Registrierungs-IDs enthalten. Um eine Multicast-Nachricht zu senden, müssen Sie
JSON verwenden. Um eine einzelne Nachricht zu einem einzelnen Gerät zu
senden, kann man ein JSON-Objekt mit nur einer Registrierungs-ID oder
Klartext (siehe unten) verwenden. Eine Anforderung muss einen Empfänger
enthalten - dies kann entweder eine Registrierungs-ID, eine Reihe von Registrierungs-IDs oder ein notification_key sein. Erforderlich.
(Seite 25 des Anlagenkonvoluts EIP A11 und EIP A11a)
HTTP
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-51
A84. Dort wo der GCM-Verbindungs-Server eine HTTP-Verbindung nutzt und die Mitteilung von der Art her eine reine Textnachricht ist, muss die Registrierungs-ID im
Feld “Registration_id” enthalten sein.
registration_id
Muss die Registrierungs-ID von dem einzelnen Gerät enthalten, das die Nachricht empfängt. Erforderlich.
(Seite 26 des Anlagenkonvoluts EIP A11 und EIP A11a)
A85. Wie bereits in Bezug auf das auf Seite 62 des Anlagenkonvoluts EIP A11 beschriebene unregistrierte Verfahren dargestellt, wird dem GCM-Server ohne eine wirksame Registrierungs-ID nicht gestattet, Mitteilungen an das Gerät zu übermitteln.
A86. Auf Grundlage der obigen Ausführungen sind die zu übertragenden Daten im Sinne
des Merkmals die Mitteilungen/Benachrichtigungen, und weil die Registrierungs-ID
gleichzeitig mit der Mitteilung/Benachrichtigung zu senden ist, werden diese Daten
auch im Sinne des Anspruchsmerkmals basierend auf der Sicherheitsinformation signiert.
Anspruchsmerkmal 6:
Die signierten Daten werden vom Server zum Klienten über den Schmalbandkanal übertragen.
Wie bereits im Anlagenkonvolut EIP A11 erläutert, wird die Mitteilung/Benachrichtigung samt der Registrierungs-ID vom Server an den Klienten, nämlich vom
Anwenderserver über das Serversystem an das auf Android basierende Betriebssystem gesendet, das von der Beklagten zu 1 bereitgestellt wird. Die signierten Daten
werden insofern vom Server zum Klienten über einen Schmalbandkanal übermittelt.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 7:
Seite A-52
Wenigstens ein Teil des Schmalbandkanals und des
Breitbandkanals ist drahtlos.
A87. Aus den obigen Ausführungen ergibt sich bereits, dass der Schmalbandkanal und der
Breitbandkanal beide zu dem Mobiltelefon führen. Dass diese Kommunikationsverbindungen teilweise drahtlos im Sinne des Anspruchs sind, wird von der Beklagten
sicherlich nicht bestritten werden.
2.3
Verletzung von Anspruch 7 des Klagepatents A durch GCM
Anspruchsmerkmal 1:
Funkvorrichtung, die ein Netzwerk von Computern
über eine drahtlose Verbindung verbinden kann.
A88. Die englische Fassung des Anspruchs spricht von einem „mobile device capable of
connecting to a network of computers“, d.h. von einem mobilen Gerät, das sich mit
einem Netzwerk von Computern verbinden kann. Die deutsche Übersetzung ist diesbezüglich nur ein wenig missglückt, was am Schutzbereich des Anspruchs 7, der
beispielsweise ein Mobiltelefon oder ein Tablet umfasst, das sich über eine drahtlose
Verbindung mit dem Internet verbinden lässt, nichts ändert.
A89. Google-Mobiltelefone mit dem Android-Betriebssystem sind solche Funkvorrichtungen im Sinne des Anspruchs.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 2:
Seite A-53
Die Funkvorrichtung weist einen Anzeigebildschirm
auf, der Grafiken und Text anzeigt.
A90. Ein derartiger Bildschirm ist bei den verletzenden Ausführungsformen fraglos vorhanden.
Anspruchsmerkmal 3:
Die Funkverbindung enthält einen Nachrichtenpuffer, der eine Nachricht von einem Computer am Netzwerk von Computern temporär speichert, wobei
A91. Alle Google Android Mobiltelefone sind mit Speicherungsmechanismen ausgestattet, die – neben vielen anderen Daten – die hier interessierenden Notifizierungen
temporär speichern.
Anspruchsmerkmal 3.1:
die Nachricht ein damit verbundenes Dienstkennzeichen hat.
A92. Die Mitteilung (Push-Notification) ist für eine bestimmte Anwendung auf dem Mobiltelefon gedacht und wird von dieser Anwendung, und zwar nur von dieser Anwendung, empfangen. Aus diesem Grund muss es einen mit dieser Mitteilung
verbundenen Service Identifier (Dienstkennzeichen) geben, so dass diese entsprechend empfangen und genutzt werden kann.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 4:
Seite A-54
Die Funkvorrichtung weist eine Anwendung auf, die
die vom Computer am Netzwerk von Computern empfangene Nachricht verwendet.
A93. Die App bzw. Anwendung auf dem Google Android Mobiltelefon, für welche die
Notifizierung gedacht ist, nutzt die Notifizierung beispielsweise dafür, um den Besitzer des Mobiltelefons darauf hinzuweisen, dass neue Daten für diese Anwendung
verfügbar sind, so dass das Merkmal erfüllt ist.
A94. In diesem Zusammenhang wird auf Seite 1 des Anlagenkonvoluts EIP A11 folgendes ausgeführt:
„Google Cloud Messaging für Android (GCM) ist ein Dienst, mit dem
Sie Daten von Ihrem Server zu Ihrem Android-gestützten Nutzer-Gerät senden können und auch Nachrichten von Geräten auf der gleichen Verbindung empfangen können. Der GCM-Dienst befasst sich
mit sämtlichen Aspekten bei der Bildung einer Warteschleife von
Nachrichten und Lieferung zur Android-Zielanwendung, die auf dem
Zielgerät läuft. GCM ist völlig kostenlos, ganz egal, wie groß Ihr Messaging-Bedarf ist, und es gibt keine Kontingente.
(…)
Versenden von Daten von Ihrem Server zu Android-gestützten Nutzer-Geräten
Dabei kann es sich um eine einfache Nachricht handeln, die Ihrer App
mitteilt, dass neue Daten zur Übertragung vom Server bereitliegen
(beispielsweise ein Film, der von einem Freund hochgeladen wurde),
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-55
oder es kann sich um eine Nachricht mit bis zu 4 KB Nutzdaten handeln (so können Apps wie Instant Messaging die Nachricht direkt verarbeiten).
Versenden von "send-to-Sync"-Nachrichten
Eine Send-to-sync-Nachricht (collapsible) ist oft eine Art "Kribbeln",
womit einer mobilen Anwendung mitgeteilt wird, Daten von dem Server zu synchronisieren. Es sei beispielsweise angenommen, Sie haben
eine E-Mail-Anwendung. Wenn ein Nutzer eine neue E-Mail auf dem
Server empfängt, versieht der Server die mobile Anwendung mit einer
"Neue E-Mail"-Meldung. Dadurch wird der Anwendung mitgeteilt,
sich mit dem Server zu synchronisieren, um die neue E-Mail abzurufen.
Anspruchsmerkmal 5:
Es ist eine kryptografische Steuerung vorgesehen, die
A95. Wir legen als
Anlage EIP A14
einen Ausdruck der Webseite „Security Tips (Sicherheits-Tips)“ der Android.comWebseite vor. Eine deutsche Übersetzung der relevanten Passagen legen wir als
Anlage EIP A14a
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-56
vor.
A96. Von besonderem Interesse sind:
(a) der Abschnitt mit dem Titel „ Verwenden von IP-Netzwerken“ („Using IP Networking“) auf Seite 4, wo es heißt:
„Netzwerken auf Android unterscheidet sich nicht wesentlich von
Linux-Umgebungen. Die Hauptüberlegung ist, sicherzustellen, dass
geeignete Protokolle für sensible Daten verwendet werden, wie etwa
HttpsURLConnection (/reference/javax/net/asl/HttpsURLConnection.html) für den sicheren Web-Datenverkehr. Wir bevorzugen die
Verwendung von HTTPS gegenüber HTTP überall dort, wo HTTPS
auf dem Server unterstützt wird, weil mobile Geräte sich häufig mit
Netzwerken verbinden, die nicht gesichert sind, wie etwa mit öffentlichen W-LAN Hotspots.
Authentifizierte, verschlüsselte Socket-Level-Kommunikation kann
leicht implementiert werden unter Verwendung der SSLSocket (/reference/javax/net/ssl/SSLSocket. html) Klasse. Angesichts der Häufigkeit,
mit
welcher
Android-Geräte
eine
Verbindung
zu
ungesicherten WLAN- Netzwerken mit Wi-Fi herstellen, wird die
Verwendung von sicheren Netzwerken für sämtliche Anwendungen
stark angeraten, die über das Netzwerk kommunizieren.“
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-57
(b) der Abschnitt mit dem Titel „Verwendung von Kryptographie“ („Using Cryptography“) auf den Seiten 7 und 8, wo es heißt:
„Neben der Bereitstellung von Daten-Isolation, Unterstützung der
vollen Dateisystem-Verschlüsselung und der sicheren Bereitstellung
von Kommunikationskanälen bietet Android eine breite Palette von
Algorithmen für den Schutz von Daten unter Verwendung von Kryptographie.
Versuchen Sie generell, die höchste Stufe der bereits bestehenden
Framework-Implementierung zu nutzen, die Ihr Anwendungsfall unterstützen kann. Wenn Sie eine Datei sicher von einem bekannten
Ort abrufen müssen, kann eine einfache HTTPS-URI angemessen
sein und erfordert keine Kenntnisse der Kryptographie. Wenn Sie
eine sichere Verbindung brauchen, gehen Sie auf HttpsURLConnection oder SSLSocket, anstatt Ihr eigenes Protokoll zu schreiben.“
A97. Wir reichen als
Anlage EIP A15
zudem einen Ausdruck des Abschnitts „Vorbereiten der Freigabe“ („Preparing for
Release“) der Android.com-Webseite auf http://developer.android.com/tools/publishing/preparing.html ein. Eine deutsche Übersetzung der relevanten Passagen hieraus fügen wir ebenfalls bei als
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-58
Anlage EIP A15a
A98. Insbesondere verweisen wir auf den zweiten Abschnitt mit der Überschrift „Vorbereiten von externen Servern und Ressourcen“ („Preparing External Servers and Resources“) auf Seite 5, wo es heißt:
„Wenn Ihre App auf einen Remote-Server gestützt ist, vergewissern
Sie sich, dass der Server sicher ist…“
A99. Um den Sicherheitsanforderungen der Beklagten zu 1 gerecht zu werden, muss bei
der Entwicklung der Anwendungen das Vorhandensein einer kryptografischen Steuerung beachtet werden. Diese ist bei den verletzenden Ausführungsformen damit im
Betriebssystem enthalten.
Anspruchsmerkmal 5.1:
eine Verschlüsselung oder Signatur von abgehenden
Nachrichten steuert und
Eine kryptografische Steuerung ist in der Lage, die Verschlüsselung oder Signatur
einer ausgehenden Nachricht zu kontrollieren.
Anspruchsmerkmal 5.2:
die Entschlüsselung oder Autentifizierung von ankommenden Nachrichten steuert.
Eine kryptografische Steuerung ist in der Lage, die Entschlüsselung oder Authentifizierung von eingehenden Nachrichten vorzunehmen.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 5.3:
Seite A-59
Die kryptografische Steuerung arbeitet, um eine sichere Verbindung, über die sie die ankommenden
Nachrichten empfängt, durch Verwenden eines Einwegkanals aufzubauen.
A100. Wie bereits oben ausgeführt, ist die Verbindung zwischen dem Mobiltelefon (Klient)
und dem GCM-Server, über welchen die „Leichtgewicht-Mitteilungen“/Push Notifications empfangen werden, eine SSL (gesicherte und verschlüsselte) Verbindung,
die die Verwendung einer kryptografischen Steuerung zum Aufbau dieser Verbindung voraussetzt. Die Beklagten werden diesen Umstand sicherlich nicht bestreiten.
A101. Darüber hinaus wird die kryptografische Steuerung auf dem Gerät in Übereinstimmung mit der oben genannten Leitlinie bezüglich der Anwendung von HTTPSVerbindungen (Seite 4, 7 und 8 der Anlage EIP A 14) zwischen dem Klienten und
dem Server über einen nicht-GCM-Kanal (den Breitband-Kanal in Übereinstimmung
mit unseren Ausführungen bezüglich des Anspruchs 6), zusätzlich einen EinwegKanal herstellen, über welchen die eingehenden Nachrichten empfangen werden
können. Hierfür muss sie zunächst einen Zweiwege-Kanal herstellen, über den die
Sicherheitsinformationen gesendet werden können, damit ein sicherer Einweg-Kanal
aufgebaut werden kann.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 5.4:
Seite A-60
Dabei wird ein dazugehöriger Zweiwegekanal verwendet, um Sicherheitsinformationen auszutauschen, die zum Aufbauen der sicheren Verbindung
über den Einwegkanal nötig ist.
A102. Im Einklang mit unseren im Abschnitt 2 gegebenen Erläuterungen in Bezug auf das
Klagepatent A und mit Verweis auf unseren Vortrag bezüglich des Patentanspruchs
6 weisen wir nochmals darauf hin, dass der Schmalbandkanal des Anspruchs 6 (der
Kanal, der über den GCM-Server führt) im Allgemeinen ein Einweg-Kanal im Sinne
des Anspruchs 7 ist.
A103. Mit Verweis auf unseren Vortrag im Zusammenhang mit Anspruch 6 weisen wir
darüber hinaus erneut darauf hin, dass der Breitband-Kanal im Anspruch 6 (der Kanal, der nicht über den GCM-Server läuft), im Allgemeinen ein Zweiwege-Kanal im
Sinne des Anspruchs 7 ist.
A104. Wie ferner im Zusammenhang mit dem Anspruch 6 erläutert wird die Sicherheitsinformation über den Zweiwege-Kanal gesendet, um einen sicheren Einweg-Kanal
herzustellen.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
3.
Seite A-61
Benutzung der Lehre des Klagepatents A – „Google Cloud to Device Messaging
Service („C2DM“)“
A105. Der GCM-Dienst, wie er oben beschrieben wird, ist der Nachfolger des sogenannten
„Cloud to Device Messaging“-Dienstes, welcher ebenfalls von der Beklagten zu 1
entwickelt wurde und derzeit auch noch bereitgestellt wird.
A106. Wir reichen als
Anlage EIP A 16
ein von der Beklagten zu 1 unter dem Titel „Android Cloud to Device Messaging
Framework“ veröffentlichtes Dokument ein. Eine deutsche Übersetzung der relevanten Passagen fügen wir als
Anlage EIP A16a
bei.
A107. Wie sich aus Seite 1 oben der Anlage EIP A16a und dem unten folgenden Zitat
ergibt, wurde der C2DM-Dienst am 26. Juni 2012 vom GCM-Dienst abgelöst. Obwohl der C2DM-Dienst nach diesem Datum von keinem neuen Anwender mehr genutzt werden kann, nutzen Anwendungen, die bereits vor diesem Datum existierten,
dieses Verfahren und werden es auch weiterhin nutzen. Damit existieren beide
Dienste bis auf weiteres nebeneinander.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-62
„C2DM ist seit dem 26. Juni 2012 offiziell veraltet. Das bedeutet,
dass C2DM aufgehört hat, neue Nutzer und Kontingentanfragen anzunehmen. Es werden keine neuen Funktionen zu C2DM hinzugefügt. Jedoch funktionieren weiterhin Apps, die C2DM verwenden.
Bestehenden C2DM-Entwicklern wird dringend nahegelegt, zur
neuen Version von C2DM, Google Cloud Messaging for Android
(GCM) genannt, zu wechseln. Siehe das Schriftstück, C2DM zu
GCM Migration für weitere Informationen.“
A108. Der Abschnitt „Migration“ des Anlagenkonvoluts EIP A11 (Seite 67 bis 69) beinhaltet eine Darstellung der Unterschiede dieser beiden Dienste. In Bezug auf die Anwendung der Merkmale des Patents sind diese Unterschiede jedoch unerheblich, da
der GCM-Dienst lediglich eine verbesserte Version des früheren C2DM-Dienstes ist.
A109. Nachfolgend haben wir eine Merkmalsanalyse in Bezug auf die Verletzung der Ansprüche 6 und 7 des Klagepatents A durch den C2DM-Dienst, und Mobiltelefone,
die Verbindungen mit diesem Dienst nutzen, vorgenommen.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
3.1
Seite A-63
Verletzung des Anspruchs 6
Anspruchsmerkmal 1:
Verfahren zum sicheren Übertragen von Daten zwischen einem Klienten und einem Server über einen
Schmalbandkanal.
A110. Das Verfahren ist das in Anlage EIP A16 beschriebene, nämlich das „Android Cloud
to Device Messaging Framework“-Verfahren (oder auch „C2DM“). Hierbei handelt
es sich um einen Dienst, der von Google zur Nutzung für Anwendungen angeboten
wird, die auf Mobiltelefonen mit Android-Betriebssystem installiert sind.
A111. Ein Überblick über den C2DM-Dienst geben die folgenden Auszüge der Seite 1 der
Anlage EIP A16:
„Android Cloud to Device Messaging (C2DM) ist ein Dienst, mit
dem Entwicklern beim Versenden von Daten von Servern zu Ihren
Apps auf Android-Geräten geholfen wird. Der Dienst stellt ein einfaches, leichtes Mittel bereit, den Server nutzen können, um mobilen
Anwendungen mitzuteilen, den Server direkt zu kontaktieren, um aktualisierte Anwendungen oder Nuterdatzen abzurufen. Der C2DMDienst befasst sich mit sämtlichen Aspekten der Bildung einer Warteschleife von Nachrichten und Zustellung zur Zielanwendung, die
auf dem Zielgerät läuft.“
„Es ermöglicht Drittanbieter-Anwendungsservern, einfache Nachrichten zu deren Android-Anwendungen zu senden. Der Benachrichtigungsdienst ist nicht zum Senden einer Menge Nutzerinhalt über
die Nachrichten ausgelegt, sondern sollte vielmehr dazu genutzt
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-64
werden, der Anwendung mitzuteilen, dass neue Daten auf dem Server bereitliegen, so dass die Anwendung sie abrufen kann.“
A112. Die einzelnen Komponenten, welche für den C2DM-Dienst genutzt werden, werden
auf Seite 1 der Anlagen EIP A16 und EIP A16a aufgeführt, nämlich:
„Mobiles Gerät – Das Gerät, auf dem eine Android-App läuft, die
C2DM verwendet. Dabei muss es sich um ein 2.2 Android-Gerät
handeln, das Market installiert hat, und es muss mindestens ein angemeldetes Google-Account haben.“
„Drittanbieter-Anwendungsserver – Ein Anwendungsserver, den
Entwickler als Teil der C2DM-Implementierung in ihren Apps aufzeichnen. Der Drittanbieter-Anwendungsserver sendet über den
C2DM-Server Daten an eine Android App auf dem Gerät.“
„C2DM-Server – Google-Server, die Nachrichten von dem Drittanbieter-Anwendungsserver entgegennehmen und diese zu dem Gerät
senden.“
A113. Der „Drittanbieter-Anwendungsserver“ („third-party application server“) ist der Server und das „Mobile Gerät“ („mobile device”) ist der Klient im Sinne des Merkmals
1.
A114. Die Daten werden (in Form einer einfachen Nachricht – „lightweight message“ –
oder Push Notification) von einem Server (Drittanbieter-Anwendungsserver – thirdparty application server) an den Klienten (Mobiltelefon) über den C2DM Dienst
übertragen. Diesbezüglich beschreibt Google auf Seite 6 der Anlage EIP A16 die
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-65
Struktur dieser einfachen Nachricht („lightweight message“) / Push Notification, die
vom Server über einen Schmalband (C2DM)-Kanal an den Klienten gesandt wird:
Feld
Beschreibung
registration_id
Die Registrierungs-ID, die von der Android-App auf das Gerät abgerufen
wurde. Erforderlich.
collapse_key
Eine beliebige Zeichenfolge, die verwendet wird, um eine Gruppe ähnlicher
Nachrichten zu bündeln, wenn das Gerät offline ist, damit nur die letzte
Nachricht an den Client gesendet wird. Damit soll das Versenden von zu
vielen Nachrichten an das Telefon vermieden werden, wenn es wieder online geht. Beachten Sie, dass dadurch, dass keine Garantie für die Reihenfolge besteht, in der Nachrichten versandt werden, womöglich die "letzte"
Nachricht im Grunde nicht die letzte Nachricht sein könnte, die vom Anwendungssender versandt wurde. Erforderlich.
data.<key>
Nutzdaten, ausgedrückt als Schlüssel-Wert-Paare. Falls vorhanden, sind sie
im Intent als Anwendungsdaten mit <key> enthalten. Es besteht keine
Begrenzung der Anzahl von Schlüssel-Wert-Paaren, obgleich eine Begrenzung der Gesamtgröße der Nachricht besteht. Optional.
delay_while_idle
Falls enthalten, wird damit angegeben, dass die Nachricht nicht unmittelbar
versendet werden sollte, falls das Gerät nicht aktiv ist. Der Server wartet darauf, dass das Gerät aktiviert wird, wonach nur die letzte Nachricht für jeden collapse key Wert versendet wird. Optional.
Authorization:
GoogleLogin
auth=[AUTH_TOKEN]
Kopfzeile mit einem ClientLogin Auth Token. Das Cookie muss mit dem
ac2dm Dienst verbunden werden. Erforderlich.
A115. Die „payload-Daten“ sind Daten im Sinne des Merkmals 1.
A116. Die Nutzung des C2DM-Dienstes erfordert die Anwendung zweier Kanäle zwischen
dem Server (Drittanbieter-Anwendungsserver – third-party application server) und
dem Klienten (Mobiltelefon).
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-66
A117. Der erste Kanal ist der, über welchen die lightweight message / Push Notification
vom Server an den Klienten gesendet wird. Das ist der Kanal, der auf Seite 2 der
Anlage EIP A16 unter der Überschrift „Senden einer Nachricht“ beschrieben wird,
und der über den C2DM-Server läuft.
A118. Im Fall des GCM-Dienstes ist der Kanal, welcher über den GCM-Server führt, ein
Schmalbandkanal, da die Übertragungsrate von Daten, welche von einem Server an
eine Android-Anwendung auf einem Android-Mobiltelefon übertragen werden,
durch einen Drosselungsmechanismus reduziert werden, der sich auf den GCMServern der Beklagten zu 1 befindet. Dieser Drosselungsmechanismus auf den
GCM-Servern hat das Zuteilungssystem ersetzt, von welchem im Abschnitt „Migration“ des Anlagenkonvoluts EIP A11 die Rede ist.
A119. Die Zuteilung beim C2DM erlaubt ebenfalls nur das Senden einer begrenzten Anzahl
von Mitteilungen an ein bestimmtes Gerät und führt insofern dazu, dass der Kanal,
welcher über den C2DM-Server führt, ein Schmalbandkanal ist. Diesbezüglich verweisen wir auf Seite 6 des Abschnitts „Beschränkungen“ („Limitations“) der Anlage
EIP A16:
„C2DM gibt folgende Begrenzungen vor:
•
Die Grenze der Nachrichtengröße liegt bei 1024 Bytes.
•
Google begrenzt die Anzahl von Nachrichten, die ein Sender insgesamt versendet, sowie die Anzahl von Nachrichten, die ein Sender an
ein spezifisches Gerät versendet.“
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-67
A120. Der zweite Kanal verbindet den Server (Drittanbieter-Anwendungsserver – third
party application server) und den Klienten (Mobiltelefon) und führt nicht über den
C2DM-Server. Der zweite Kanal ist ein konventioneller Client-Server-Kommunikationskanal. Über diesen Kanal erhält der Server die Sicherheitsinformation, welche
für die Übertragung der Daten über den Schmalbandkanal (und damit zum Sichermachen dieser Daten über den Schmalbandkanal) notwendig sind. Der „Nutzerinhalt“ („user content“), auf welchen in den oben zitierten Auszügen insofern Bezug
genommen wird, als dass dieser von den third-party-Servern durch die Mobiltelefone
„abgeholt“ wird, wird ebenfalls über diesen Kanal übertragen.
A121. Seite 1 der Anlage EIP A16 beschreibt die Berechtigungsnachweise, welche für den
C2DM-Server notwendig sind; diese Berechtigungsnachweise werden beschrieben
als
„Die Identifizierungen und Tokens, die in verschiedenen Phasen des C2DM genutzt
werden, um sicherzustellen, dass die Anwenderparteien authentifiziert sind, und dass
die Mitteilung an den richtigen Ort geht“ (The IDs and tokens that are used in different stages of C2DM to ensure that app parties have been authenticated, and that
the message is going to the correct place).“
(Hervorhebungen durch den Unterzeichner).
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-68
A122. Eine solche ID ist die Registrierungs-ID. Diese wird auf Seite 2 der Anlage EIP A16
folgendermaßen beschrieben:
„Eine ID, die von den C2DM-Servern zur Android-App ausgegeben
wird, die ihr gestattet, Nachrichten zu empfangen. Sobald die App
die Registrierungs-ID hat, sendet sie sie zum Drittanbieter-Anwendungsserver, der sie dazu nutzt, jedes Gerät zu identifizieren, das
zum Empfangen von Nachrichten für eine gegebene App registriert
ist. Mit anderen Worten ist eine Registrierungs-ID an eine bestimmte App gebunden, die auf einem bestimmten Gerät läuft.“
A123. Der Prozess des Generierens dieses Tokens und des Sendens desselben durch den
Klienten (Mobiltelefon) an den Server (Drittanbieter-Anwendungsserver – third
party applications server) wird auf Seite 2 der Anlage EIP A16 unter dem Titel „Aktivieren von C2DM“ („Enabling C2DM“) beschrieben. In Schritt drei dieser Aktivierung wird im Besonderen das Senden der Registrierungs-ID vom Klienten an den
Server beschrieben.
A124. Die Tabelle auf Seite 6 der Anlage EIP A16, in welcher die Bestandteile der lightweight message / Push Notofication dargestellt werden, welche vom Server über den
Schmalbandkanal (C2DM) gesandt werden, zeigt (ebenso wie oben dargestellt), dass
die payload-Daten (Daten) zusammen mit einer Kopie der Registrierungs-ID und
einem Klienten Login Authentifizierungs-Token versandt werden. Dies wird ebenfalls im Abschnitt „Senden einer Nachricht“ („Sending a Message“) auf Seite 2 der
Anlage EIP A16 dargestellt.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-69
A125. Gemäß den Ausführungen auf Seite 2 der Anlage EIP A16 wird der Klient-Token
dafür genutzt, den Anwendungsserver zum Senden einer Mitteilung an eine bestimmte Android-Anwendung zu authentifizieren. Es ist davon auszugehen, dass die
Registrierungs-ID genutzt wird, um eine Mitteilung (Daten), die an einen bestimmten Klienten gesandt werden, zu authentifizieren. Die Registrierungs-ID sichert insofern die Datenübertragung über den Schmalbandkanal im Sinne des
Patentanspruchs.
Anspruchsmerkmal 2:
Der Klient und der Server sind nicht nur durch den
Schmalbandkanal verbindbar, sondern auch durch
einen Breitbandkanal.
A126. Wie im Zusammenhang mit dem Merkmal 1 erläutert, können Klient und Server
durch zwei Kanäle verbunden werden.
A127. Der erste Kanal ist der, der über den C2DM-Server läuft und der, wie bei Merkmal
1 erläutert, ein Schmalbandkanal im Sinne des Patents ist.
A128. Der zweite Kanal führt, wie bereits im Rahmen von Merkmal 1 dargestellt, nicht
über einen C2DM-Server. Da er nicht über den C2DM-Server läuft, handelt es sich
um einen Breitbandkanal, der nicht dem Zuteilungssystem der Beklagten zu 1 unterworfen ist. Die Bandbreite dieses Kanals ist größer als die des Kanals, über welchen
die GCM-Mitteilung/Daten gesendet werden.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 3:
Seite A-70
Der Klient und der Server werden über den Breitbandkanal verbunden.
A129. Dass das Mobiltelefon (der Klient im Sinne des Anspruchs) und der „DrittanbieterAnwendungsserver („third-party application server“), d. h. der Server im Sinne des
Anspruchs, über einen Breitbandkanal (wie bei Anspruchsmerkmal 2 definiert) verbunden sind, ergibt sich daraus, dass die Registrierungs-ID, wie bei Merkmal 2 beschrieben, über einen Breitbandkanal an den Drittanbieter-Anwendungsserver
(„third-party application server“) gesendet wird (vgl. Seite 2 und 6 der Anlage EIP
A16).
Anspruchsmerkmal 4:
Es werden Sicherheitsinformationen zwischen dem
Klienten und dem Server über den Breitbandkanal
ausgetauscht.
A130. Die Erfüllung dieses Merkmals ergibt sich daraus, dass die Registrierungs-ID, die
als Sicherheitsinformation im Sinne des Klagepatents zu verstehen ist, über die gemäß Merkmal 3 entstandene Breitbandkanal-Verbindung geschickt wird (vgl. Seite
2 und 6 der Anlage EIP A16).
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 5:
Seite A-71
Die vom Server zum Klienten zu übertragenden Daten werden basierend auf der Sicherheitsinformation
signiert.
A131. Wie bereits bei Merkmal 1 dargestellt, zeigt Seite 8 der Anlage EIP A16 die Bestandteile einer „lightweight message“ / Push Notification, welche von einem Server
an einen Klienten über einen Schmalbandkanal (C2DM) gesandt werden:
Feld
Beschreibung
registration_id
Die Registrierungs-ID, die von der Android-App auf das Gerät abgerufen
wurde. Erforderlich.
collapse_key
Eine beliebige Zeichenfolge, die verwendet wird, um eine Gruppe ähnlicher Nachrichten zu bündeln, wenn das Gerät offline ist, damit nur die
letzte Nachricht an den Client gesendet wird. Damit soll das Versenden
von zu vielen Nachrichten an das Telefon vermieden werden, wenn es
wieder online geht. Beachten Sie, dass dadurch, dass keine Garantie für
die Reihenfolge besteht, in der Nachrichten versandt werden, womöglich
die "letzte" Nachricht im Grunde nicht die letzte Nachricht sein könnte,
die vom Anwendungssender versandt wurde. Erforderlich.
data.<key>
Nutzdaten, ausgedrückt als Schlüssel-Wert-Paare. Falls vorhanden, sind
sie im Intent als Anwendungsdaten mit <key> enthalten. Es besteht
keine Begrenzung der Anzahl von Schlüssel-Wert-Paaren, obgleich eine
Begrenzung der Gesamtgröße der Nachricht besteht. Optional.
delay_while_idle
Falls enthalten, wird damit angegeben, dass die Nachricht nicht unmittelbar versendet werden sollte, falls das Gerät nicht aktiv ist. Der Server wartet darauf, dass das Gerät aktiviert wird, wonach nur die letzte Nachricht
für jeden collapse key Wert versendet wird. Optional.
Authorization:
GoogleLogin
auth=[AUTH_TOKEN]
Kopfzeile mit einem ClientLogin Auth Token. Das Cookie muss mit dem
ac2dm Dienst verbunden werden. Erforderlich.
A132. Wie ebenfalls bereits im Rahmen von Merkmal 1 beschrieben, wird die Registrierungs-ID (Sicherheitsinformation) zusammen mit den „payload-Daten“ (Daten) als
Teil der lightweight message / Push Notification versandt. Auf diese Weise werden
die Daten im Sinne des Merkmals anhand der Sicherheitsinformationen signiert.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 6:
Seite A-72
Die signierten Daten werden vom Server zum Klienten über den Schmalbandkanal übertragen.
A133. Wie schon im Zusammenhang mit Merkmal 1 ausgeführt, wird die „lightweight message“ / Push Notification (umfassend die payload-Daten und die Registrierungs-ID)
von dem „third-party application server“ (Server) an ein Mobiltelefon (Klient) über
einen Kanal gesandt, welcher über einen C2DM-Server (d. h. einen Schmalbandkanal) führt.
Anspruchsmerkmal 7:
Wenigstens ein Teil des Schmalbandkanals und des
Breitbandkanals ist drahtlos.
A134. Aus den obigen Ausführungen ergibt sich bereits, dass der Schmalbandkanal und der
Breitbandkanal beide in dem Mobiltelefon münden.
A135. Dass diese Kommunikationsverbindungen teilweise drahtlos im Sinne des Anspruchs sind, wird von der Beklagten sicherlich nicht bestritten werden.
3.2
Verletzung von Anspruch 7:
Anspruchsmerkmal 1:
Funkvorrichtung, die ein Netzwerk von Computern
über eine drahtlose Verbindung verbinden kann.
Anspruchsmerkmal 2:
Die Funkvorrichtung weist einen Anzeigebildschirm
auf, der Grafiken und Text anzeigt.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Anspruchsmerkmal 3:
Seite A-73
Die Funkverbindung enthält einen Nachrichtenpuffer, der eine Nachricht von einem Computer am Netzwerk von Computern temporär speichert, wobei
Anspruchsmerkmal 3.1:
die Nachricht ein damit verbundenes Dienstkennzeichen hat.
A136. Bezüglich dieser Merkmale verweisen wir auf unsere obigen Ausführungen zur Verletzung des Anspruchs 7 des Klagepatents A durch den GCM-Dienst.
Anspruchsmerkmal 4:
Die Funkvorrichtung weist eine Anwendung auf, die
die vom Computer am Netzwerk von Computern empfangene Nachricht verwendet.
A137. Die App bzw. Anwendung auf dem Google Android Mobiltelefon, für die die Notifizierung gedacht ist, nutzt diese Notifizierung zum Beispiel dafür, um dem Besitzer
des Mobiltelefons anzuzeigen, dass neue Daten für diese Anwendung verfügbar sind,
so dass dieses Merkmal erfüllt ist. In diesem Zusammenhang wird auf Seite 1 der
Anlage EIP A16 wie folgt ausgeführt:
„Android Cloud to Device Messaging (C2DM) ist ein Dienst, mit
dem Entwicklern beim Versenden von Daten von Servern zu Ihren
Apps auf Android-Geräten geholfen wird. Der Dienst stellt ein einfaches, leichtes Mittel bereit, den Server nutzen können, um mobilen
Anwendungen mitzuteilen, den Server direkt zu kontaktieren, um aktualisierte Anwendungen oder Nuterdatzen abzurufen. Der C2DM-
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-74
Dienst befasst sich mit sämtlichen Aspekten der Bildung einer Warteschleife von Nachrichten und Zustellung zur Zielanwendung, die
auf dem Zielgerät läuft.“
…
„Es ermöglicht Drittanbieter-Anwendungsservern, einfache Nachrichten zu deren Android-Anwendungen zu senden. Der Benachrichtigungsdienst ist nicht zum Senden einer Menge Nutzerinhalt über
die Nachrichten ausgelegt, sondern sollte vielmehr dazu genutzt
werden, der Anwendung mitzuteilen, dass neue Daten auf dem Server bereitliegen, so dass die Anwendung sie abrufen kann.“
Anspruchsmerkmal 5:
Es ist eine kryptografische Steuerung vorgesehen, die
Anspruchsmerkmal 5.1:
eine Verschlüsselung oder Signatur von abgehenden
Nachrichten steuert und
Anspruchsmerkmal 5.2:
die Entschlüsselung oder Autentifizierung von ankommenden Nachrichten steuert.
Anspruchsmerkmal 5.3:
Die kryptografische Steuerung arbeitet, um eine sichere Verbindung, über die sie die ankommenden
Nachrichten empfängt, durch Verwenden eines Einwegkanals aufzubauen.
Anspruchsmerkmal 5.4:
Dabei wird ein dazugehöriger Zweiwegekanal verwendet, um Sicherheitsinformationen auszutauschen, die zum Aufbauen der sicheren Verbindung
über den Einwegkanal nötig ist.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-75
A138. Wir verweisen im Hinblick auf diese Merkmale auf unsere obigen Ausführungen
bezüglich der Verletzung des Anspruchs 7 aus dem Klagepatent A durch den GCMDienst.
4.
Benutzung der Lehre des Klagepatents A – Das Anbieten und Senden von Daten
unter Nutzung von Push Notifications durch die Beklagten zu 1 und 3
A139. Die Beklagte zu 1 bietet Anwendungen zur Nutzung auf Android Mobiltelefonen,
die Push Notifications so wie im obigen Abschnitt 2 und/oder 3 beschrieben erhalten,
an und stellt diese bereit; die Beklagte zu 3 bietet derartige Anwendungen ebenfalls
an.
A140. Wir fügen als
Anlage EIP A17
einen Ausdruck der Webseiten der deutschen Google Play Webseite der Beklagten
zu 1 bei, auf der Anwendungen zum Download von Chrome, Google+, Gmail,
Hangouts und Google Play für Geräte in Deutschland angeboten werden.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-76
A141. Laut Abschnitt 2 der Google Play Nutzungsbedingungen, die wir als
Anlage EIP A18
beifügen, kommt der Vertrag zum Download und zur Nutzung der Anwendungen
mit dem Provider der Anwendung, im Fall der genannten „Google“-Anwendungen
also mit der Beklagten zu 1, zustande.
A142. Die Notifizierungen werden zu diesen Anwendungen „gepusht“, indem die GCMund/oder C2DM-Verfahren, die von der Beklagten zu 1 entwickelt wurden und betrieben werden, wie oben in Abschnitt 2 und 3 angewandt werden.
A143. Beispielhaft verweisen wir auf die erste Seite der Anlage EIP A17 und weisen hierbei insbesondere auf folgende Passage hin:
„Get your email instantly via push notifications”
Auf Deutsch:
“Sie erhalten Ihre E-Mails umgehend über Push-Benachrichtigungen”
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-77
A144. Zur weiteren Verdeutlichung fügen wir als
Anlage EIP A19
einen Ausdruck der Webseiten http://googledevelopers.blogspot.co.uk/2013/05/building-efficient-apps-and-extensions.html,
und
http://developer.chrome.com/-
apps/cloudMessaging.html (auf welche man durch den ersten Webseitenlink gelangt). Insbesondere weisen wir auf folgende Passage hin:
„Event pages keep apps and extensions efficient by allowing them to
respond to a variety of events such as timers or navigation to a particular site, without having to remain running persistently. But what if
you need to respond to something that occurs outside of Chrome, such
as a news alert, a message sent to a user or a stock hitting a price
threshold? Until now, you had to do this by repeatedly polling a server.
This process consumed bandwidth and reduced the battery life of your
users’ machines. For a more efficient solution, starting today you can
use Google Cloud Messaging for Chrome (GCM) - across all channels
of Chrome.
GCM will be familiar to developers who have used Google Cloud Messaging for Android. To send a message, all you need to do is:
1.
Request a token (channel ID) via
chrome.pushMes-
saging.getChannelId().
2.
Pass the returned token to your server.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
3.
Seite A-78
Whenever you need to send a message to your app or
extension,
post the message along with the token to
the GCM server-side API.
Your message is then delivered in near real time to Chrome. This makes
your event page wake up (if it’s not already running), and the message
is delivered to your chrome.pushMessaging.onMessage listener.”
Auf Deutsch:
„Event-Seiten halten Apps und Erweiterungen effizient, indem sie diesen gestatten, auf eine Vielzahl von Events zu reagieren, wie etwa Timer oder Navigation zu einer bestimmten Seite, ohne dabei andauernd
weiterlaufen zu müssen. Was aber passiert, wenn Sie auf etwas reagieren müssen, das außerhalb von Chrome auftritt, wie etwa ein News
Alert, eine an einen Nutzer versandte Nachricht, oder eine Aktie, die
eine Preisgrenze erreicht? Bisher mussten Sie dies durch wiederholtes
Abfragen eines Servers tun. Dieser Prozess beanspruchte eine Bandbreite und verminderte die Akkulaufzeit Ihrer Nutzer-Einrichtungen.
Für eine effizientere Lösung können Sie ab heute Google Cloud Messaging für Chrome (GCM) nutzen - und zwar über sämtliche Kanäle
von Chrome.
GCM wird Entwicklern vertraut sein, die Google Cloud Messaging für
Android genutzt haben. Zum Versenden einer Nachricht, brauchen Sie
nur folgendes zu tun:
1.
Fordern
Sie
ein
Token
(Kanal-ID)
an
über
chrome.pushMessaging.getChannelId().
2.
Leiten Sie das zurückgesandte Token an Ihren Server
weiter.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
3.
Seite A-79
Immer dann, wenn Sie eine Nachricht an Ihre App oder
Erweiterung senden müssen, schicken Sie die Nachricht
mit dem Token an die GCM-serverseitige API.
Ihre Nachricht wird dann nahezu in Echtzeit an Chrome geschickt.
Dadurch wird Ihre Event-Seite geweckt (falls sie nicht bereits läuft)
und die Nachricht wird an Ihren chrome.pushMessaging.onMessage
Empfänger geschickt.“
A145. Wir verweisen zudem auf die unten abgebildeten Screenshots der „Einstellungsregisterkarten“ der Google+-, Google Play und Hangouts-Anwendungen.
Google Play
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-80
Google +
Hangouts
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
Seite A-81
A146. Zusätzlich hierzu und anderen vorinstallierten Anwendungen, die derartige Push Notifications senden, hat die Beklagte zu 1 viele zusätzliche Anwendungen entwickelt,
die ebenfalls darauf ausgelegt sind, solche Push Notifications zu erhalten, und die
sie in dem oben genannten „Play Store“ verkauft.
5.
Benutzung der Lehre des Klagepatents A – Verkauf und Anbieten von Android
Mobiltelefonen
A147. Die Beklagte zu 1 und 3 bieten sogenannte „Android Smartphones“ und „Android
Tablets“ an, also Geräte, die mit dem Android-Betriebssystem der Beklagten zu 1
ausgestattet sind, und die Beklagte zu 2 verkauft diese Geräte. Diesbezüglich verweisen wir auf unsere bereits vorgelegten Nachweise (vgl. Anlagen EIP A9, EIP
A10 und EIP A18).
A148. Wie oben in den Abschnitten 2 und 3 dargestellt, hat die Beklagte zu 1 als Teil des
Android-Betriebssystems sogenannte „Push Notifications“ eingerichtet, die Updates
für Anwendungen solcher Smartphones oder Tablets bereitstellen. Insofern verweisen wir auf unseren Ausführungen in den obigen Abschnitten 2 und 3. Die zuvor
genannten Android Smartphones und Tablets werden ebenfalls mit vorinstallierten
Anwendungen geliefert, wie sie oben in Abschnitt 4 beschrieben wurden. Derartige
Geräte verletzen damit das Klagepatent A.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
6.
Seite A-82
Benutzung der Lehre des Klagepatents A – Verkauf und Besitz von AndroidMobiltelefonen und Push-Anwendungen durch die Beklagte zu 4 und 5
A149. Die Beklagte zu 4 stellt her und verkauft und die Beklagte zu 5 bietet sogenannte
„Android Smartphones“ und „Android Tablets“ an, die mit dem o.g. Android-Betriebssystem ausgestattet sind. Ein Beispiel für Android-Push-Notifikationen ist die
„Find My Mobile“ („Finde mein Mobiltelefon“)-Anwendung, die ebenfalls von der
Beklagten zu 4 entwickelt und von der Beklagten zu 5 angeboten wird und die auf
einer Vielzahl von Geräten der Marke „Samsung“ bereits vorinstalliert ist. Entsprechende Webseiten der von den Beklagten zu 4 und 5 betriebenen Homepages fügen
wir als
Anlage EIP A20
bei.
Wie oben bereits in den Abschnitten 2 und 3 ausgeführt, stellt die Beklagte zu 1 als
Teil des Android-Betriebssystems sogenannte „Push-Notifications“ bereit, die eine
Aktualisierung von Anwendungen dieser Smartphones und Tablets ermöglichen. Insofern verweisen wir auf die obigen Abschnitte 2 und 3. Die zuvor genannten Android-Smartphones und Tablets werden auch mit vorinstallierten Anwendungen
geliefert, wie sie in Abschnitt 4 oben beschrieben worden sind, ebenso wie mit eigenen Anwendungen der Beklagten zu 4 wie die oben genannte „Find My Mobile“
(Finde mein Mobiltelefon)-Anwendung, wobei diese Anwendung nur ein Beispiel
für eine Vielzahl weiterer vorinstallierter oder online verfügbarer und herunterladbarer Apps ist. Diese Geräte verletzen damit das Klagepatent A.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
7.
Seite A-83
Benutzung der Lehre des Klagepatents A – Angebot und Verkauf von AndroidGeräten durch die Beklagten zu 6 und 7
A150. Die Beklagten zu 6 und 7 bieten ebenfalls sogenannte „Android-Geräte“ mit vorinstallierten Anwendungen an und verkaufen diese, wobei letztere gemeinsam mit einem Dritten den sogenannten „Huawei Shop“ betreibt. Entsprechende Ausdrucke der
Webseiten der von den Beklagten zu 6 und zu 7 betriebenen Webseiten fügen wir als
Anlage EIP A21
bei.
Wir verweisen insofern erneut auf die obigen Abschnitte 2, 3 und 4.
8.
Benutzung der Lehre des Klagepatents A – Angebot von Android-Mobiltelefonen durch den Beklagten zu 9
A151. Die Beklagte zu 9 bietet ebenfalls sogenannte „Android-Geräte“ mit vorinstallierten
Anwendungen an, wie sie auf ihrer deutschen Webseite beschrieben werden. Entsprechende Ausdrucke der Webseiten fügen wir bei als
Anlage EIP A22.
A152. Wir verweisen erneut auf die obigen Abschnitte 2, 3 und 4.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
IV.
Seite A-84
RECHTSAUSFÜHRUNGEN
Die Begründetheit der mit der Klage gestellten Anträge A-I. bis A-VI. ergibt sich
aus Folgendem:
1.
Unterlassung
A153. Da die Beklagten zu 1 bis 7 und 9 das beschriebene patentverletzende Verfahren
gemäß Anspruch 6 des Klagepatents A ohne Zustimmung der Klägerin in der Bundesrepublik Deutschland zumindest in Mittäterschaft anwenden (für die Beklagten
zu 1, 2, 4, 6, 7 und 9 besteht hier bereits Wiederholungsgefahr) bzw. zur Anwendung
anbieten, verletzen sie unmittelbar die allein der Klägerin zustehenden Rechte gemäß
§ 9 Satz 2 Nr. 2 PatG.
A154. Zusätzlich verletzen die Beklagten zu 1 bis 7 und 9 die der Klägerin gemäß § 9 Satz
2 Nr. 1 PatG zustehenden Rechte, indem sie Funkvorrichtungen gemäß Anspruch 7
anbieten, und zwar in der Regel durch Präsentation auf deutschsprachigen Webseiten
bzw. Verlinkung solcher Webseiten mit Webseiten anderer Beklagter oder Dritter.
Indem die Beklagte zu 3 in dem Telefonat mit der Zeugin Hofmann auf die Webseite
der Beklagten zu 1 verwiesen hat, macht sie sich deren Verletzungshandlungen zu
eigen und verletzt damit ebenfalls die oben genannten Rechte der Klägerin.
A155. Es besteht somit zumindest Erstbegehungsgefahr für alle Verletzungshandlungen,
für die eingangs Unterlassung gefordert wird.
A156. Die Beklagten sind damit gemäß § 139 Abs. 1 PatG zur Unterlassung verpflichtet.
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
2.
Seite A-85
Auskunft und Rechnungslegung
A157. Die Klägerin kennt den Umfang der Verletzungshandlungen nicht. Die Beklagten
sind deshalb gemäß 140b ff. PatG sowie gewohnheitsrechtlich gemäß § 242 BGB
verpflichtet, der Klägerin in der Weise Rechnung zu legen, dass diese den ihr zustehenden Schadensersatzanspruch beziffern kann. Auf diese Informationen ist die
Klägerin angewiesen, um einen bezifferten Schadenersatzanspruch geltend machen
zu können.
A158. Die geschuldeten Angaben sind im Klageantrag A-II. so zusammengefasst, wie sie
zum Zwecke der Rechnungslegung zu machen sind.
3.
Schadensersatz
A159. Der mit Klageantrag A-III. geltend gemachte Schadensersatzanspruch ist dem
Grunde nach gemäß § 139 Abs. 2 PatG gerechtfertigt. Die Beklagten haben schuldhaft in das Klagepatent A eingegriffen.
A160. Weil die genaue Bezifferung des durch die Verletzungshandlungen eingetretenen
Schadens bzw. der angemessenen Entschädigung der Klägerin gegenwärtig noch
nicht möglich ist, hat sie ein berechtigtes Interesse an der Feststellung der Schadenersatzpflicht der Beklagten dem Grunde nach (§ 256 ZPO).
Rechtsanwaltskanzlei Grzimek
Klageschrift vom 10.03.2014
4.
Seite A-86
Veröffentlichung
A161. Der Klägerin steht darüber hinaus ein Anspruch auf Veröffentlichung des Urteils
gemäß § 140e PatG zu. Die Klägerin hat an einer solchen ein berechtigtes Interesse,
da der Rechtsstreit weite Beachtung in der Öffentlichkeit finden und der Ausgang
desselben insbesondere als Planungsgrundlage für Händler und Unternehmer dienen
wird, ob entsprechende Mobilgeräte weiter angeboten oder verwendet werden dürfen.
5.
Prozessuales
A162. Die Zuständigkeit des angerufenen Gerichts ergibt sich daraus, dass es sich um eine
Patentverletzungsstreitigkeit handelt und die angegriffenen Ausführungsformen im
gesamten Gebiet der Bundesrepublik Deutschland und damit auch im Gerichtsbezirk
des Landgerichts Düsseldorf angeboten und vertrieben werden (§ 32 ZPO). Zwei der
Beklagten haben ihren Sitz zudem in Nordrhein-Westfalen.