170 Die Verletzungsklage vor dem Landgericht Mannheim (…) gegen die B… AG (das ist die vormalige Klägerin zu 4 aus dem zeitweise hier hinzuverbundenen Nichtigkeitsverfahren 7 Ni 81/19 (EP)), dem die Klägerin zu 1, weil sie Zulieferin war, als Nebenintervenientin beigetreten ist, ist zwar von der Verletzungsklägerin und hiesigen Beklagten zurückgenommen worden. Jedoch besteht das Rechtsschutzinteresse an einer Patentnichtigkeitsklage grundsätzlich auch für den Fall fort, dass ein Patentinhaber eine bereits erhobene Verletzungsklage zurücknimmt, einen Verzicht auf eventuelle Ansprüche aus dem Patent aber nicht erklärt (vgl. BGH GRUR 2010, 1084, Rn. 10 – Windenergiekonverter; GRUR 2020, 1074, Rn. 29 – Signalübertragungssystem).

171 Ein vergleichbarer Fall liegt hier vor. Die Beklagte hat durch ihre oben bezeichnete, bei Erhebung der Nichtigkeitsklage noch anhängige Verletzungsklage zum Ausdruck gebracht hat, dass sie gewillt ist, ihr nach ihrer Auffassung zustehende Ansprüche wegen Verletzung des Streitpatents durchzusetzen. Hiervon ist sie bis zum Schluss der mündlichen Verhandlung nicht abgerückt. Rechtlich gehindert wäre sie nur in einem Fall des Klageverzichts auf Ansprüche aus dem Streitpatent. Einen solchen hat die Beklagte aber gegenüber der Klägerin zu 1 auf Nachfrage des Senats in der mündlichen Verhandlung nicht erklärt. Bei dieser Ausgangslage ist die Besorgnis der Klägerin zu 1 als Zulieferin der B… AG nicht unbegründet, dass sie von der Beklagten wegen Handlungen in der Zeit vor Erlöschen des Streitpatents wegen Verletzung in Anspruch genommen wird. Hiervon abgesehen könnte die Klägerin zu 1 auch Regressansprüchen der B… AG ausgesetzt sein, zumal der Inhalt des Vergleichs aus dem Verletzungsverfahren gegen die B… AG nicht bekannt ist.

172 Auch der Klägerin zu 2, die zwar selbst weder unmittelbar wegen Verletzung des Streitpatents in Anspruch genommen wird noch Zulieferin ist, kann ein Rechtsschutzinteresse an der Fortführung der Nichtigkeitsklage nicht abgesprochen werden. Nach der BGH-Entscheidung „Tafelförmige Elemente“ (BGH GRUR 1995, 342), auf die die Beklagte verweist, lässt sich das erforderliche Rechtsschutzinteresse nicht allein damit begründen, dass der Kläger Mehrheitsgesellschafter einer GmbH ist, die wegen Verletzung des Schutzrechts in Anspruch genommen wird. Die vorliegenden Umstände sind damit aber nicht vergleichbar, da es um arbeitsteiliges Vorgehen im Konzern geht.

173 Die Klägerin zu 2 gehört zum N…-Konzern und verfügt nach eigenen Angaben, an deren Richtigkeit der Senat keinen Anlass hatte zu zweifeln, über eine Rechtsabteilung für Rechtsangelegenheiten des Konzerns für Europa, und hat es im N…-Konzern übernommen, die vorliegende Nichtigkeitsklage zu betreiben, um die wegen Patentverletzung in Anspruch genommene Klägerin zu 5 als Beklagte im parallelen Verletzungsverfahren vor dem Landgericht Mannheim (Aktenzeichen …) zu verteidigen. Die hiesige Beklagte hat als Verletzungsklägerin in ihrer Klageschrift vom 25. Mai 2018 (Anlage NK7 zum Verfahren 7 Ni 35/19 (EP)) insoweit selbst vorgetragen (Seiten 17, 18), dass in die Spielkonsole „Nintendo Switch“, als deren Vertreiberin in Deutschland die Klägerin zu 5 verklagt wird, das Ein-Chip-System N… T210 (N… Tegra X1) des „Chipherstellers N… verbaut“ sei und das genannte Ein-Chip-System alle Merkmale des Streitpatents verwirkliche. Ungeachtet einer näheren Auseinandersetzung mit der im konkreten Einzelfall gewählten Form arbeitsteiligen Zusammenwirkens im Konzern ist das auch nach Patentablauf bestehende rechtliche Interesse des Chipherstellers, die Inanspruchnahme einer Abnehmerin abzuwenden – die Verletzungsklage gegen die Abnehmerin ist weiterhin anhängig -, der Klägerin zu 2 hier zuzurechnen, da sie als mit dem Chiphersteller verbundenes Unternehmen nur zu diesem Zweck die Nichtigkeitsklage erhoben hat (vgl. zur Berücksichtigung verbundener Unternehmen BGH GRUR 2021, 42, Rn. 9 – Truvada). Eine Verzichtserklärung, die das Rechtsschutzinteresse in der gegebenen Situation hätte entfallen lassen können, hat die Beklagte nicht abgegeben (vgl. BGH GRUR 2020, 1284, Rn. 51 – Datenpaketumwandlung; GRUR 2010, 1084 – Windenergiekonverter).

174 Hinsichtlich der Klägerin zu 5 ergibt sich das erforderliche Rechtsschutzinteresse ohne Weiteres daraus, dass sie die Verletzungsbeklagte in dem oben unter 1.2 bezeichneten Verletzungsverfahren vor dem Landgericht Mannheim ist.

206 Zum Begriff Textur bzw. Struktur

207 Für den englischen Begriff texture im Original des Streitpatents verwendet die zugehörige T2-Schrift den Begriff Struktur. Beide Begriffe betreffen denselben Bedeutungsinhalt: eine Textur bezeichnet in der Computergrafik in der Regel einen „Überzug“ für ein 3D-Modell eines Objekts, der die Beschaffenheit der Objektoberfläche beschreibt und dem Objekt eine Oberflächenstruktur verleiht. Insoweit entspricht eine Textur gleichzeitig einer Struktur. Ausgehend vom Streitpatent in der englischen Originalfassung wird im Folgenden abweichend von der T2-Schrift der technisch zutreffendere Begriff Textur anstelle von Struktur verwendet.

208 Zum Begriff Fragment

209 Um Objekte auf dem Display eines Grafiksystems anzuzeigen, wird jedes Objekt in eine Vielzahl von Polygonen aufgeteilt (Streitpatentschrift, Abs. [0003]). Jedes der Polygone bedeckt oder schneidet eine bestimmte Anzahl von Pixeln in der Anzeige. Die Daten für einen Abschnitt eines Polygons, das ein bestimmtes Pixel schneidet, werden als Fragment für dieses Polygon und dieses Pixel bezeichnet (Streitpatentschrift, Abs. [0004], siehe „Data for a portion of a polygon which intersects a particular pixel is termed the fragment for that polygon and that pixel.”). Jedes Polygon beinhaltet gewöhnlich eine Mehrzahl von Fragmenten, wobei jedes Fragment Daten beinhaltet, die dasjenige Pixel betreffen, in dem das jeweilige Fragment liegt. Laut Streitpatent umfasst ein Fragment Informationen bezüglich Farbe, Mischungsmodi und Textur (Abs. [0004]). Zwar korrespondiert ein Fragment mit einem Pixel, d. h. einem auf der Anzeige angeordneten Bildpunkt, jedoch handelt es sich dabei nicht schon um ein zur Anzeige bereites Pixel, sondern um eine Art Vorstufe, die diejenigen Daten beinhaltet, die zur Berechnung und Darstellung eines Pixels benötigt werden (Streitpatentschrift, Abs. [0004], [0014]).

210 Zum Begriff Textur- bzw. Strukturabschnitt

211 Einem Fragment ist gemäß dem Streitpatent eine Textur zugeordnet (Abs. [0005], siehe „texture for the fragment“), die als eine weitere Farbe für das Fragment angesehen werden kann und aus einer Texturkarte (texture map) abgeleitet wird. Diese Textur wird mit der Farbe des Fragments zusammengemischt, um einen endgültigen Farbwert für das Fragment zu erhalten. Zu diesem Zweck ruft das Grafiksystem einen bestimmten Abschnitt der Textur ab, der üblicherweise einem Pixel entspricht und als Elementarmuster die grundlegende Einheit der Textur in der Computergrafik bildet. Ein solcher Texturabschnitt – auch Texel genannt – beinhaltet laut Streitpatent einen Farb- und einen Alpha-Wert, der eine Transparenzinformation für einen Bildpunkt bzw. ein Pixel angibt (Streitpatentschrift, Abs. [0005]).

212 Zum Begriff Programm

213 Anspruchsgemäß steuert ein Programm die Texturverarbeitung auf einer Mehrzahl von Texturprozessoren (Streitpatentschrift, Abs. [0033]). Infolge dieses Programms können die Texturprozessoren an verschiedene Mischoperationen angepasst werden (Streitpatentschrift, Abs. [0036]). Der Fachmann versteht unter dem Programm ganz allgemein eine in einer bestimmten Programmiersprache oder in Maschinencode festgelegte Abfolge von Anweisungen bzw. Instruktionen, die zur Texturverarbeitung auf den Texturprozessoren ausgeführt werden.

214 Zur Lehre des erteilten Patentanspruchs 1

215 Der Patentanspruch 1 lehrt ein System, das der Verarbeitung von Texturen für eine Grafikabbildung auf einer Anzeige dient. Dabei umfasst die Grafikabbildung ein Objekt, das sich aus einer Mehrzahl von Fragmenten zusammensetzt (Merkmal M1).

216 Im Streitpatent bildet das System einen Teil der Image Generating Unit 120, die eine Grafikabbildung auf einer Anzeige erzeugt (Streitpatentschrift, Abs. [0027], Fig. 6). Das System selbst wird als Textureinheit 150 (texture unit) bezeichnet. Das darzustellende Objekt wird durch eine Mehrzahl von Fragmenten bestimmt, wobei die Daten eines Fragments die Farbe, die Textur, den Alpha-Wert und Tiefenwerte eines bestimmten Polygons und Pixels betreffen (Streitpatentschrift, Abs. [0014]).

217 Merkmal M1.1 besagt, dass das beanspruchte System über eine Mehrzahl von Texturprozessoren verfügt, die der Verarbeitung eines Teils der Mehrzahl der Fragmente dienen. In der bevorzugten Ausführungsform weist ein Texturprozessor eine bitweise Logik, einen Multiplexer/Akkumulator und eine Summierungseinheit auf (Streitpatentschrift, Abs. [0049], Fig. 11A).

218 Gemäß Merkmal M1.2 umfasst das System einen Speicher, der der Hinterlegung eines Teils eines Programms zur Verarbeitung einer Mehrzahl von Texturabschnitten dient. Als Speicher kommt jede Art von Speicher unabhängig von seiner Lage innerhalb des Systems in Frage (vgl. Streitpatentschrift, Abs. [0033]). So kann es sich bei dem Speicher laut Streitpatent etwa um einen Zwischenspeicher (Fig. 9, Program Cache 160) oder einen Festplattenspeicher handeln (Fig. 6, Memory 110). Weiterhin wird in Absatz [0042] der Streitpatentschrift ausgeführt, dass der Zwischenspeicher das komplette Programm zur Texturverarbeitung beinhaltet. Alternativ wird vorgeschlagen, dort nur einen Teil des Programms vorzuhalten. Der erteilte Patentanspruch 1 verlangt allerdings nicht, dass im Speicher nur ein Teil des Programms hinterlegt sein muss; der Patentanspruch 1 schließt nicht aus, dass der Speicher mehrere, z. B. auch sämtliche Teile des Programms umfasst und nicht bloß einen einzigen Teil davon. Zur Texturverarbeitung können die einzelnen Teile des anspruchsgemäßen Programms in gleichwirkender Weise sowohl auf einem einzigen Speicher untergebracht als auch über eine Mehrzahl von Speichern verteilt sein.

219 In Merkmal M1.3 wird beansprucht, dass der Teil des Programms eine Mehrzahl von Anweisungen beinhalten soll. Bei den Anweisungen handelt es sich um beliebige Anweisungen, die an die Texturprozessoren übergeben werden und die Texturverarbeitung von Fragmenten steuern.

220 Merkmal M1.4 besagt, dass die Mehrzahl der Texturprozessoren an den Speicher gekoppelt ist. Laut Streitpatent können die Texturprozessoren und der Speicher über einen Distributor und einen Argument Decoder miteinander verknüpft sein (Streitpatentschrift, Abs. [0032], [0039], Fig. 7, 9). Beide Komponenten sind dafür verantwortlich, dass die Anweisungen des im Speicher hinterlegten Programms an die Texturprozessoren verteilt werden. Allerdings ist Merkmal M1.4 nicht auf eine solche indirekte Verknüpfung beschränkt. Vielmehr sind sämtliche physikalische Verbindungen mit umfasst, die das Laden von Anweisungen aus dem Speicher in die Texturprozessoren erst ermöglichen.

221 Weiterhin ist jeder der Texturprozessoren dazu ausgelegt, einen Teil der Texel zu verarbeiten, wobei diese Texel zu einem Fragment gehören (Merkmal M1.5). Dem Anspruchswortlaut nach kann es sich bei dem zu verarbeitenden Teil der Texel auch um nur ein einziges Texel handeln.

222 Außerdem sollen die Texturprozessoren in der Lage sein, die Texturverarbeitung parallel durchzuführen. So sind die Texturprozessoren gemäß Merkmal M1.6 dazu eingerichtet, einen zweiten Teil der Texel parallel zu verarbeiten. Der Fachmann wird Merkmal M1.6 so verstehen, dass sich der „zweite Teil der Texel“ von dem in Merkmal M1.5 genannten Teil dadurch unterscheidet, dass er andere Texel einer Texturkarte desselben Fragments betrifft oder aber überhaupt zu einem anderen Fragment gehört. Wie sich den Ausführungen in Absatz [0032] der Streitpatentschrift entnehmen lässt, sollen die Texturprozessoren die Texel für die entsprechenden Fragmente verarbeiten. Demnach führt jeder Texturprozessor die gesamte Texturverarbeitung für das Fragment oder die Fragmente durch, das bzw. die er erhält. Alternativ kann ein Texturprozessor auch nur einen Teil der Texturverarbeitung für ein Fragment durchführen, wobei der Rest der Texturverarbeitung von einem anderen Texturprozessor übernommen wird (Streitpatentschrift, Spalte 9, Zeilen 40 bis 45). Merkmal M1.6 ist demnach bereits dann erfüllt, wenn die Texturprozessoren mehrere Texel parallel verarbeiten können unabhängig davon, ob sie zum selben Fragment gehören oder nicht. Allerdings ist Patentanspruch 1 so zu verstehen, dass in Übereinstimmung mit Merkmal M1 die parallel verarbeiteten Texel zu Fragmenten desselben Objekts gehören.

223 In Merkmal M1.7 wird beansprucht, dass die mehreren Texturprozessoren einen Teil der Anweisungen „implementieren“. Damit ist – entsprechend der Bedeutung des englischen Verbs „to implement“ (zu Deutsch „durchführen“, „umsetzen“, „verwirklichen“, „erfüllen“) – gemeint, dass die Texturprozessoren in der Lage sind, Programmanweisungen auszuführen, und dass ein vom Benutzer erstellter Programmcode auf die Texturprozessoren übertragen werden kann, der vorgibt, was diese ausführen sollen.

248 In diesem Zusammenhang führt die Beklagte aus, dass die Druckschrift NK12 zwar an manchen Stellen von „user-programmable shading“ (Seite 57, linke Spalte, letzter Absatz, Zeile 4; Seite 57, rechte Spalte, vierter Absatz, Zeile 4) spreche, die Texturierung werde dabei aber klar eigenständig/separat und ohne den Zusatz „user-programmable“ erwähnt. Bereits daraus ergebe sich, dass die Programmierbarkeit gemäß der Druckschrift NK12 allenfalls auf ein Shading im engeren Sinne bezogen ist, also die Anwendung von Licht und Schatten. Ein konkretes Beispiel einer „programmierbaren“ Texturierung/Texturmischung sei in der Druckschrift NK12 nicht zu finden.

249 Der Einwand vermag nicht zu überzeugen.

250 So wird zwar die Eigenschaft „user-programmable“ bzw. „benutzerprogrammierbar“ in der Druckschrift NK12 zusammen mit „Shading“ verwendet. Jedoch vermag dies allein noch keine abschließende Aussage darüber zu machen, ob und in welchem Maß die in PixelFlow realisierte Texturverarbeitung programmierbar war. Hingegen zeigt die Druckschrift NK12 sehr wohl, dass die Texturverarbeitung in den einzelnen Verarbeitungselementen (PE) und TASICs durch Programmanweisungen des Geometry Processor Boards gesteuert wird (Seite 64, linke Spalte, Abschnitt „Rasterizer Control“); dabei wird auf die Programm-Routinen der OpenGL-Bibliothek zurückgegriffen, welche keinen „starren“ Funktionsumfang haben, sondern grundsätzlich angepasst und erweitert werden können. In diesem Umfang ist deshalb die Texturverarbeitung „programmierbar“ (vgl. S. 65 rechte Spalte, Abschnitt „PixelFlow OpenGL“, erster Absatz „… to demonstrate programmability in the hardware pipeline“, mit Verweis auf die NK13).

251 Nach Auffassung der Beklagten ist der Druckschrift NK12 an keiner Stelle zu entnehmen, dass speziell die Texturmischung in irgendeiner Form über die herkömmlichen, im Streitpatent gewürdigten algebraischen Operationen hinausgeht. Dieses Dokument enthalte keinerlei Details, aus denen geschlossen werden könne, dass für die Texturierung mehr als lediglich Parameterwerte bzw. Operanden zur Berechnung übergeben werden. Ferner könne sich die Nutzer-Programmierbarkeit der Druckschrift NK12 nur auf OpenGL-Version 1.0 beziehen. In dieser OpenGL-Version sei aber eine Programmierbarkeit der Texturierung bzw. des Texturmischens überhaupt nicht möglich gewesen.

252 Diese Argumentation ist ebenfalls nicht überzeugend.

253 Vielmehr kann aufgrund der Verwendung der OpenGL API auch auf eine programmierbare Texturverarbeitung geschlossen werden (Seite 65, rechte Spalte, Abschnitt „PixelFlow OpenGL“, zweiter Absatz), bei der es sich aus Sicht des Senats allerdings nicht um eine freie sondern eher um eine teilweise bzw. eingeschränkte Programmierbarkeit handelt, die sich maßgeblich auf die in der API implementierten Funktionen stützt. Nichts Anderes trifft auf die in der Druckschrift NK12 angesprochene OpenGL-Programmierschnittstelle der Version 1.0 zu. Dabei ist davon auszugehen, dass eine Programmierbarkeit i. S. d. Streitpatents nicht notwendigerweise voraussetzt, dass die beanspruchte Vorrichtung frei programmierbar ist oder unbeschränkt angepasst werden kann, so dass dieser Programmierbarkeit keine technischen Grenzen gesetzt sind. Die OpenGL API eröffnet dem Benutzer z. B. die Möglichkeit, Funktionen für bump mapping und mip mapping in ein verteiltes Anwendungsprogramm nach dem Client-/Server-Modell einzubinden und dieses auf „PixelFlow“ auszuführen (Seite 63, rechte Spalte, vorletzter Absatz). Bump mapping und mip mapping stellen bekanntlich prominente Beispiele für Spezialfälle einer Texturverarbeitung dar. Das Einbinden der entsprechenden Softwarekomponenten aus der OpenGL-Programmierschnittstelle in einen Programmcode zur Darstellung komplexer Grafik belegt, dass das in Druckschrift NK12 beschriebene System „als solches“ programmierbar war – wenn auch nicht unmittelbar aus einem beliebigen Grafikprogramm heraus, sondern nur über den Rückgriff auf die OpenGL-Programmbibliothek; diese wiederum war aber grundsätzlich anpassbar und änderbar.

254 In Hinblick auf die für die arithmetisch-logischen Einheiten (ALUs) der Verarbeitungselemente (PE) bereitgestellten Mikroanweisungen argumentiert die Beklagte, dass diese vom Geometrie-Prozessor ausgegeben würden (Seite 64, linke Spalte, Abschnitt „Rasterizer Control“, erster Absatz) und daher gerade nicht die Anweisungen eines in einem Speicher gespeicherten Programms gemäß den Merkmalen M1.2 und M1.5 sein könnten.

255 Auch dieser Einwand hält einer genaueren Überprüfung nicht stand.

256 So sind die vom Geometry Processor (GP) an den SIMD-Prozessor und das Textur-Subsystem ausgegebenen Programmanweisungen im SDRAM gepuffert (Fig. 4; Seite 60, rechte Spalte, dritter Absatz „Memory … buffering commands for the rasterizer“). Wenigstens bei einem Teil dieser Programmanweisungen handelt es sich um solche für eine Texturverarbeitung, welche laut Druckschrift NK12 auf der Verarbeitung einer Mehrzahl von Texeln beruht (Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, erster Absatz, siehe „The shaders look up texture values for the pixels and compute final pixel color values …“).

257 Der Fachmann wird unschwer erkennen, dass es sich bei den gespeicherten Programmanweisungen um eine Abfolge von Instruktionen und somit um ein Programm bzw. den Teil eines Programms handelt. Dieses geht wiederum auf kleine Unterprogramme zurück, die auf einer Host Workstation hinterlegt sind, dort ablaufen und Funktionen der OpenGL API aufrufen (Seite 66, linke Spalte, zweiter Absatz). Die Funktionsaufrufe werden an die jeweiligen Shader verteilt und auf deren Geometry Processors (GP) ausgeführt, wobei der Code für die jeweiligen SIMD-Prozessoren generiert wird (Seite 66, linke Spalte, zweiter und dritter Absatz). Der anspruchsgemäße Speicher gemäß Merkmal M1.2 ist damit in der Lehre der Druckschrift NK12 in Gestalt des SDRAM verwirklicht.

272 Gemäß Hilfsantrag I wurde Merkmal M1 des erteilten Patentanspruchs 1 in Merkmal M1´ mit der Maßgabe abgeändert, dass sich das beanspruchte System auf eine Bereitstellung von programmierbarer Texturverarbeitung bezieht. Weiterhin wurde Merkmal M1.8 eingeführt, wonach die Verarbeitung eines Teils der Texel für ein Fragment entsprechend dem Programm ein Texturmischen („texture blending“) beinhaltet.

273 Der unabhängige Patentanspruch 8 wurde entsprechend angepasst.

274 Entsprechend dem Verständnis des Streitpatents umfasst ein Texturmischen bzw. texture blending eine Operation, bei der eine Textur mit einer Farbe oder einer anderen Textur beispielsweise durch Interpolation vermischt bzw. kombiniert wird (vgl. Streitpatentschrift, Abs. [0005], [0006] und [0020]).

275 Die Merkmale M1´ und M1.8 sind aus Druckschrift NK12 bekannt.

276 Bereits zum Hauptantrag ist ausgeführt, dass das PixelFlow-System der Druckschrift NK12 eine – wenn auch eingeschränkte – Programmierbarkeit der Texturverarbeitung ermöglichte (Merkmal M1´).

277 Weiterhin ergibt sich aus den in der Druckschrift NK12 genannten Techniken der Bildsynthese, z. B. bump mapping oder mip mapping (Seite 63, rechte Spalte, vorletzter Absatz), dass das Texturmischen eine von PixelFlow unterstützte Art der Texturverarbeitung darstellte. So entnimmt der Fachmann der Druckschrift NK12, dass die genannten Techniken Operationen vorsehen, bei denen Texturen mit den Farbwerten von Fragmenten gemischt werden, um endgültige Farbwerte zu bekommen (vgl. NK12, Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz, siehe „The shaders look up texture values for the pixels and compute final pixel color values, based on surface normal, light sources, etc.“ – Merkmal M1.8).

278 Die Beklagte argumentiert, die Druckschrift NK12 gebe keinen Hinweis, wie ein Texturmischen durchgeführt, geschweige denn wie ein solches programmiert werden könne. Das unter Abschnitt 3.3 der Druckschrift NK12 beschriebene mip mapping betreffe allenfalls texture lookups, zeige aber kein programmierbares Texturmischen.

279 Zwar ist der Beklagten darin zuzustimmen, dass mip mapping für sich gesehen kein programmierbares Texturmischen umfasst. Um die Darstellungsqualität von Bildern bzw. Texturen zu verbessern, wenn diese kleiner als in der ursprünglichen Größe dargestellt werden sollen, sieht mip mapping nach fachmännischem Verständnis vielmehr vor, verschiedene Versionen eines originalen Bildes, sogenannte MipMap Levels in Form von Texturkarten im Speicher abzulegen, welche in der Regel jeweils um einen Faktor 2 verkleinert sind. Durch anschließende texture lookups werden dann ausgehend von Texturkoordinaten aus den MipMap-Texturkarten Farbwerte ermittelt, die einer weiteren Texturverarbeitung bereitgestellt werden. Dass diese Farbwerte als Texturwerte einem Texturmischen zugeführt werden, ergibt sich bereits aus der oben genannten Textstelle auf Seite 59 unter Abschnitt 2.5 der Druckschrift NK12. Dort wird beschrieben, dass spezifische Pixelattribute, z. B. Farben von Oberflächen, von den Verarbeitungselementen (PE) der Shader zusammen mit Texturwerten zu endgültigen Pixelwerten bzw. -farben verarbeitet – also gemischt – werden (siehe „PixelFlow rasterizers do not compute pixel colors directly; instead, they compute geometric and intrinsic pixel attributes, such as surface-normal vectors and surface color; these attributes, not pixel colors, are composited. … The shaders look up texture values for the pixels and compute final pixel color values, based on surface normal, light sources etc.”). Im Übrigen ist dem Fachmann geläufig, dass die von texture lookups unterstützten Funktionen, wie bump mapping (Simulation von Oberflächenunebenheiten) oder environment mapping (Simulation spiegelnder Oberflächen) (vgl. NK12, Seite 63, rechte Spalte, vorletzter Absatz) gewöhnlich mit einem Texturmischen verknüpft sind.

280 Unter Berücksichtigung der Ausführungen zum Hauptantrag unterstützt PixelFlow demnach nicht nur eine programmierbare Texturverarbeitung (vgl. Merkmal M1´), sondern auch ein Texturmischen (vgl. Merkmal M1.8). Dass die Druckschrift NK12 nicht beschreibt, wie ein Texturmischen durchgeführt oder gar programmiert werden kann, ist in diesem Zusammenhang ohne Belang, da mit Merkmal M1.8 allenfalls beansprucht wird, dass ein Texturmischen überhaupt stattfinden soll.

281 Mit Rücksicht auf die Ausführungen zum Hauptantrag ist die Lehre des Patentanspruchs 1 gemäß Hilfsantrag I nicht neu und daher nicht patentfähig. Mit dem Patentanspruch 1 fällt der gesamte Hilfsantrag.

282 Beantragt der Patentinhaber, das Patent in beschränktem Umfang mit einem bestimmten Anspruchssatz oder bestimmten Anspruchssätzen aufrechtzuerhalten, rechtfertigt es grundsätzlich die Ablehnung des gesamten Antrags, wenn sich auch nur der Gegenstand eines Patentanspruchs aus dem vom Patentinhaber verteidigten Anspruchssatz als nicht patentfähig erweist (vgl. BGH GRUR 2007, 862 – Informationsübermittlungsverfahren II). Allerdings ist das Gericht gehalten, aufzuklären, in welchem Verhältnis die Hilfsanträge zu einem nicht ausdrücklich formulierten Petitum stehen sollen, einem formal vorrangigen Antrag nur teilweise zu entsprechen (BGH GRUR 2017, 57 - Datengenerator).

283 Im vorliegenden Fall hat die Beklagte nur die Patentansprüche 1 und 8 des Hilfsantrags VII, eingereicht mit Schriftsatz vom 21. September 2020, ausdrücklich einzeln vereidigt. Im Übrigen hat sie sich der Erklärung des Senats in der mündlichen Verhandlung angeschlossen, er verstehe die von der Beklagten vorgelegten Hilfsanträge grundsätzlich im Sinne geschlossener Anspruchssätze, die sie jeweils in ihrer Gesamtheit beanspruche. Vorbehaltlich der für Hilfsantrag VII beantragten Ausnahme, also für alle übrigen Hilfsanträge einschließlich des Hilfsantrags I, schließt dies eine separate Betrachtung einzelner Patentansprüche aus, wenn sich ein Patentanspruch des betroffenen Anspruchssatzes, wie hier, als nicht patentfähig erweist.

285 Der Hilfsantrag II beruht auf dem Hilfsantrag I, wobei Merkmal M1.9 bzw. M8.3.5 in Patentanspruch 1 bzw. 8 aufgenommen worden ist. Demnach sollen die Texturprozessoren in der Lage sein, sich auf unterschiedliche Eingaben hin an unterschiedliche Mischoperationen anzupassen.

286 Ausgehend von Seite 12, Zeilen 26 bis 29 der Anlage NK2 und den Absätzen [0035] und [0036] der Streitpatentschrift ist Merkmal M1.9 bzw. M8.3.5 so zu verstehen, dass aufgrund des anspruchsgemäßen Programms zur Texturverarbeitung die Texturprozessoren in der Lage sein sollen, in Abhängigkeit von unterschiedlichen Eingaben unterschiedliche Mischoperationen auszuführen.

287 Die Lehre des Patentanspruchs 1 gemäß Hilfsantrag II hat ausgehend von der Druckschrift NK12 nahegelegen.

288 So gibt die OpenGL-Programmieranleitung NK55 der Version 1.2.1 vom 14. Oktober 1998 Hinweise, wie ein „Blending“ (Seiten 146ff) programmiert werden kann oder welche Funktionen für ein Multitexturing angewandt werden können (Seiten 240ff).

289 Insbesondere werden in Druckschrift NK55 auf den Seiten 136 und 137 diejenigen Funktionen beschrieben, die in Abhängigkeit von der Anzahl der Farbanteile der Textur und dem Texturmodus (REPLACE, MODULATE, DECAL, BLEND) verschiedene Mischoperationen ausführen können, in denen Fragmentfarbe und Texturfarbe kombiniert werden. Zum besseren Verständnis sei an dieser Stelle außerdem auf die Druckschrift NK57 hingewiesen, die auf Seite 204 die unter der OpenGL-Version 1.1 verfügbaren Funktionen zur Texturmischung näher erläutert.

290 Die Druckschrift NK55 offenbart damit zumindest die zum Prioritätstag des Streitpatents unter OpenGL verfügbaren Funktionen zur Texturverarbeitung, die ganz konkret verschiedene Mischoperationen in Abhängigkeit von verschiedenen Eingaben realisieren. Da der Fachmann stets bestrebt ist, in einem System zur Bildsynthese die aktuellsten Softwarebibliotheken zu verwenden, lag es für ihn auf der Hand, auch im OpenGL-basierten PixelFlow-System der Druckschrift NK12 die neueste Version der OpenGL API mit der größtmöglichen Funktionalität anzuwenden. Die Verarbeitungselemente eines solchen angepassten PixelFlow-Systems, die als Texturprozessoren fungieren, sind dann in der Lage, verschiedene Mischoperationen an Fragmenten und Texturen durchzuführen, und zwar in Abhängigkeit von verschiedenen Eingaben, wie etwa Farbanteilen der Textur und Texturmodi (Merkmal M1.9).

291 Die Beklagte macht geltend, dem PixelFlow-System der Druckschrift NK12 liege allenfalls OpenGL-Version 1.0 zugrunde, das keine benutzerprogrammierbare Texturverarbeitung erlaube. Letzteres gelte ebenso für die OpenGL-Version 1.2.1 aus Druckschrift NK55.

292 Der Einwand der Beklagten geht bereits deswegen fehl, weil PixelFlow OpenGL um Extensions erweitert worden ist, die eine Programmierbarkeit dadurch unterstützten, dass benutzercodierte Funktionen für Shading- und Beleuchtungsmodelle in Anwendungen eingebunden werden konnten. Die Extensions ermöglichen insbesondere, Werte für benutzerdefinierte Parameter, z. B. Texturkoordinaten festzulegen, die sich von Primitiv zu Primitiv ändern können (vgl. NK12, Seite 65, rechte Spalte, Abschnitt 4.1, zweiter Absatz), was sich wiederum auf die Texturverarbeitung und das Texturmischen auswirkt. Nichts Anderes gilt nach Auffassung des Senats für ein PixelFlow-System, das sich auf OpenGL-Version 1.2.1 mit Extensions stützt. Dass eine Verwendung von OpenGL- Version 1.2.1 unter PixelFlow zum Prioritätstag des Streitpatents grundsätzlich möglich gewesen sein muss, ergibt sich bereits aus der Tatsache, dass nahezu alle Komponenten von PixelFlow programmierbar waren (vgl. NK12, Seite 67, rechte Spalte, Abschnitt 6, zweiter Absatz, siehe „Virtually all of the components of PixelFlow are programmable: …“) und PixelFlow auch auf Rechenanlagen mit vielen Ressourcen implementiert werden konnte (vgl. NK12, Seite 67, rechte Spalte, Abschnitt 6, dritter Absatz, siehe „Coupled to a parallel supercomputer, it can serve as a visualization subsystem for immediate-mode rendering.“).

293 Die Beklagte argumentiert, der Spezifikation NK55 sei allenfalls ein begrenzter mathematischer Funktionensatz für ein Texturmischen zu entnehmen (vgl. NK55, Seite 137), der keine Programmierbarkeit der Texturverarbeitung gestatte.

294 Zwar ist die Anzahl der unter der OpenGL-Version 1.2.1 für ein Texturmischen zur Verfügung stehenden mathematischen Texturfunktionen ersichtlich begrenzt (vgl. NK55, Seite 137, Tabelle 3.19, siehe „Decal and blend texture functions“). Die Programmierbarkeit der Texturverarbeitung beruht aber – entgegen der Auffassung der Beklagten – zum einen auf der Möglichkeit, OpenGL Extensions auch unter OpenGL-Version 1.2.1 bereitzustellen, die entsprechend der Lehre der Druckschrift NK12 benutzerindividuellen Programmcode einbinden können, der die Texturverarbeitung betrifft (vgl. NK12, Seite 65, Abschnitt 4.1). Zum anderen resultiert die Programmierbarkeit der Texturverarbeitung schon aus der Tatsache, eine Mehrzahl von OpenGL-Aufrufen in eine Anwendung einbinden zu können, die die Definition von Texturen (vgl. NK55, Seite 112ff, Abschnitt 3.8.1), die Festlegung von Texturparametern (vgl. NK55, Seite 123ff, Abschnitt 3.8.3) und die Anwendung von Texturen steuern (vgl. NK55, Seite 135ff, Abschnitt 3.8.9), wodurch eine Auswahl aus den oben genannten Funktionen für das Texturmischen getroffen wird. Dabei gehört es zum fachmännischen Wissen und Können, im PixelFlow-System der Druckschrift NK12 dafür Sorge zu tragen, dass die bei jedem OpenGL-Aufruf anfallende Arbeitslast zwischen Host Workstation und modularem Grafiksystem unter dem Gesichtspunkt der Performanz in geeigneter Weise aufgeteilt wird.

295 Damit ist auch der Patentanspruch 1 in der Fassung des Hilfsantrags II nicht patentfähig. Mit dem Patentanspruch 1 fällt der gesamte Hilfsantrag.

297 Der Hilfsantrag III basiert auf dem Hilfsantrag I, wobei das zusätzliche Merkmal M1.9´ bzw. M8.3.5´ in die unabhängigen Patentansprüche aufgenommen worden ist. Demnach sollen die Texturprozessoren derart angepasst werden können, dass sie eine Vielfalt von Texturmischungen durchführen können.

298 Aus der Druckschrift NK12 folgt, dass das dort offenbarte PixelFlow-System aufgrund der OpenGL API programmierbar war. Außerdem war das bekannte System nicht auf die Anwendung einer einzigen Textur auf Fragmente eingeschränkt (vgl. NK12, Seite 63, rechte Spalte, Abschnitt 3.3, erster und zweiter Absatz, siehe „Mip-map texture lookups“; Seite 63, rechte Spalte, Abschnitt 3.3, vorletzter Absatz, siehe „bump mapping“ u. a.). Weiterhin war ein auf der OpenGL- Version 1.2.1 basierendes PixelFlow-System dank der im OpenGL-Standard bereitgestellten Texturfunktionen (s. o.) derart programmierbar bzw. anpassbar, dass nicht nur eine, sondern eine Vielfalt an Texturmischungen ausgeführt werden konnte (Merkmal M1.9´).

299 Die Beklagte führt aus, dass aus den Druckschriften NK12 und NK55 keine Vielzahl von Texturmischungen i. S. d. Merkmals M1.9´ hervorgehe.

300 Der Einwand überzeugt nicht.

301 So offenbart die Druckschrift NK12, dass in PixelFlow grundsätzlich eine Mehrzahl von Texturen mit mip mapping angewendet werden konnte (vgl. NK12, Seite 63, Abschnitt 3.3, zweiter Absatz, siehe „Prefiltered (Mip-map) texture maps can be interleaved across the banks so that eight texels required for one pixel are stored in the eight separate banks.“), was bei vorgefilterten MipMap Levels je nach Textur und Auflösung zu unterschiedlichen Texturmischungen führte. Außerdem geht aus der Spezifikation NK55 hervor, dass die mathematischen Mischfunktionen der Tabellen 3.18 und 3.19 auf den Seiten 136 und 137 für ein und dieselbe auf ein Fragment angewandte Textur unterschiedliche Texturmischungen hervorbringen. In diesem Sinne hat ein auf OpenGL-Version 1.2.1 basierendes PixelFlow-System die Eigenschaft, eine Vielfalt von Texturmischungen durchzuführen.

302 Mit Rücksicht auf die Ausführungen zu Hilfsantrag I ist der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag III nicht patentfähig. Mit dem Patentanspruch 1 fällt der gesamte Hilfsantrag. Der Hilfsantrag III ist nach allem nicht günstiger zu beurteilen als der Hilfsantrag I.

304 Der Hilfsantrag IV beruht auf Hilfsantrag I, wobei die Merkmale M1.2 und M1.5 durch die Merkmale M1.2´ und M1.5´ ersetzt worden sind. Laut Merkmal M1.2´ soll der in einem Speicher hinterlegte Teil eines Programms von der Mehrzahl der Texturprozessoren zur Texturverarbeitung genutzt werden. Gemäß Merkmal M1.5´ ist jeder der Texturprozessoren dazu vorgesehen, wenigstens einen Teil des Programms zu importieren und einen Teil der Mehrzahl der Texturabschnitte bzw. Texel für ein Fragment gemäß dem Programm zu verarbeiten.

305 Der Fachmann wird das Teilmerkmal „importing at least a portion of the program“ so verstehen, dass wenigstens ein Teil eines Programms von den Texturprozessoren eingelesen bzw. geladen wird, um dann eine Texturverarbeitung auszuführen. Eine solche Auslegung findet ihre Stütze in Absatz [0043] (siehe „Using instructions stored in the program cache 160, a texture processor 190-1 through 190-k processes a fragment.“) und Absatz [0033] der Streitpatentschrift (siehe „… the program used by a texture processor 154-1 through 154-k may be imported from the memory 110.“).

306 Diese Maßnahmen können jedoch eine Patentfähigkeit nicht begründen.

307 So offenbart Druckschrift NK12 in Figur 5, dass ein EMC-Chip und damit auch die jeweiligen Verarbeitungselemente (PE) (die ja als Texturprozessoren fungieren) Programmanweisungen („instructions“) erhalten. Die jeweils zu verarbeitende Textur wird von einem Verarbeitungselement (PE) über den „Input Buffer“ geladen (vgl. NK12, Fig. 5, 6; Seite 63, rechte Spalte, erster und zweiter Absatz).

308 Weiterhin geht – wie bereits zum Hauptantrag ausgeführt - aus der Druckschrift NK12 hervor, dass die vom Geometry Processor (GP) erzeugten und im SDRAM zwischengespeicherten Programmanweisungen über die Controller-IGCs an die Verarbeitungselemente (PE) ausgegeben werden. Die Anweisungen werden von diesen geladen bzw. importiert und demnach auch zur Texturverarbeitung verwendet (vgl. NK12, Seite 64, linke Spalte, Abschnitt 3.4, erster und zweiter Absatz, siehe „It provides the SIMD micro-instruction to the PEs.“).

309 Mit Rücksicht auf die Ausführungen zum Hauptantrag bzw. Hilfsantrag I sind die Merkmale M1.2´ und M1.5´ damit aus der Druckschrift NK12 bekannt.

310 Die Beklagte führt aus, in der Lehre der Druckschrift NK12 werde keine Mehrzahl von Programmanweisungen an die Verarbeitungselemente PEs übergeben. Dementsprechend werde dort auch kein Programmteil geladen und ausgeführt.

311 Der Einwand greift nicht durch. So geht aus Druckschrift NK12 unmittelbar hervor, dass die vom Geometry Processor GP ausgegebenen Mikrobefehle mittels eines Controller-IGC an die SIMD-Prozessoren bzw. deren Verarbeitungselemente (PE) weitergeleitet werden. Ein Mikrobefehl beinhaltet dabei u. a. Steuerfelder für die arithmetisch-logische Einheit ALU eines Verarbeitungselements (PE) sowie die Adresse von dessen lokalem Speicher (vgl. NK12, Seite 64, linke Spalte, Abschnitt 3.4, zweiter Absatz). Nach fachmännischem Verständnis stellt der Mikrobefehlsstrom eine Abfolge von Programmanweisungen dar, die zusammen einen Programmteil bilden und die auf den Verarbeitungselementen (PE) der SIMD-Prozessoren zur Ausführung gebracht werden.

312 Da sich auch die Merkmale M1´ und M1.8 aus der Druckschrift NK12 ergeben (siehe Ausführungen zu Hilfsantrag I), fehlt es dem Gegenstand gemäß Hilfsantrag IV an der für die Patentfähigkeit erforderlichen Neuheit, weswegen Hilfsantrag IV nicht günstiger als der Hauptantrag bzw. Hilfsantrag I beurteilt werden kann.

314 Der Hilfsantrag V beruht auf dem Hilfsantrag IV, wobei in Patentanspruch 1 Merkmal M1.5´ gegen Merkmal M1.5 ausgetauscht und der Patentanspruch 1 um Merkmal M1.7a ergänzt wurde. Patentanspruch 8 wurde dementsprechend angepasst.

315 Das ergänzte Merkmal M1.7a sieht vor, Fragmente mitsamt den zu verarbeitenden Texturabschnitten und den Instruktionen, die auf einem Texturprozessor ausgeführt werden sollen, für einen oder mehrere Texturprozessoren bereitzustellen.

316 Das neu hinzugekommene Merkmal M1.7a kann eine Patentfähigkeit des Patentanspruchs 1 gemäß Hilfsantrag V nicht begründen, da es aus Druckschrift NK12 bekannt ist.

317 Druckschrift NK12 zeigt, dass den Verarbeitungselementen (PE), die die Aufgaben von Texturprozessoren übernehmen, Programmanweisungen und zu verarbeitende Texturen bereitgestellt werden (vgl. NK12, Seite 64, linke Spalte, Abschnitt 3.4, erster und zweiter Absatz, siehe „It provides the SIMD micro-instruction to the PEs.“; Fig. 6, siehe „Data in from TASIC“; Seite 63, rechte Spalte, erster und zweiter Absatz). Die den Verarbeitungselementen (PE) zugeführten Rohpixeldaten, die die anspruchsgemäßen Fragmente repräsentieren (vgl. NK12, Seite 58, linke Spalte, vorletzter Absatz, siehe „raw pixel attributes“), setzen sich aus geometrischen und spezifischen Pixel-Attributen zusammen (Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz, siehe „… instead, they compute geometric and intrinsic pixel attributes, such as surface-normal vectors and surface color …“). Die Bereitstellung von Fragmenten, Texturabschnitten und Programmanweisungen für Texturprozessoren i. S. d. Merkmals M1.7a geht damit aus der Druckschrift NK12 hervor.

318 Die Beklagte argumentiert, in Abschnitt 3.4 der Druckschrift NK12 sei allenfalls ein Strom aus Mikroinstruktionen offenbart, jedoch keinerlei Fragmente, die zudem laut Merkmal M1.7a Texturabschnitte beinhalten müssten.

319 Zwar ist der Beklagten darin zuzustimmen, dass sich Abschnitt 3.4 in erster Linie mit der Übergabe von Mikrobefehlen an den SIMD-Prozessor und das Textur-/Video-Subsystem beschäftigt und dort die Verarbeitung von Fragmenten nicht direkt angesprochen wird. Allerdings lehrt Druckschrift NK12, dass Rohpixeldaten, welche geometrische und spezifische Pixel-Attribute umfassen und welche der Fachmann als Fragmente i. S. d. Streitpatents verstehen wird, in die Shader und damit auch in die Verarbeitungselemente (PE) geladen werden, die letztendlich als Texturprozessoren fungieren (vgl. NK12, Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz). Dabei ist zu beachten, dass Merkmal M1.7a entsprechend der Präposition „including“ (zu Deutsch „mit“, „mitsamt“, „einschließlich“) nicht notwendigerweise verlangt, dass die Fragmente selbst Texturabschnitte umfassen müssen. Vielmehr ist Merkmal M1.7a so zu verstehen, dass Fragmente zusammen mit Texturabschnitten an Texturprozessoren übergeben werden, wobei offenbleibt, ob die Texturabschnitte in den Fragmenten enthalten sind oder nicht.

320 Mit Blick auf die Ausführungen zum Hilfsantrag IV ist der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag V nicht neu, so dass das Streitpatent in seiner Fassung nach Hilfsantrag V, der ebenfalls als geschlossener Anspruchssatz zu verstehen ist, keinen Bestand hat.

322 Der Hilfsantrag VI beruht auf dem Hilfsantrag V, wobei Merkmal M1.10 in Patentanspruch 1 aufgenommen worden ist. Demnach soll jeder Texturprozessor für die Fragmente, die er erhält, das gesamte Texturmischen durchführen. Der nebengeordnete Patentanspruch 8 wurde entsprechend angepasst.

323 Das neu hinzugekommene Merkmal M1.10 geht aus Druckschrift NK12 hervor.

324 So war das PixelFlow-System in der Lage, alle Texturmischungen für ein Fragment in einem Texturprozessor durchzuführen. Dies wird in Druckschrift NK12 am Beispiel eines mip mappings verdeutlicht, bei dem ein Verarbeitungselement (PE) acht Texturwerte (texel) anwendet (vgl. NK12, Seite 63, rechte Spalte, Abschnitt 3.3, zweiter und dritter Absatz). Dabei werden alle acht Texturwerte in den Puffer des Verarbeitungselements (PE) geladen, vom Verarbeitungselement (PE) verarbeitet und gemäß Abschnitt IV. 1.2 (s. o.) mit Farbwerten gemischt.

325 Weiterhin ist Druckschrift NK12 nicht nur die Zuordnung der Verarbeitungselemente (PE) zu den einzelnen Pixeln (vgl. NK12, Seite 62, linke Spalte, fünfter Absatz, siehe „The PEs are grouped into sets of 1, 4 or 8, each group corresponding to a pixel.“) zu entnehmen, sondern auch der Hinweis, dass jedes Subpixel (und somit bei 1 PE pro Pixel auch jedes Pixel) unabhängig (und vollständig) zusammen mit den Shading-Informationen verarbeitet werden kann (vgl. NK12, Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz, siehe „For ultimate quality rendering, every subpixel sample can be shaded independently.“). Hieraus folgt, dass ein einzelnes Verarbeitungselement (PE) dazu ausgelegt ist, für ein einzelnes Pixel (d. h. für ein zugeführtes Fragment) das gesamte Shading zu übernehmen, was aber gleichzeitig bedeutet, dass dort auch die gesamte Texturverarbeitung für das Pixel ablaufen kann. Dabei ist zu beachten, dass Merkmal M1.10 bereits dann erfüllt ist, wenn die gesamte Texturverarbeitung für eine einzige Textur und ein einziges Pixel auf einem der Verarbeitungselemente (PE) erfolgt.

326 Merkmal M1.10 ist somit aus Druckschrift NK12 bekannt.

327 Die Beklagte führt aus, Druckschrift NK12 offenbare nicht, dass sämtliche Operationen einer Texturverarbeitung bzw. eines Texturmischens an einem Fragment auf ein und demselben Verarbeitungselement (PE) stattfinden.

328 Dem Einwand kann nicht zugestimmt werden; denn der Fachmann entnimmt Abschnitt 2.5 der Druckschrift NK12 nicht nur, dass ein Shading für sämtliche Subpixel bzw. Pixel ausgeführt werden kann, sondern dass dieses für jedes Subpixel bzw. Pixel unabhängig stattfindet (vgl. NK12, Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz). Demnach ist aber auch die ganze Texturverarbeitung bzw. das ganze Texturmischen eines Subpixels bzw. Pixels auf dem ihm zugeordneten Verarbeitungselement (PE) unabhängig vom Shading auf den anderen Verarbeitungselementen (PE), d. h. eine Verteilung der Texturverarbeitung bzw. des Texturmischens an einem einzigen Subpixel bzw. Pixel auf mehrere Verarbeitungselemente (PE) lässt sich aus der genannten Textstelle gerade nicht ableiten. Vielmehr ist in der Lehre der Druckschrift NK12 davon auszugehen, dass das gesamte Shading und somit auch die gesamte Texturverarbeitung an einem Subpixel bzw. Pixel auf einem Verarbeitungselement (PE) ausgeführt wird.

329 Angesichts der Ausführungen zum Hilfsantrag V erweist sich auch der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag VI als nicht neu. Mit Patentanspruch 1 fällt der gesamte Hilfsantrag.

331 Der Hilfsantrag VII beruht auf dem Hilfsantrag IV, wobei in Patentanspruch 1 die Merkmale M1.11 und M1.12 hinzugekommen sind. Der nebengeordnete Patentanspruch 8 wurde mit den Merkmalen M8.3.7 und M8.3.8 entsprechend angepasst. Demgemäß soll über die Lehre des Hilfsantrags IV hinaus jedes Fragment eine Programm ID umfassen, wobei der zur Texturverarbeitung notwendige „Teil des Programms“ anhand dieser Programm ID bestimmt und geholt bzw. importiert wird.

332 Der Beklagten ist zuzustimmen, dass der Gegenstand des Patentanspruchs 1 nach Hilfsantrag VII nicht mehr ohne weiteres als durch die Lehre der Druckschrift NK12 neuheitsschädlich getroffen oder allein durch diese nahegelegt bezeichnet werden kann. Dennoch ist die beanspruchte Lehre nicht patentfähig, weil sie ausgehend von Druckschrift NK12 in Verbindung mit dem aus der Druckschrift NK13 entnehmbaren Stand der Technik nahegelegt ist.

333 7.2.1 Die Druckschrift NK12 zeigt alle Merkmale des Patentanspruchs 1 nach Hilfsantrag VII mit dem einzigen Unterschied, dass die Lehre der Druckschrift NK12 nicht ausdrücklich vorsieht, dass das Fragment mitsamt einer Programm ID an die Texturprozessoren übermittelt wird (Merkmal M1.11) und, dass der mindestens ein Programmteil mittels der Programm ID von den Texturprozessoren importiert wird (Merkmal M1.12). Die neu hinzugekommenen Merkmale können jedoch keine erfinderische Tätigkeit begründen.

334 Dies begründet sich z. B. durch die Druckschrift NK13, welche eine etwas frühere Realisierungsstufe desselben PixelFlow-Systems betrifft (NK13 Seite 59 „Abstract“, dritter Absatz, siehe „PixelFlow, an experimental graphics engine under construction“) und in der Druckschrift NK12 zitiert wird (NK12 Seite 68 „LAST95“).

335 So offenbart die Druckschrift NK13 die Anwendung verschiedener Programmiermodelle auf das PixelFlow-System der Druckschrift NK12, insbesondere auf dessen Shader Flow Units (vgl. NK13, Seite 64, Abschnitt „Shader programming model“). Auch anhand der Druckschrift NK13 wird klar, dass eine Programmierung der Texturverarbeitung vor dem Prioritätsdatum des Streitpatents bereits bekannt war (vgl. NK13, Seite 64, linke Spalte, Abschnitt „Shader programming model“, erster und zweiter Absatz; Absatz „High-level model“ ff), und der damit generierte Code jedenfalls spätestens während der in der Druckschrift NK12 beschriebenen Forschungsarbeiten in die Verarbeitungselemente (PE) des SIMD-Prozessors geladen und dort zur Ausführung gebracht werden konnte. Mit anderen Worten: die Verarbeitungselemente (PE), die die Aufgaben von Texturprozessoren übernehmen, waren programmierbar.

336 In diesem Zusammenhang offenbart die Druckschrift NK13 eine Programmidentifikation i. S. d. Hilfsantrags VII, die als Shader ID bezeichnet wird und die Bestandteil einer Datenstruktur für „Appearance“-Parameter ist (vgl. NK13, Fig. 8). Die Shader ID wird vom Steuerprogramm für das Shading benutzt, um für jedes Pixel einen Shader Code, d. h. einen Programmteil auszuwählen (vgl. NK13, Seite 65, linke Spalte, Abschnitt 4.1, zweiter Absatz). Dass dieser Shader Code

340 Der nebengeordnete Patentanspruch 8 kann nicht günstiger beurteilt werden.

341 In den im Patentanspruch 8 gemäß Hilfsantrag VII neu hinzugekommenen Merkmalen M8.3.7 und M8.3.8 wird im Wesentlichen beansprucht, dass jedes Fragment eine Programmidentifikation beinhaltet und unter Verwendung dieser Programmidentifikation ein Programmteil (in den Texturprozessor) geholt wird.

342 Da die Druckschrift NK13 mit der Shader ID gerade eine solche Programmidentifikation offenbart, die darüber hinaus noch in einem Fragment enthalten ist (siehe oben), können die neuen Merkmale allein eine Patentfähigkeit nicht begründen. Da außerdem der Patentanspruch 8 gemäß Hilfsantrag IV, auf dem der Patentanspruch 8 gemäß Hilfsantrag VII beruht, inhaltlich nicht über den Patentanspruch 1 gemäß Hilfsantrag IV hinausgeht, ist auch die Lehre des Patentanspruchs 8 gemäß Hilfsantrag VII mit Rücksicht auf den den Druckschriften NK12 und NK13 entnehmbaren Stand der Technik nahegelegt.

343 Die Patentansprüche 1 und 8 gemäß Hilfsantrag VII haben daher auch jeder für sich allein betrachtet keinen Bestand. Mit ihnen fällt der gesamte Hilfsantrag.

345 Patentanspruch 1 gemäß Hilfsantrag VIIa beruht auf Patentanspruch 1 gemäß Hilfsantrag VII, wobei Merkmal M1.12 durch Merkmal M1.12´ ersetzt worden ist, unter Änderung der Formulierung „a portion of the program is imported by each texture processor“ in „a portion of the program is  by each texture processor“.

346 Der Senat versteht das neue Merkmal M1.12´ so, dass unter Verwendung der Programmidentifikation wenigstens ein Teil des Programms von jedem Texturprozessor genutzt wird.

347 Insoweit geht Patentanspruch 1 gemäß Hilfsantrag VIIa inhaltlich nicht über Patentanspruch 1 gemäß Hilfsantrag VII hinaus, weswegen er nicht anders als dieser beurteilt werden kann. Zur Vermeidung von Wiederholungen sei an dieser Stelle lediglich auf die entsprechenden Ausführungen zum Hilfsantrag VII hingewiesen.

348 Mit dem Patentanspruch 1 gemäß Hilfsantrag VIIa fällt der gesamte Hilfsantrag.

349 Unter den vorgenannten Umständen kann dahinstehen, ob der Hilfsantrag VIIa schon wegen Verspätung nach § 83 Abs. 4 Satz 1 PatG zurückzuweisen war.

351 Der Hilfsantrag VIII beruht auf dem Hilfsantrag VI, wobei der Patentanspruch 1 um das Merkmal M1.13 ergänzt wurde. Das neue Merkmal schränkt die Verarbeitung der Texturprozessoren dahingehend ein, dass nur dann eine Ausgabe erzeugt wird, wenn die Verarbeitung des Fragments abgeschlossen ist.

352 Der unabhängige Patentanspruch 8 wurde entsprechend angepasst.

353 Das in Patentanspruch 1 gemäß Hilfsantrag VIII hinzugekommene Merkmal kann eine Patentfähigkeit nicht begründen.

354 So ist aus Druckschrift NK12 bekannt, dass nachdem alle Verarbeitungen für ein Pixel abgeschlossen sind, der endgültige Pixelwert an das „Image Composition Network“ übergeben wird, um ein endgültiges Bild zu erhalten. Die Druckschrift NK12 beschreibt, dass für die vollständig verarbeiteten Pixel („final shaded pixel“) der „Unload“-Modus des „Image Composition Networks“ verwendet wird, damit der Pixelwert in den Bildpuffer gelangt (vgl. NK12, Seite 63, linke Spalte, letzter Absatz, siehe „Unload mode is used, to dump final shaded pixels out of the shader …“). Dabei dürfte klar sein, dass ein Pixelwert von dem Verarbeitungselement (PE) nur dann an das „Composition Network“ weitergegeben wird, wenn für die Rohpixeldaten das gesamte Shading und damit auch die gesamte Texturverarbeitung ausgeführt worden ist.

355 Merkmal M1.13 ist demnach in der Druckschrift NK12 offenbart.

356 Die Beklagte argumentiert, aus der Druckschrift NK12 gehe nicht hervor, dass ein Texturprozessor erst dann eine Ausgabe erzeuge, wenn ein Fragment vollständig verarbeitet ist.

357 Der Einwand greift nicht durch. So ist bereits zu Hilfsantrag VI ausgeführt, dass im PixelFlow-System der Druckschrift NK12 ein Verarbeitungselement (PE) das komplette Shading bzw. die gesamte Texturverarbeitung eines Pixels übernehmen kann. Dies gilt insbesondere dann, wenn auch nur eine einzige Textur verarbeitet werden soll. Erst wenn das Shading eines Pixels auf einem Verarbeitungselement (PE) abgeschlossen ist, wird dieses an den Framebuffer zur Anzeige ausgegeben (vgl. NK12, Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz, siehe „After shading, regions of shaded pixels are forwarded to a frame buffer for display.“).

358 Unter Berücksichtigung der Ausführungen zum Hilfsantrag VI ist der Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag VIII durch die Druckschrift NK12 neuheitsschädlich vorweggenommen. Damit ist auch der Patentanspruch 1 in der Fassung des Hilfsantrags VIII nicht patentfähig. Mit dem Patentanspruch 1 fällt der gesamte Hilfsantrag.