16 O 49/23 Kart

Leitsatz: 1. Nach § 19 Abs. 2 Nr. 4 GWB liegt ein Missbrauch einer marktbeherrschenden Stellung insbesondere vor, wenn ein marktbeherrschendes Unternehmen als Anbieter oder Nachfrager einer bestimmten Art von Waren oder gewerblichen Leistungen sich weigert, ein anderes Unternehmen gegen angemessenes Entgelt mit einer solchen Ware oder gewerblichen Leistung zu beliefern, insbesondere ihm Zugang zu Daten, zu Netzen oder anderen Infrastruktureinrichtungen zu gewähren, und die Belieferung oder die Gewährung des Zugangs objektiv notwendig ist, um auf einem vor- oder nachgelagerten Markt tätig zu sein und die Weigerung den wirksamen Wettbewerb auf diesem Markt auszuschalten droht, es sei denn, die Weigerung ist sachlich gerechtfertigt. Nicht jede Zugangsverweigerung ist nach dem GWB missbräuchlich. Voraussetzung ist eine Weigerung “gegen angemessenes Entgelt”. Auch kommt eine unbillige Behinderung nur in Betracht, wenn der Zugang „gegen angemessenes Entgelt“ verweigert wird.(Rn.83) 2. Die Angemessenheit des Entgeltes bemisst sich nach betriebswirtschaftlichen Gesichtspunkten. Angemessen ist nur ein solches Entgelt, das bei isolierter Betrachtung der Vorleistung auch missbrauchsfrei wäre.(Rn.84) 1. Der Antrag auf Erlass einer einstweiligen Verfügung wird zurückgewiesen. 2. Die Antragstellerin trägt die Kosten des Verfahrens. 3. Das Urteil ist vorläufig vollstreckbar. Der Antragstellerin wird nachgelassen, die Vollstreckung durch Sicherheitsleistung in Höhe von 110 % des vollstreckbaren Betrages abzuwenden, wenn nicht die Antragsgegnerin zu 2) zuvor Sicherheit in Höhe von 110 % des jeweils zu vollstreckenden Betrages leistet. Der Antrag ist zulässig, aber unbegründet. A. Der Antrag ist zulässig Die örtliche Zuständigkeit des Landgerichts Berlin ergibt sich aufgrund des Sitzes der vom vermeintlichen Verstoß betroffenen Antragstellerin in Berlin aus §§ 937 Abs. 1, 32 ZPO (vgl. BGH, Beschluss vom 27. November 2018 – X ARZ 321/18, Rn. 18). Der Antrag ist dahin auszulegen, dass es um Zugang zur API bzgl. Fahrtenvermittlungen in Deutschland geht. Die Antragstellerin hat ein entsprechendes (vorliegend auch naheliegendes) Verständnis im Verhandlungstermin vom 7.9.2023 klargestellt. B. Der Antrag ist unbegründet. Denn die Antragstellerin kann das Vorliegen eines Verfügungsgrundes, d.h. der für ein Vorgehen im einstweiligen Rechtsschutz erforderlichen Eilbedürftigkeit nicht darlegen. Wenngleich die Antragstellerin mit ihrem Antrag die Untersagung eines Verhaltens beantragt, geht es ihr der Sache nach um mehr als bloß die Sicherung eines Anspruchs (hier auf Gewährung von Zugang zur API), nämlich die (vorläufige) Befriedigung des Anspruchs selbst. Hieran ändert nichts, dass – wie die Antragstellerin im Verhandlungstermin vertieft hat – aus Sicht der Antragstellerin lediglich erreicht werden soll, dass Xxx keine weiteren Maßnahmen vornimmt, d.h. schlicht nichts verändert. Da dies aus Sicht der Antragstellerin aber gerade der Zugangsgewährung dient (welchen sich die Antragstellerin bei unveränderter Sachlage dann „selbst“ organisieren kann), verbleibt es doch dabei, dass der Sache nach Erfüllung der aus Sicht der Antragstellerin geschuldeten Leistung erfolgen soll (der Datenzugang kann denklogisch nur i.S.e. Vorwegnahme der Hauptsache gewährt werden und insbesondere nicht rückabgewickelt oder nur hinterlegt werden o.ä.). Für den Erlass einer solchen einstweiligen (Leistungs-) Verfügung ist es jedenfalls erforderlich, dass bei Abwägung der Interessen des Gläubigers und des Schuldners die Interessen des Gläubigers deutlich überwiegen, weil die Anspruchsdurchsetzung für diesen besonders dringlich und andererseits das Risiko des Schuldners, im Verfügungsverfahren zu Unrecht verpflichtet zu werden, verhältnismäßig gering ist (vgl. BGH, Urteil vom 10. Oktober 2017 – I ZB 96/16, Rn. 35). Diese Voraussetzung ist im Streitfall nicht erfüllt. Die besondere Dringlichkeit der Anspruchsdurchsetzung ist seitens der Antragstellerin nicht glaubhaft gemacht. I. Dies folgt noch nicht daraus, dass die Antragstellerin offenbar bereits am 22.5.2023, d.h. mehr als 2 Monate vor der hiesigen Antragstellung Kenntnis von der Integration der GPI in die API-Schnittstelle der Fahrer-App hatte und dennoch mit dem Einleiten des hiesigen Verfahrens bis zum 28.7.2023 (Eingang des Antrags bei Gericht) zuwartete. Denn aus den genannten Umständen ergibt sich nur, dass die Antragstellerin Kenntnis von der Integration der GPI hatte, nicht jedoch, dass sie seinerzeit bereits Kenntnis von der Aktivierung der Sicherheitsstufe „Device Integrity“ hatte. Die Antragstellerin trägt insofern den 4.7.2023 vor; die Antragsgegnerseite hat hinsichtlich der Aktivierung eine frühere Kenntnis nicht dargelegt. Eine frühere Aktivierung (und damit denklogisch auch: Kenntnis) erscheint auch deswegen fernliegend, weil die Antragstellerin die Aktivierung unwidersprochen mit erheblichen und plötzlichen Zugriffsproblemen (erst) am 4.7.2023 in Verbindung bringt (Antragsschrift Rz. 22 ff.). II. Aus Sicht der Kammer spricht vorliegend aber gegen eine besondere Dringlichkeit eine Gesamtschau der maßgeblichen Umstände, insbesondere unter Berücksichtigung des vorprozessualen Verhaltens der Antragstellerin. 1. Gegen die Annahme einer besonderen Dringlichkeit spricht zunächst, dass die Antragstellerin derzeit (bzw. inzwischen schon wieder über ca. 2 Monate) wie von ihr angestrebt „ungestört“ auf die API von Xxx zugreifen kann. 2. Dass es Anfang Juli zur Aktivierung der GPI und somit einer kurzfristigen Erschwerung kam, spricht für sich noch nicht für eine besondere Dringlichkeit. Denn es ist nicht glaubhaft gemacht, dass es Xxx hier gerade um eine Behinderung der Klägerin ging. Die Antragstellerin kann ihren Vortrag, dass die Aktivierung der GPI dazu diene, die Bliq-App bzw. deren Zugriff „gezielt“ zu „behindern“ (Antragsschrift Rz. 29 – 31) nicht substantiieren, jedenfalls nicht glaubhaft machen. Auch eine bloße Verweigerungshaltung aufgrund der GPI-Aktivierung ist nicht glaubhaft gemacht (wenngleich, was vorliegend aber dahinstehen kann, seitens Xxx ggfs. in Kauf genommen wurde, dass dies zu Zugriffsproblemen bei der Antragstellerin führt). Hierfür ist zu berücksichtigen, dass es sich bei der Aktivierung der GPI um eine allgemeine Sicherheitsanwendung eines prominenten Drittanbieters, nämlich Google handelt, und Google die Verwendung der GPI den App-Anbietern generell empfiehlt. Zwar trägt die Antragstellerin vor, dass es sich nicht um eine naheliegende Lösung für den Schutz von Ride-Hailing-Apps handele und Xxx andere Lösungen zur Verfügung stünden (Schriftsatz vom 5.9.2023, S. 11). Die Antragsgegnerseite hat hierzu aber weiter nachvollziehbar vertieft, weshalb die von der Antragstellerin ins Spiel gebrachten Alternativen zu GPI für sie nicht in Betracht kommen (Schriftsatz vom 7.9.2023, S. 21). Schließlich hat die Antragsgegnerseite plausibel dargestellt, dass Hauptgrund für die GPI-Integration von der Antragstellerin unabhängige Manipulationen von GPS-Koordinaten waren und die GPI-Integration insofern (Betrugsfälle in Tansania) tatsächlich zu messbaren Verbesserungen aus Sicht von Xxx führte. Aus dem Vorverhalten von Xxx lässt sich nicht auf eine anderweitige Absicht bei der GPI-Verwendung schließen. Insbesondere ist nicht glaubhaft gemacht, dass sich der von der Antragstellerin so genannte „Bliq-Check“ konkret gegen die Antragstellerin richtete. Die Antragsgegnerseite hat darauf hingewiesen, dass es um die generelle Abfrage des Vorhandenseins von Ride-Hailing-Apps ging. Die Antragstellerin kann eine auf sie fokussierte Zielrichtung nicht glaubhaft machen. Auch aus der Kommunikation der Antragsgegnerseite im Verfahren lässt sich keine Verweigerungsabsicht schließen. Die Antragsgegner haben erklärt, dass eine „Blockade“ des Zugangs nicht vorläge (Antragserwiderung S. 5). Dass die Antragsgegner ähnlich wie Uber schärfere Sicherheitsmaßnahmen ergreifen können, hat sie als „pure Spekulation“ bezeichnet (aaO S. 15). 3. Vor diesem Hintergrund (Zugang besteht derzeit ungestört, Vorverhalten von Xxx kein Indiz für Behinderungsabsicht, siehe eben) fällt allerdings als dringlichkeitsschädlich ins Gewicht, dass die Antragstellerin bisher nicht auf Xxx mit der Bitte um Verhandlungen zum API-Zugang zugegangen ist. Dieses Verhalten (keine Aufnahme von Verhandlungen, sondern Ausnutzen des Status Quo aufgrund des technisch möglichen selbstorganisierten API-Zugangs) spricht deswegen gegen eine Dringlichkeit der Anspruchsverfolgung durch die Antragstellerin, weil die Antragstellerin damit selbst zu erkennen gibt, wichtige notwendige Schritte zur verbindlichen Absicherung der begehrten Zugangsgewährung nicht mit Nachdruck anzugehen. Aus Sicht der Kammer ist vorliegend allerdings naheliegend, dass ein erheblicher – seitens der Antragstellerin aufgeschobener – Klärungs- und Vereinbarungsbedarf besteht: Dies betrifft zum einen die Datenschutzkonformität (Die Antragstellerin ist derzeit offenbar der Ansicht, dass hier kein Klärungsbedarf vorliegt), das für den Zugang zu gewährende Entgelt (Die Antragstellerin ist der Ansicht, dass Zugang unentgeltlich zu gewähren sei, Antragsschrift Rz. 116) als auch weitere technische/Sicherheitsaspekte, deren Klärung Xxx zunächst erwarten darf bzw. organisieren muss (dazu gleich noch unten). Vor diesem Hintergrund kann das bisherige Verhalten seitens Xxx auch nicht als Verweigerung der Gewährung des Zugangs zu Daten gegen angemessenes Entgelt, d.h. als Verletzungshandlung iSv § 19 Abs. 2 Nr. 4 GWB und § 20 Abs. 1a GWB gewertet werden. Denn die dort umschriebene Verletzungshandlung bezeichnet letztlich einen Kommunikationsakt: Für die Verletzungshandlung allein entscheidend ist, dass der Normadressat der genannten Vorschriften zum Ausdruck bringt, den begehrten Zugang zu Daten nicht gewähren zu wollen (vgl. LG Berlin, Urteil vom 15.05.2023 – 61 O 26/23 Kart). Daran fehlt es. Im Einzelnen: a) Es ist glaubhaft gemacht, dass – vorbehaltlich einer diesbezüglichen Klärung und dem Ergreifen weiterer organisatorischer Schritte – eine Datenschutzkonformität des derzeitigen seitens der Antragstellerin praktizierten Zugangs zur API nicht gegeben ist. Zwischen den Parteien ist unstreitig, dass die Nutzung der Bliq-App zur Verarbeitung persönlicher (Fahrgast-) Daten führt (vgl. Antragsschrift Rz. 99 ff. sowie Antragserwiderung S. 26 ff.), was auch naheliegt. aa) Allerdings ist zwischen den Parteien streitig, ob die Verarbeitung durch die Antragstellerin „privilegiert“ im Rahmen einer Auftragsverarbeitung für die Fahrer erfolgt (zu den „privilegierten“ Rechtfertigungsanforderungen in diesem Fall noch unten) oder aber die Verarbeitung hier durch die Antragstellerin als Verantwortliche erfolgt. Aus Sicht der Kammer erscheint überwiegend wahrscheinlich, dass die Antragstellerin nicht lediglich als Auftragsverarbeiterin i.S.v. Art. 4 Nr. 8 DS-GVO tätig wird. Insofern ist zunächst darauf hinzuweisen, dass allein die Frage, ob sich die Antragstellerin auf Vereinbarungen zur Auftragsverarbeitung mit den Fahrern stützen kann (Antragsschrift Rz. 100), insofern nicht entscheidend ist, da es für die Frage des Vorliegens einer (bloßen) Auftragsverarbeitung auf die tatsächlichen Umstände ankommt (dazu gleich). Gegen eine bloße Auftragsverarbeitung dürfte sprechen, dass die Fahrer – in deren Auftrag die Antragstellerin die Daten verarbeiten will – nur begrenzt Zweck und Mittel der Verarbeitung durch die Antragstellerin überblicken und steuern dürften (vgl. insofern zur Abgrenzung zwischen Auftragsverarbeiter gem. Art. 4 Nr. 8 DS-GVO einerseits und andererseits dem Verantwortlichen gem. Art. 4 Nr. 7 DS-GVO, der allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten entscheidet EuGH, Urteil vom 10.7.2018, C-25/17 (Zeugen Jehovas), Rn. 68 sowie Leitlinien 07/2020 des Europäischen Datenschutzausschuss zu den Begriffen „Verantwortlicher“ und „Auftragsverarbeiter“ in der DSGVO (EDSA), Version 2.0, Rz. 32 ff.). Jedenfalls erscheint beachtlich, dass sich die Antragstellerin – worauf die Antragsgegnerseite unwidersprochen hingewiesen hat – in der Vereinbarung zur vermeintlichen Auftragsvereinbarung mit den Fahrern die Unterbeauftragung von Auftragsverarbeitungen vorbehält und die Fahrer insofern nur begrenzt widersprechen können sollen (vgl. Schriftsatz Antragsgegnerin zu 2) vom 7.9.2023 s. 8 = Bl. 180 d.A. sowie Ziff. 7.2. in Annex 1: Data Processing Agreement in CC20), womit eigene (zumindest beabsichtigte) Zwecke der Antragstellerin naheliegen. Hinzu kommt, dass die Antragstellerin der Behauptung der Antragsgegnerseite, wonach allein die Antragstellerin über die Dauer der Datenspeicherung bei ihr entscheiden würde (a.a.O. S. 5 = Bl. 177 d.A.), substantiiert nicht entgegengetreten ist. Vor allem aber ist zu beachten, dass nicht davon ausgegangen werden kann, dass die Fahrer vorliegend selbst Verantwortliche iSv Art. 4 Nr. 7 DS-GVO sind (insofern dürfte vielmehr allein Xxx und nicht die Fahrerseite in Betracht kommen), eine Auftragsverarbeitung gem. Art. 28 Abs. 1 DS-GVO aber gerade voraussetzt, dass die „Verarbeitung im Auftrag eines Verantwortlichen“ erfolgt. bb) Es erscheint ferner überwiegend wahrscheinlich, dass die entsprechende Verarbeitung nicht durch die Erlaubnistatbestände in Art. 6 DS-GVO gerechtfertigt ist. Einwilligungen (der Fahrgäste) iSv Art. 6 Abs. 1 lit. a) DS-GVO sind insofern nicht ersichtlich. Eine Rechtfertigung nach Art. 6 Abs. 1 lit. b) DS-GVO scheidet aus, weil die Antragstellerin nicht Vertragspartnerin der Fahrgäste ist, um deren Daten es geht. Eine – einzig noch in Betracht kommende – Rechtfertigung nach Art. 6 Abs. 1 lit. f) DS-GVO dürfte nicht in Betracht kommen: Voraussetzung wäre, dass dies zur Wahrung der berechtigten Interessen des Verantwortlichen (hier unterstellt: der Antragstellerin) erforderlich wäre. Hiergegen sprich aber schon, dass es der Antragstellerin zumutbar sein dürfte, mit Xxx in Verhandlungen zur Ausgestaltung des API-Zugangs zu treten und insofern auch zur Ausgestaltung der Datenschutzkonformität zu klären, z.B. durch Anpassung der dortigen Einholung von Einwilligungen durch die Fahrgäste (iSv Art. 6 Abs. 1 lit. a) DS-GVO); zumal ohnehin eine Regelung zum Entgelt zu treffen ist (dazu noch unten). Vorliegend dürften jedenfalls die Interessen oder Grundrechte und Grundfreiheiten der betroffenen Person, die den Schutz personenbezogener Daten erfordern (d.h. hier die Interessen der Fahrgäste), ein Verbreitungsinteresse der Antragstellerin überwiegen iSv Art. 6 Abs. 1 lit. f) DS-GVO. Denn durch die Wahl ihrer App (z.B. Xxx-Fahrgast-App), die auch und gerade im Hinblick auf die Gewährleistung eines Datenschutzniveaus getroffen werden kann, dürften die Fahrgäste nach derzeitigem Stand eher nicht damit rechnen, dass ihre Fahrtenanfragen (eigenmächtig) durch Drittanbieter verarbeitet werden. Zu berücksichtigen ist auch, dass es sich bei den fraglichen Daten um solche handelt, bei denen ein erhöhtes Vertraulichkeitsbedürfnis vorliegen kann (da sich z.B. Bewegungsprofile ableiten lassen usw.), wenngleich die Kammer nicht davon ausgeht, dass vorliegend besondere Kategorien personenbezogener Daten vorliegen (vgl. zum einschränkenden Verständnis des Art. 9 Abs. 1 DS-GVO bei eher theoretischer Ableitbarkeit der dortigen Datenkategorien: BeckOK DatenschutzR/Albers/Veit, 44. Ed. 1.5.2023, DS-GVO Art. 9 Rn. 29 f.). Hinzu kommt, dass vorliegend den Fahrern durch die Xxx-AGB der Abschluss von Verarbeitungsverträgen mit Dritten verboten ist (Schriftsatz der Antragsgegnerin zu 1) vom 7.9.2023, S. 9), was im Rahmen der Interessenabwägung zu würdigen sein dürfte (zumal dies auch für berechtigte Sicherheitserwartungen der Fahrgäste spricht). Dass die Kammer vorliegend eine Auftragsverarbeitung eher als fernliegend ansieht, ist für diese Würdigung unerheblich: Wenn den Fahrern aber schon verboten ist, Auftragsverarbeitungsverträge zu schließen, so ist diesen erst recht untersagt, Dritten zu ermöglichen, die Daten als Verantwortlicher zu verarbeiten (ohnehin könnte insofern ein Vertragsverstoß der Fahrer im Raum stehen). Selbst wenn man davon ausginge, dass es sich bei der Datenverarbeitung durch die Antragstellerin um eine Auftragsverarbeitung handelte, und eine in Betracht kommende Rechtfertigung gem. Art. 6 Abs. 1 lit. f) DS-GVO (BeckOK DatenschutzR/Spoerr, 44. Ed. 1.5.2022, DS-GVO Art. 28 Rn. 31) unter diesem Blickwinkel zu prüfen wäre, ergäbe sich keine andere Bewertung. cc) Vorliegend kann unterstellt werden, dass die genannten datenschutzrechtlichen Beschränkungen nicht dazu führen, dass der von der Antragstellerin verfolgte Anspruch ausgeschlossen bleiben muss. Denn zwar sind Datenschutzverstöße grundsätzlich regelmäßig ein sachlicher (Zurückweisungs-) Grund iSv § 19 Abs. 2 Nr. 4 GWB n.F. (BT- Drucksache 19/23492 S. 72: „… insbesondere bedarf es einer Rechtsgrundlage für die Rechtmäßigkeit der Verarbeitung“). Allerdings kann der Zugangsanspruch nach § 19 Abs. 2 Nr. 4 (bzw. entsprechend § 20 Abs. 1) GWB dazu führen, dass der Dateninhaber im Einzelfall verpflichtet ist, an der Herstellung der notwendigen Datenschutzkonformität mitzuwirken (z.B. MüKoEuWettbR/Wolf GWB § 19 Rn. 170c (mwN): „Da der Zugangsanspruch auch Vorbereitungshandlungen zur Ermöglichung des Zugangs erfasst, könnte im Einzelfall eine Verpflichtung des Normadressaten bestehen, innerhalb der sondergesetzlichen und wettbewerbsrechtlichen Grenzen seine Bestands- oder Neukunden um eine entsprechende Einwilligung zu bitten.“). Nach dem vorliegend glaubhaft gemachten Sachverhalt bedeutet dies, dass die Antragstellerin von Xxx ggfs. zunächst die Herstellung eines datenschutzkonformen Zugangs verlangen könnte (d.h. z.B. Einholung der Einwilligungen der Fahrgäste dahin, dass die Fahrgastdaten auch durch Vermittlungs-Apps wie Bliq verarbeitet werden dürfen) und ggfs. bei der weiteren Zugangsgewährung zu differenzieren wäre, wenn einzelne Kunden die Einwilligung verweigern. Ferner wäre für diesen Fall wohl gegenüber den Fahrern zu regeln, dass diese entsprechende Apps (wie Bliq) nutzen dürfen. Weiter kommt in Betracht, dass technische Details / Sicherheitsfragen zu klären wären. Für das vorliegende Verfahren allein entscheidend ist, dass mit der von der Antragstellerin begehrten Zugangsgewährung jedenfalls aufgrund der Herstellung der Datenschutzkonformität erheblicher Klärungs- und Abstimmungsaufwand einhergeht (s.o. für die Würdigung im Rahmen des Verfügungsgrundes). Eine weitere – für das Verfahren erhebliche - Konsequenz der eben erläuterten Herstellung der Datenschutzkonformität dürfte sich für die Frage des angemessenen Entgelts der Zugangsgewährung ergeben (dazu gleich). b) Ferner ist aus Sicht der Kammer naheliegend, dass das angemessene Entgelt, von welchem Xxx die Zugangsgewährung abhängig machen darf, vorliegend über Null liegt. Nach § 19 Abs. 2 Nr. 4 GWB ist nicht jede Zugangsverweigerung missbräuchlich; Voraussetzung ist eine Weigerung “gegen angemessenes Entgelt”. Auch kommt eine unbillige Behinderung nach §§ 20 Abs. 1, Abs. 1a, 19 Abs. 1, Abs. 2 Nr. 1 GWB nur in Betracht, wenn der Zugang „gegen angemessenes Entgelt“ (§ 20 Abs. 1a Satz 2 GWB) verweigert wird. Die Angemessenheit des Entgeltes bemisst sich nach betriebswirtschaftlichen Gesichtspunkten. Angemessen ist nur ein solches Entgelt, das bei isolierter Betrachtung der Vorleistung auch iSd § 19 Abs. 2 Nr. 2 oder 3 GWB missbrauchsfrei wäre; materiell sind also die Maßstäbe der § 19 Abs. 2 Nr. 2 und 3 GWB – insbes. das Vergleichsmarktkonzept – auf § 19 Abs. 2 Nr. 4 GWB übertragbar, soweit es um die Angemessenheit des Entgelts geht. Ohne hinreichend vergleichbare Märkte läuft die Angemessenheitsprüfung regelmäßig auf eine Kostenkontrolle hinaus (MüKoEuWettbR/Wolf, 4. Aufl. 2022, GWB § 19 Rn. 155) so dass in jedem Falle (anteilige) Kostendeckung verlangt werden kann (Bechtold/Bosch/Bechtold/Bosch, 10. Aufl. 2021, GWB § 19 Rn. 74). Vorliegend ist insofern für ein Entgelt über Null zu berücksichtigen, dass Xxx einerseits Investitionskosten entstanden sind (Xxx kann nur deswegen potentielle Fahrgäste bzw. Fahrgastanfragen vermitteln, weil insofern mittels Investitionen ein Geschäftsmodell aufgebaut wurde). Zudem ist davon auszugehen, dass die spezifische Zugangsgewährung für die Antragstellerin allein schon aus Gründen der Herstellung der Datenschutzkonformität Kosten verursacht. Im Übrigen läge aus Sicht der Kammer zudem nahe, dass vorliegend – neben der Kostenbetrachtung – ein angemessenes Entgelt über Null schon mit dem Vergleichsmarktkonzept ermittelt werden kann. Aus Sicht der Anbieter jedenfalls von großen Ride-Hailing-Plattformen wie Xxx dürfte es nämlich einen wirtschaftlichen Wert darstellen, wenn sich Fahrer „ihre“ Angebote (potentielle Fahrten) durch die eigene Fahrer-App anschauen, da die Aufmerksamkeit der Fahrer dann stärker gebunden ist als bei einer Betrachtung über Vergleichsplattformen wie die der Antragstellerin. So wie die ungeteilte Aufmerksamkeit im Werbebereich einen Wert hat, gilt dies auch vorliegend, da für die Antragstellerin die Chance zum Verdienst einer Provision (d.h. Annahme eines Fahrtenangebotes in der App) steigen dürfte, wenn das Angebot vorher durch die eigene App wahrgenommen wurde (statt „neben“ weiteren Alternativen), was in der mdl. Verhandlung auch erörtert wurde. Unabhängig davon, wie angesichts der vorstehenden betriebswirtschaftlichen Erwägungen das „angemessene“ Entgelt letztlich zu bestimmen wäre, sprechen alle diese Erwägungen dafür, dass dieses jedenfalls über Null liegt. Hierfür spricht auch, dass das Geschäftsmodell der Antragstellerin – auch wenn man mit ihrer Argumentation von der Tätigkeit auf einem vor- bzw. nachgelagerten Markt ausgeht – den Wettbewerb auf dem Markt, auf dem Xxx tätig ist, intensiviert. C. Die prozessualen Nebenentscheidungen beruhen auf § 91 Abs. 1 ZPO sowie §§ 708 Nr. 6, 711 Satz 1 und 2 ZPO. Die Antragstellerin begehrt eine auf Kartellrecht gestützte einstweilige Verfügung gegen die Antragsgegnerin zu 2) (Anmerkung: das Verfahren gegen die Antragsgegnerin zu 1) ist abgetrennt worden, die Parteibezeichnung bleibt zwecks Nachvollziehbarkeit unverändert), dieser zu untersagen, den Datenzugriff der Bliq-App der Antragstellerin auf die Anwendungsprogrammierschnittstelle (nachfolgend: API) der Xxx-Fahrer-App der Antragsgegnerseite (nachfolgend auch „Xxx“ genannt) zu unterbinden. Die Antragsgegnerin zu 2) sowie die Xxx Xxxx XXX (bis zur Abtrennung des gegen sie gerichteten Verfahrens hier Antragsgegnerin zu 1), nachfolgend zur Vereinfachung weiter entsprechend bezeichnet) sowie die nicht am Verfahren beteiligte Xxx xxxxx XXX gehören zu dem Unternehmen Xxx, welches eine sog. Ride-Hailing-Plattform betreibt. Im Zentrum stehen zwei Ride-Hailing-Apps: Die Fahrgast-App "Xxx: Fahrten anfordern" (die "Xxx-Fahrgast-App"); zum anderen die Fahrer-App "Xxx Driver: Fahren und Geld verdienen" (die "Xxx-Fahrer-App"). Mit diesen Apps tritt Xxx als Vermittler im Bereich des Ride-Hailing zwischen Fahrgästen und Fahrern von Mietwagen- sowie Taxiunternehmern, also der Anbietung und Vermittlung von Fahrdiensten, am Markt auf. Die Antragsgegnerin zu 1.) (Sitz in Estland) ist die Entwicklerin dieser soeben beschriebenen Apps und Mutterunternehmen der Antragsgegnerin zu 2). Die Vertragsbeziehungen zur Fahrerseite unterhält die Xxx Operations XXX (Antragserwiderung S. 4), wobei die Vertragsbeziehungen selten unmittelbar mit dem Fahrer, sondern meist mit Personenbeförderungsunternehmen bestehen (Schriftsatz vom 7.9.2023, S. 8 = Bl. 180 d.A.). Der Markt für die App-gestützte Vermittlung von individuellen Personenbeförderungsleistungen ist v.a. durch drei große Anbieter mit zusammen ca. 80 % Marktanteil geprägt: 35% entfallen auf Uber, 31% auf Xxx und 14% auf FreeNow (Antragsschrift Rz. 18). Die Antragstellerin ist Entwicklerin und Betreiberin der App „Bliq – alle Aufträge, eine App“ („Bliq-App“). Diese App richtet sich an Fahrer von Fahrdiensten im Bereich der On-Demand-Mobilität. Die Bliq-App ermöglicht jedem Fahrer, der die Bliq-App nutzt, den Zugriff auf und die Verwaltung und ggfs. Bestätigung/Annahme von Anfragen aus jeder der von diesem Fahrer genutzten Fahrer-Apps verschiedener Ride-Hailing-Plattformen. Dies erfolgt mittels Zugriff auf die Anwendungsprogrammierschnittstelle ("API") verschiedener Fahrer-Apps der Ride-Hailing-Plattformen. Technisch stellt die Bliq-App eine sichere Verbindung zur jeweiligen API jeder einzelnen Fahrer-App, einschließlich der Xxx-Fahrer-App, her, nachdem der Fahrer seine jeweiligen Anmeldedaten der Fahrer-App(s), die er nutzen möchte, in der Bliq- App eingegeben hat. Weder die Antragstellerin noch die Bliq-App greifen in den Quellcode oder den Objektcode der Xxx-Fahrer-App (oder einer anderen Fahrer-App) ein. Durch die Nutzung der Bliq-App wird nicht in die Apps der verschiedenen Fahrdienste-Anbieter eingegriffen (Antragsschrift Rz. 15). Die Antragstellerin ist seit 2018 in der dargelegten Weise mit ihrer Bliq-App am Markt tätig. Anfragen über die Apps der drei großen Anbieter Uber, Xxx und FreeNow machten bis März 2023 ca. 98% der über die Bliq-App abgewickelten Fahrten aus. Zwischen dem 4.5.2021 und dem 13.8.2022 verwendete Xxx in einigen Versionen der Xxx-Fahrer-App einen Mechanismus, mit dem die Verwendung weiterer Programme von Nutzern der Xxx-Fahrer-App gemessen werden konnte. Die Antragstellerin hatte regelmäßig Zugang zur API der Xxx-Fahrer-App, zuletzt aber zeitweise unter Einschränkungen. Denn seitens Xxx wurde das vom Google-Konzern entwickelte Sicherheitstool „Play Integrity API" (nachfolgend "GPI") in die API der Xxx-Fahrer-App integriert und auf der Stufe "Device Integrity" aktiviert. GPI soll Apps vor unbefugten Zugriffen und betrügerischen Interaktionen schützen, um risikoreiche Angriffe zu verhindern und den Missbrauch zu verringern. Nach Einbindung von GPI weist der Server des App-Betreibers, hier: von Xxx, wenn der Nutzer in der App eine definierte Aktion ausführt, das anfragende Endgerät an, zunächst GPI aufzurufen (Antragsschrift Rz. 24). GPI nimmt mithilfe verschiedener Merkmale eine Integritätsprüfung des Geräts vor (Antragsschrift Rz. 25), wobei verschiedene Sicherheitsstufen bestehen (Basic Integrity, Device Integrity und Strong Identity) und vorliegend seitens Xxx die mittlere Stufe „Device Integrity“ aktiviert wurde (Rz. 29).Die Aktivierung von GPI „führte … dazu“, „dass die Bliq-App der Antragstellerin nutzende Fahrer nicht mehr auf die API der Xxx-Fahrer-App zugreifen konnten“ (Antragsschrift Rz. 29). Die Antragstellerin trägt insofern vor, am 4.7.2023 hätte sie „erstmals“ festgestellt, dass das Tool offenbar integriert und auf der Stufe Device Integrity aktiviert wurde (Antragsschrift Rz. 22). Am 5.7.2023 gelang es der Antragstellerin, den Zugang der Bliq-App zur API der Xxx-Fahrer-App technisch wiederherzustellen (Antragsschrift Rz. 38). Die Antragstellerin trägt vor, dass die Antragsgegnerin zu 2) als Anbieterin bzw. Betreiberin der genannten „Apps sowie der damit verbundenen Leistungen“ in Deutschland auftrete (Antragsschrift Rz. 3). Die Antragstellerin trägt vor, bei dem von Xxx zwischen 4.5.2021 und dem 13.8.2022 verwendeten Mechanismus sei es darum gegangen festzustellen, „ob ein Nutzer der Xxx-Fahrer-App auch die Bliq-App auf seinem Mobilfunkendgerät installiert hat“ (aaO Rz. 34), weshalb sie den Mechanismus als „Bliq-Check“ bezeichnet. Diese Ausrichtung ist zwischen den Beteiligten streitig. Die Antragstellerin meint, mittels der GPI würde die Antragsgegnerseite den „rechtmäßigen Zugriff der Bliq-App“ „behindern“ (Rz. 29) bzw. es läge eine „Beschränkung des Zugriffs“ vor (aaO Rz. 30). Aus ihrer Sicht war dies „gezielt gegen die Bliq-App“ gerichtet (aaO Rz. 31). Dies folge daraus, dass Xxx auch andere Sicherheits-Tools implementieren könnte, die keine Behinderung der Antragstellerin bedeuten würden (aaO Rz. 33). Sie verweist auf einen erheblichen Rückgang der über die Bliq-App vermittelten Fahrten mit Xxx nach dem 4.7.2023 (aaO Rz. 53). Die Antragstellerin befürchtet, dass Xxx den Zugriff auf die API der Xxx-Fahrer-App „erneut gezielt beschränken“ werde. Sie verweist darauf, dass der Wettbewerber Uber eine höhere Sicherheitsstufe der GPI verwendet, ihr dort bisher nicht gelungen sei, den Zugriff auf die API der Uber-Fahrer-App technisch für die Nutzer der Bliq-App sicherzustellen (Antragsschrift Rz. 47) und dass bei Xxx die technischen Voraussetzungen für eine entsprechende Sperre bereits erfüllt seien (aaO Rz. 39 f.). Die Antragstellerin meint, sie hätte Anspruch auf unentgeltlichen Zugang zur API von Xxx. Das nach § 19 Abs. 2 Nr. 4 GWB zustehende Entgelt sei mit Null anzusetzen (aaO Rz. 114), da Xxx durch die Zugangsgewährung keine Kosten entstehen würden (aaO Rz. 116). Die Antragstellerin beantragt, im Wege der einstweiligen Verfügung anzuordnen: Den Antragsgegnerinnen wird bei Meidung eines Ordnungsgeldes bis zu EUR 250.000,00, ersatzweise Ordnungshaft, oder Ordnungshaft, jeweils bis zu sechs Monaten und zu vollziehen an ihren vertretungsberechtigten Organen, untersagt, den Zugriff der App "Bliq" der Antragstellerin auf die Anwendungsprogrammierschnittstelle, respektive die API, der App "Xxx Driver: Fahre & Verdiene" der Antragsgegnerinnen für Nutzer, also Fahrer, der App "Bliq" zu blockieren, soweit dadurch verhindert wird, dass die App "Bliq" die Daten mit der Anwendungsprogrammierschnittstelle, respektive der API, der App "Xxx Driver: Fahre & Verdiene" austauschen kann, die auch die App "Xxx Driver: Fahre & Verdiene" mit dieser Schnittstelle austauscht, insbesondere die Daten, die erforderlich sind, damit Fahrer sich einloggen, online gehen, Fahrten ausführen (inklusive deren Abrechnung und Bewertung) und Übersichten über die geleisteten Fahrten abrufen können, insbesondere die folgenden Daten: (a) Authentifizierung mit Fahrer Login, Gesichtserkennung, (b) Aufhebung der Authentifizierung (Fahrer Logout), (c) An- und Abschalten der Verfügbarkeit der Fahrer, Aufträge zu erhalten, (d) Annahme von Fahraufträgen, (e) Ablehnen von Fahraufträgen, (f) Bestätigung der Ankunft am Abholort, (g) Start des Auftrags, (h) Abschluss des Auftrags, (i) Änderungen am Auftrag (z.B. Änderung des Zielorts, Hinzufügen eines Zwischenhalts, Stornieren von Aufträgen etc.), (j) Bewertung des Fahrgasts, (k) Anfrage von Profilinformationen des Fahrers, (l) Anfrage von Daten zum Fahrer-Einkommen und Bewertungen, (m) Auswahl eines Fahrzeugs, (n) Auswahl der aktiven Produkte (z.B. Xxx: Fahrten anfordern), (o) Abfrage von Details zur Warteschlange in vorgesehenen Bereichen (z.B. Flughäfen), (p) Bereitstellung der aktuellen geographischen Fahrerposition, (q) Abfrage von Reservierung-Aufträgen, Annahme / Ablehnen / Durchführung, (r) Nutzung der Kontaktmöglichkeiten mit Fahrgästen zur Koordination angenommener Fahrten (z.B. Chat, Anruf über anonymisierte Telefonnummer, In-App Anruf), (s) Zielfilter-Funktion: Auswahl eines Ziels für geographisch zielgerichtete Fahranfragen, sodass Fahrer nur Aufträge in eine bestimmte Richtung erhalten (z.B. zu ihrem Wohnort), (t) Stop-Requests-Funktion: Markierung des Stopps von weiteren Angebotsanfragen während eine Fahrt bereits durchgeführt wird (was von Fahrern typischerweise verwendet wird, wenn Sie eine Pause machen möchten), sowie (u) Radius-Funktion: Setzen einer Maximal-Distanz innerhalb derer Aufträge an den Fahrer disponiert werden, und (v) sämtliche weiteren Funktionen welche die "Xxx Driver: Fahre & Verdiene" mit der API der "Xxx Driver: Fahre & Verdiene" austauscht und die für eine Funktionsparität der App "Bliq" der Antragstellerin mit der App "Xxx Driver: Fahre & Verdiene" in Bezug auf eine Funktionsparität beim Einloggen und Online gehen der Fahrer, Fahrten ausführen (inklusive Abrechnung und Bewertung) und Abruf von Übersichten über die geleisteten Fahrten, erforderlich sind. Die Antragsgegnerin zu 2) beantragt, Der Antrag auf Erlass einer einstweiligen Verfügung wird zurückgewiesen. Die Antragsgegnerin zu 2) trägt vor, Anbieterin der Xxx-Fahrer-Apps sei allein die Antragsgegnerin zu 1); „Vertragspartnerin gegenüber den Kunden und Mietwagenunternehmen sowie … Betreiberin der App“ sei allein das weitere Unternehmen Xxx Xxxxx XXX. Sie – die Antragsgegnerin zu 2) – würde hingegen lokale Unterstützung im – hier nicht einschlägigen – Geschäftszweig Car-Sharing Fahrzeuge, E-Scooter und E-Bikes leisten; zum Ride-Hailing-Geschäft “unterstützt” sie “soweit notwendig … für den deutschen Markt”; sie könne auch den streitgegenständlichen Datenzugang nicht gewähren, weil sie nicht Anbieterin der Xxx-Apps sei und nicht über technische Schnittstellen verfüge (Antragserwiderung, S. 4 f.). Sie trägt vor, dass keine „Blockade“ eines Zugangs vorläge (a.a.O. S. 5). Es bestünde ein legitimes Interesse an der Verwendung der Nutzung des Sicherheitstools GPI. Es sei naheliegend und üblich, das Tool zu nutzen (a.a.O. S. 12). Google empfehle dies auch (S. 13). Die Entwicklung eines alternativen Tools sei aufwändig und teuer (a.a.O. S. 13). GPI verhinderte z.B., dass Xxx „gefälschte GPS-Standortdaten“ zukommen (a.a.O. S. 14). Bis heute sei die Antragstellerin niemals an die Antragsgegnerin mit dem Wunsch nach einer Vereinbarung zum Datenzugang herangetreten und es gab niemals Gespräche hierzu (a.a.O. S. 9). Das Vorgehen der Antragstellerin beeinflusse den Preisbildungsmechanismus (a.a.O. S. 6), denn dies ermögliche falsche Angaben zur Lokalisierung der Fahrer, was u.a. die Fahrtpreise beeinflusse (a.a.O. S. 10, 14). Zudem verstieße das Vorgehen gegen Datenschutzrecht und umgehe Sicherheitsfeatures (a.a.O. S. 17 ff.). Beim von der Antragstellerin sog. “Bliq-Check” sei es nicht um ein Ausspähen von Bliq gegangen, sondern um die generelle Abfrage, ob auf Geräten andere Ride-Hailing-Apps vorhanden waren (a.a.O. S. 16). Jedenfalls fehle es an der Dringlichkeit, da die Antragstellerin seit dem 22.5.2023 vom Einsatz des Sicherheitstools GPI wisse (a.a.O. S. 6). Denn die Antragstellerin hätte – ausweislich deren eigenen Vortrags im Parallelverfahren gegen den Anbieter Uber (Anlage CC Rn. 234) - schon am 22.5.2023 Kenntnis von der Integration von GPI in die API-Schnittstelle der Fahrer-App gehabt.