Bundespatentgericht, Urteil vom 06.04.2021, Az. 7 Ni 28/19 (EP), verb. m. 7 Ni 35/19 (EP)

Die Beklagte ist eingetragene Inhaberin des in [X.] Verfahrenssprache mit Wirkung auch für den Hoheitsbereich der [X.] erteilten [X.] Patents 1 177 531 (Streitpatent) mit der Bezeichnung „Method and system for providing programmable texture processing“ (Verfahren und Vorrichtung zur programmierbaren Texturverarbeitung). Im [X.] wird das inzwischen erloschene Streitpatent, das aus der internationalen Anmeldung PCT/[X.]/11907 vom 2. Mai 2000 (veröffentlicht als Druckschrift WO 00/68891 [X.] = Anlage [X.]) hervorgegangen ist und die Priorität der [X.] 09/306,877 vom 7. Mai 1999 in Anspruch nimmt, unter dem Aktenzeichen 600 07 521.4 geführt.

Die Klägerinnen zu 1, 2 und 5 greifen das Streitpatent übereinstimmend in vollem Umfang an. Der [X.] hat die Klage 7 Ni 28/19 (EP) der Klägerin zu 1 und die Klage 7 Ni 35/19 (EP) der Klägerin zu 2 zur gemeinsamen Verhandlung und Entscheidung verbunden. Die Klägerin zu 3, die den verbundenen Verfahren am 1. August 2019 beigetreten ist, hat ihre Klage am 31. Januar 2020 zurückgenommen; einen Kostenantrag hat die Beklagte insoweit nicht gestellt. Weiter [X.] war zunächst auch die Klage 7 Ni 81/19 (EP) der Klägerin zu 4. Diese Klage ist aber nach der Klagerücknahme dieser Klägerin wieder abgetrennt worden. Die Klägerin zu 5 ist dem Verfahren 7 Ni 35/19 (EP) am 14. September 2020 als weitere Klägerin beigetreten.

Das Streitpatent umfasst 13 Patentansprüche, die alle mit den vorliegenden Klagen angegriffen werden. Patentanspruch 1 mit darauf unmittelbar oder mittelbar rückbezogenen [X.]n 2 bis 7 betrifft ein System zur Verarbeitung von Strukturen für eine [X.]ung auf einer Anzeige, Patentanspruch 8 mit darauf unmittelbar oder mittelbar rückbezogenen [X.]n 9 bis 13 ein Verfahren zur Strukturverarbeitung für eine [X.]ung auf einer Anzeige.

Die nebengeordneten Patentansprüche 1 und 8 haben in ihrer erteilten Fassung folgenden Wortlaut:

1. A system (150) for processing textures for a graphical image on a display (1; 104), the graphical image including an [X.], the [X.] including a plurality of fragments, the system comprising:

a plurality of texture processors (154; 190; 300) for processing a portion of the plurality of fragments; characterised by:

a memory (156; 160) for storing a portion of a program for processing a plurality of texture portions for the plurality of fragments, the portion of the program including a plurality of instructions; [X.] (154; 190; 300) [X.] (156; 160), [X.] (154; 190; 300) for processing a portion of the plurality of texture portions for a fragment of the plurality of fragments in [X.], the plurality of texture processors (154; 190; 300) capable of processing a second portion of the plurality of texture portions in parallel, the plurality of texture processors (154; 190; 300) implementing a portion of the plurality of instructions.

8. A method for processing textures of a graphical image on a display (1; 104), the graphical image including an [X.], the [X.] including a plurality of fragments, the system comprising a plurality of texture processors (154; 190; 300) for processing a portion of the plurality of fragments; the method characterised by the steps of:

(a) providing a plurality of texture portions for the plurality of fragments to a plurality of texture processors (154; 190; 300), and

(b) processing the plurality of texture portions in the plurality of texture processors (154; 190; 300) in parallel based on at least one program,

the at least one program including a plurality of instructions, the plurality of texture processors (154; 190; 300) implementing a portion of the plurality of instructions, [X.] (154; 190; 300).

Die [X.] Übersetzung lautet gemäß der [X.] 531 [X.]:

1. Ein System (150) zur Verarbeitung von Strukturen für eine [X.]ung auf einer Anzeige (1; 104), wobei die [X.]ung ein Objekt umfaßt, das Objekt eine Mehrzahl von Fragmenten umfaßt und das System beinhaltet:

eine Mehrzahl von Strukturprozessoren (154; 190; 300) zur Verarbeitung eines Teils der Mehrzahl der Fragmente; gekennzeichnet durch:

einen Speicher (156; 160) zum Speichern eines Teils eines Programms zur Verarbeitung einer Mehrzahl von [X.] für die Mehrzahl der Fragmente, wobei der Abschnitt des Programms eine Mehrzahl von Anweisungen umfaßt; wobei die Mehrzahl der Strukturprozessoren (154; 190; 300) mit dem Speicher (156; 160) gekoppelt ist und jeder der Mehrzahl der Strukturprozessoren (154; 190; 300) zur Verarbeitung eines Teils der Mehrzahl der [X.] für ein Fragment der Mehrzahl der Fragmente gemäß dem Programm eingerichtet ist, wobei die Mehrzahl der Strukturprozessoren (154; 190; 300) in der Lage ist, einen zweiten Abschnitt der Mehrzahl der [X.] parallel zu verarbeiten und die Mehrzahl der Strukturprozessoren (154; 190; 300) ein Abschnitt der Mehrzahl der Anweisungen implementiert.

8. Ein Verfahren zur Strukturverarbeitung für eine [X.]ung auf einer Anzeige (1; 104), wobei das [X.] ein Objekt beinhaltet, das Objekt eine Mehrzahl von Fragmenten beinhaltet und das System eine Mehrzahl von Strukturprozessoren (154; 190; 300) zur Verarbeitung eines Teils der Mehrzahl der Fragmente umfaßt und das Verfahren durch die Mehrzahl der Schritte gekennzeichnet ist;

(a) Liefern einer Mehrzahl von [X.] für die Mehrzahl von Fragmenten an eine Mehrzahl von Strukturprozessoren (154; 190; 300), und

(b) paralleles Verarbeiten der Mehrzahl von [X.] in der Mehrzahl von Strukturprozessoren (154; 190; 300) auf der Grundlage von wenigstens einem Programm, wobei

das wenigstens eine Programm eine Mehrzahl von Anweisungen aufweist, die Mehrzahl von Strukturprozessoren (154; 190; 300) einen Abschnitt der Mehrzahl der Anweisungen implementiert und wenigstens ein Programm auf diese Weise das Verarbeiten der Mehrzahl der [X.] mittels der Mehrzahl der Strukturprozessoren (154; 190; 300) steuert.

Wegen des Wortlauts der [X.] bis 7 und 9 und 13 in [X.] bzw. [X.]r Sprache wird auf die [X.] 531 [X.] Bezug genommen.

Die Klägerinnen zu 1, 2 und 5 machen übereinstimmend gegenüber der erteilten Fassung des Streitpatents den [X.] der mangelnden Patentfähigkeit, die Klägerinnen zu 2 und 5 zusätzlich den [X.] der unzulässigen Erweiterung geltend (Art. II § 6 Abs. 1 Nr. 1 und 3 [X.] [X.] Art. 138 Abs. 1 Buchst. a) und c) EPÜ), wobei die Klägerinnen die fehlende Patentfähigkeit in erster Linie auf fehlende Neuheit stützen.

Sie berufen sich auf folgende Unterlagen (wobei im weiteren Text die fett gedruckten Anlagenbezeichnungen verwendet werden; Anlagenbezeichnungen [X.]a und [X.] bis [X.] und [X.] bis [X.]5 aus 7 Ni 28/19 (EP), restliche Anlagenbezeichnungen aus 7 Ni 35/19 (EP)).

[X.] EP 1 177 531 [X.] (Streitpatent)

[X.]a [X.] ([X.] Übersetzung)

[X.] WO 00/68891 [X.] (ursprüngliche Anmeldung)

NK3 [X.] 09/306,877 (Prioritätsdokument)

[X.] [X.] 5,230,039 A

[X.] [X.] 5,586,234 A

[X.] = [X.]8 [X.] 5,808,690 A

[X.] EP 0 821 339 [X.]

[X.]0 [X.] 5,821,944 A

[X.] [X.] et al., [X.] - Computer Graphics, Principles and Practice, [X.], S. 855, 887-890;

[X.]2 [X.] et al., PixelFlow: [X.], [X.]/[X.] Hardware, 1997, S. 57-68;

[X.]3 Anselmo Lastra et al., [X.], [X.], 1995, S. 59–66, 207;

[X.]4 [X.] 5,481,669 A

[X.]5 Auszug aus dem [X.] „Wayback Machine": „http://web.archive.org/web/19980613135532/http://www.voodoo2.com:80/3dblaster.html“ betr. die Webseite „[X.] 3D Blaster Voodoo2 Review“, März 1998, Ausdruck vom 16. Juli 2018, [X.]-13;

[X.]6 Auszug aus dem [X.] „Wayback Machine": „[X.]“ betr. die Webseite „Diamond Multimedia’s Monster 3D II“, März 1998, Ausdruck vom 16. Juli 2018;

[X.]7 Zeitschrift [X.], Ausgabe 4/98, [X.], 5-7, 192, 193;

[X.]8 Zeitschrift [X.], Ausgabe Oktober 1998 (13 Seiten Auszug);

[X.]9 [X.]-Veröffentlichung („https://www.win.tue.nl/~aeb/ftpdocs/linux-local/docs/[X.]/3Dfx-[X.]“) [X.], [X.] 3Dfx [X.], 6. Februar 1998;

[X.]0 Glide Programming Guide, [X.] Interactive Glide Rasterization Library 2.4, Document Release 018, 3Dfx Interactive, [X.], [X.], [X.] ([X.]A), 25. Juli 1997, Druckdatum 30. Juli 1997;

[X.]0a Auszug aus dem [X.] „Wayback Machine“ vom 22. April 1998 betreffend die Webseite

„http://www.3dfx.com:80/software/download_glide.html“;

[X.]1 Zeitschrift [X.], Ausgabe Januar 1998, Artikel „3Dfx Vodoo

[X.]2 Produktübersicht „N… [X.]“ mit [X.] 1998;

[X.]2a Zeitschrift [X.], Ausgabe vom 3. August 1998;

[X.]3 Handbuch „ELSA [X.] II

[X.]3a Handbuch „AS[X.] V3400TNT Series, [X.]” mit [X.] Januar 1999;

[X.]4 Pressemitteilung von [X.], „[X.] Ships Final Release of [X.].0”, [X.], [X.] ([X.]A), 7. August 1998.

[X.]5 Mark [X.] et al., The [X.]®Graphics System: A Specification, Version 1.2.1, 1. April 1999, S. 238;

[X.]6 [X.]-Veröffentlichung ([X.]) [X.], [X.] - [X.], [X.], [X.], 18. August 1998;

[X.]7 Zeitschrift [X.], Ausgabe Januar 1999, Auszug mit Artikel „[X.] II“;

[X.]8 = [X.] [X.] 5,808,690 A

[X.]9 [X.], 3. Aufl. 1985, [X.]50, 223, 224, 230, 231, 232, 307, 308, 310;

[X.] [X.]/[X.] ([X.]), (Hrsg.), [X.], 1996, [X.]859, 1863, 1864;

[X.] [X.], [X.], veröffentlicht in “Proceedings of the Tenth [X.] Hardware (EGGH’95)”, 1995, [X.] ([X.]veröffentlichung unter

“[X.]/ [X.]/003-013”);

NK32 Benutzeranleitung „[X.] 3D II“ mit Vermerk „Copyright 1995, 1996, 1997, 1998“;

[X.] Zeitschrift [X.], Ausgabe November 1998 (Auszug).

[X.] Wikipedia-Artikel zum Stichwort „3dfx Voodoo [X.]“, Bearbeitungsstand 13. Mai 2017;

NK35 Ordner-Index, im [X.] veröffentlicht unter „https://www.win.tue.nl/~aeb/ftpdocs/linux-local/docs/[X.]“, Ausdruck vom 13. Dezember 2018;

[X.] Auszug aus dem [X.] „Wayback Machine": „http://web.archive.org/web/19990508173428/http://www.review-zone.com:80/hardware/vi...“ betr. die Webseite „[X.]“ vom 20. Oktober 1998;

NK38 [X.]-Veröffentlichung „Image Quality Analysis Fall 2003: [X.]” von [X.] („[X.]/“) vom 10. Dezember 2003;

NK39 Jahresbericht ([X.]) der N… Corporation ([X.]/[X.]A) an die [X.] [X.] betreffend das am 1. Januar 1999 endende Fiskaljahr, veröffentlicht im [X.] unter „https://www.sec.gov/Archives/edgar/data/1045810/0000929624-99-000772.txt“;

[X.] Auszug aus der N…-Finanzdatenbank betreffend die [X.]/1999 bis 1/2000;

[X.] Klageschrift der S… Incorporated gegen die N… Corporation vom 9. November 1998;

[X.] Rechnung und Lieferschein vom 24. Februar 1999 der E… Co., Ltd, [X.], an N… Corporation betr. [X.]-TNT;

[X.] Wikipedia-Artikel zum Stichwort „[X.]“, Bearbeitungsstand 20. September 2018;

[X.] Zeitschrift [X.], Ausgabe vom 4. Mai 1999 (Auszug);

[X.] Wikipedia-Artikel zum Stichwort „Arithmetisch-logische Einheit“, Bearbeitungsstand 28. August 2018;

NK49 Programmieranleitung der 3D-Verarbeitung von [X.], veröffentlicht als Teil des [X.] SDK am 12. Dezember 1998;

[X.] Auszug aus dem [X.] „Wayback Machine“ betr. die Webseite „[X.]“, Stand 16. Januar 1999;

NK51 Ausdruck der Webseite „http://www.gamasutra.com/view/feature/131698/multitexturing_in_dir...“ unter der Überschrift „[X.] - Multitexturing in [X.]“ vom 9. Oktober 1998;

[X.] Auszug aus dem [X.] „Wayback Machine“ betreffend die Webseite „http://www.opengl.org/Products/Accelerators.html“ vom 9. Februar 1999;

[X.] Pressemitteilung N… vom 23. September 1998;

[X.] Auszug aus dem [X.] „Wayback Machine“ betreffend die Webseite „http://www.opengl.org/Documentation/Extensions.html“ vom 6. Mai 1999;

[X.] [X.]-Programmieranleitung der Version 1.2.1 vom 14. Oktober 1998;

[X.] Auszug aus dem [X.] „Wayback Machine“ betreffend die Webseite „[X.]“, Mai 1999;

[X.] Auszug aus: [X.], Programmieren mit [X.], [X.], 1997, [X.]83-212;

[X.] Ausdruck der Webseite „https://isbnsearch.org/isbn/9783540579779“ vom 12. März 2019 betreffend die Veröffentlichung [X.];

[X.] Auszug aus dem „[X.] Programming Guide“, 2. Aufl., 1997, S. 354 bis 357;

[X.]0 Ausdruck der Webseite „https://isbnsearch.org/isbn/9783540579779“ vom 12. März 2019 betreffend die Veröffentlichung [X.];

[X.]1 Ausdruck der Webseite „https://www.khronos.org/registry/[X.]/extensions

/NV/[X.]“ vom 18. Januar 2001;

[X.]2 Programmheft der [X.] 1999, 15. bis 19. März 1999;

[X.]3 Michael I. Gold et al., Advanced [X.] Game Development, 1999, Unterlagen eines auf der dem Programmheft [X.]2 entsprechenden Konferenz gehaltenen Tutorials;

[X.]4 Ausdruck der Webseite „[X.]“ mit Artikel „[X.]“ vom 3. Juli 2019;

[X.]5 Ausdruck der Webseite „https://www.khronos.org/opengl/wiki/History_of_Programmability“ vom 15. Januar 2015.

Die Beklagte verweist in ihrem Vorbringen u. a. auf die folgenden Unterlagen:

G1 Wikipedia-Artikel zu [X.], Stand 22. Februar 2019;

G2 [X.], Architectural Evolution of N… GPUs for High-Performance Computing, Technical Report, [X.] 2015;

G3 [X.] et al., History and Evolution of GPU Architecture – A Paper Survey, Copyright 2010;

G4 Wikipedia-Artikel zum Begriff „Software Rendering”, Stand 26. Juni 2018;

G5 [X.] et al.: Programming Massively Parallel Processors – A Hands-on Approach, [X.], 2010;

G6 [X.]: How a GPU Works, 2011;

G7 N… Corporation (Hrsg.), Technical Brief, [X.] [X.] 8: [X.] in Graphics, mit Vermerk “Confidential”;

G8 Elektronik Kompendium: [X.] [X.], im [X.] abrufbar unter

„https://www.elektronik-kompendium.de/sites/com/0811171 htm?[X.]/f...“;

G9 N… Corporation (Hrsg.): GeForce 256 and [X.] Combiners, How to best utilize the per-pixel operations using [X.] on N… Graphics Processors, Copyright 1999;

[X.] [X.]dokument „https://www.khronos.org/registry/[X.]/extensions/NV/ NV_register_combiners.txt”, Ausdruck vom 16. Mai 2019.

Nach Meinung der Klägerin zu 1 sind die Gegenstände der Patentansprüche 1 und 8 am [X.] durch die [X.] [X.], [X.], [X.], [X.] oder [X.]0 (mit dem zusätzlichen Offenbarungsgehalt von [X.]) neuheitsschädlich vorweggenommen, zumindest aber dem Fachmann nahegelegt. Die Klägerin zu 1 stützt ihre Klage zusätzlich auch auf den von der Klägerin zu 2 in Gestalt des [X.] geltend gemachten Stand der Technik.

Nach Ansicht der Klägerinnen zu 2 und 5 ist der Gegenstand des Patentanspruchs 1 nicht neu gegenüber den Druckschriften [X.]2, [X.]3 ([X.] [X.]9), [X.]4, [X.]8 oder [X.].

Ferner berufen sich die Klägerinnen zu 1, 2 und 5 darauf, dass der Gegenstand von Patentanspruch 1 des Streitpatents durch die [X.] [X.] und [X.] offenkundig vorbenutzt worden sei. Auch die Gegenstände des Patentanspruchs 8 und der [X.] sind nach Auffassung der Klägerinnen zu 1, 2 und 5 nicht patentfähig.

Der [X.] der unzulässigen Erweiterung wird von den Klägerinnen zu 2 und 5 damit begründet, dass die Merkmale [X.], [X.].3, [X.], [X.], [X.], [X.].1, [X.].2 und [X.].3 (zur [X.] siehe unter Abschnitt [X.]) gegenüber der ursprünglich eingereichten Anspruchsfassung und Beschreibung (PCT/[X.]/11907, Seite 15, Zeilen 1 bis 15) wegen Fehlens der unabdingbaren Programm ID eine unzulässige Zwischenverallgemeinerung darstellten. Dies habe zur Folge, dass das Streitpatent die Priorität vom 7. Mai 1999 nicht wirksam in Anspruch nehme, weshalb ihm als Zeitrang sein Anmeldetag vom 2. Mai 2000 zukomme.

Die Klägerinnen zu 1, 2 und 5 beantragen,

das [X.] Patent EP 1 177 531 mit Wirkung für das Hoheitsgebiet der [X.] in vollem Umfang für nichtig zu erklären.

Die Beklagte beantragt zuletzt,

die Klage abzuweisen,

hilfsweise die Klage abzuweisen, soweit sie sich gegen das Streitpatent in der Fassung der in der Reihenfolge ihrer Nummerierung gestellten [X.] bis [X.], eingereicht mit Schriftsatz vom 21. September 2020, richtet.

Außerdem verteidigt sie die Ansprüche 1 und 8 des Hilfsantrags [X.], eingereicht mit Schriftsatz vom 21. September 2020, einzeln.

Darüber hinaus stellt sie – in dieser Reihenfolge – den in der mündlichen Verhandlung überreichten Hilfsantrag [X.]a vom 19. November 2020 und den Hilfsantrag [X.]I aus dem Schriftsatz vom 21. September 2020.

Ausgehend von der untenstehenden [X.] und bei im Übrigen angepassten Rückbezügen erhalten die Patentansprüche in der Fassung der Hilfsanträge I bis [X.]I, eingereicht mit Schriftsatz vom 21. September 2020, folgende Fassung, bei welcher jeweils der Patentanspruch 12 der erteilten Fassung entfällt:

Patentanspruch 1 gemäß Hilfsantrag I unterscheidet sich von Patentanspruch 1 der erteilten Fassung durch Merkmal [X.]´, das Merkmal [X.] ersetzen soll, und durch das neu hinzugekommene Merkmal [X.].8 (Änderungen gegenüber der erteilten Fassung sind unterstrichen):

[X.]´ “A system (150) for processing textures providing programmable texture processing for a graphical image on a display (1; 104), the graphical image including an [X.], the [X.] including a plurality of fragments, the system comprising:”

[X.].8 “wherein the processing a portion of the plurality of texture portions for a fragment in [X.] comprises texture blending.”

Dementsprechend enthält Patentanspruch 8 gemäß Hilfsantrag I anstelle des Merkmals [X.] das Merkmal [X.]´, wobei außerdem noch Merkmal [X.].4 auf Merkmal [X.].3 folgen soll:

[X.]´ “A method for processing textures providing programmable texture processing of a graphical image on a display (1; 104), the graphical image including an [X.], the [X.] including a plurality of fragments,”

[X.].4 “wherein the processing step (b) further includes the step of:

([X.]) [X.] in the plurality of texture processors (154; 190; 300) based on the at least one program.”

Patentanspruch 1 gemäß Hilfsantrag II unterscheidet sich von Patentanspruch 1 gemäß Hilfsantrag I in der eingereichten englischsprachigen Fassung durch Merkmal [X.].9, das sich an Merkmal [X.].8 anschließen soll:

[X.].9 “wherein the texture processors can adapt to different blending operations on different inputs.”

Patentanspruch 8 gemäß Hilfsantrag II unterscheidet sich von Patentanspruch 8 gemäß Hilfsantrag I durch Merkmal [X.].5, das auf Merkmal [X.].4 folgen soll:

[X.].5 “wherein the texture processors can adapt to different blending operations on different inputs.”

Patentanspruch 1 gemäß Hilfsantrag III unterscheidet sich von Patentanspruch 1 gemäß Hilfsantrag II durch Merkmal [X.].9´, das Merkmal [X.].9 ersetzen soll:

[X.].9´ “wherein the texture processors are adaptable to perform a variety of texture blends.”

Das entsprechende im Patentanspruch 8 gemäß Hilfsantrag III hinzugekommene Merkmal [X.].5´, das Merkmal [X.].5 ersetzt, lautet:

[X.].5´ “wherein the texture processors are adaptable to perform a variety of texture blends.”

Patentanspruch 1 gemäß Hilfsantrag IV unterscheidet sich von Patentanspruch 1 gemäß Hilfsantrag I durch die Merkmale [X.].2´und [X.].5´, die an die Stelle der Merkmale [X.].2 und [X.].5 treten sollen:

[X.].2´ “a memory (156; 160) for storing a portion of a program used by the plurality of texture processors for processing a plurality of texture portions for the plurality of fragments,”

[X.].5´ “[X.] (154; 190; 300) for importing at least a portion of the program and processing a portion of the plurality of texture portions for a fragment of the plurality of fragments in [X.],”

Patentanspruch 8 gemäß Hilfsantrag IV beruht auf Patentanspruch 8 gemäß Hilfsantrag I, wobei Merkmal [X.].1´ das Merkmal [X.].1 ersetzt:

[X.].1´ “wherein a portion of the program is imported and used by the plurality of texture processors for processing the plurality of texture portions, the at least one program including a plurality of instructions,”

Patentanspruch 1 gemäß Hilfsantrag V unterscheidet sich von Patentanspruch 1 gemäß Hilfsantrag IV durch Merkmal [X.]a, das zwischen den Merkmalen [X.] und [X.].8 eingefügt werden soll. Weiterhin wurde Merkmal [X.].5´ durch Merkmal [X.].5 ersetzt.

[X.]a “wherein the fragments, including the texture portions to be processed, and the portion of the plurality of instructions to be performed by a texture processor are provided to one or more texture processors for processing,”

Patentanspruch 8 gemäß Hilfsantrag V geht aus von Patentanspruch 8 gemäß Hilfsantrag IV, wobei zwischen den Merkmalen [X.].3 und [X.].4 das Merkmal [X.].3a eingefügt wird. Außerdem wird Merkmal [X.].1´ durch Merkmal [X.].1´´ ersetzt:

[X.].1´´ “wherein a portion of the program is used by the plurality of texture processors for processing the plurality of texture portions, the at least one program including a plurality of instructions,”

[X.].3a “wherein the fragments, including the texture portions to be processed, and the portion of the plurality of instructions to be performed by a texture processor are provided to one or more texture processors for processing,”

Patentanspruch 1 gemäß Hilfsantrag VI unterscheidet sich von Patentanspruch 1 gemäß Hilfsantrag V durch Merkmal [X.]0, das auf Merkmal [X.].8 folgen soll:

[X.]0 “wherein each texture processor performs all of the texture blending for the fragment(s) which it receives.”

In Patentanspruch 8 gemäß Hilfsantrag VI ist gegenüber Hilfsantrag V nach Merkmal [X.].4 noch Merkmal [X.].6 angefügt worden:

[X.].6 “wherein each texture processor performs all of the texture blending for the fragment(s) which it receives.”

Patentanspruch 1 gemäß Hilfsantrag [X.] geht aus von Patentanspruch 1 gemäß Hilfsantrag IV, wobei die Merkmale [X.]1 und [X.]2 hinzugefügt worden sind:

[X.]1 “wherein each fragment, including a program identification, is provided to one or more texture processors for processing,”

[X.]2 “wherein the at least a portion of the program is imported by each texture processor using the program identification.”

Patentanspruch 8 gemäß Hilfsantrag [X.] beruht auf Patentanspruch 8 gemäß Hilfsantrag IV, wobei noch die Merkmale [X.].7 und [X.].8 hinzugekommen sind:

[X.].7 “wherein each fragment includes a program identification, and wherein the method further includes the step of:”

[X.].8 “(c) fetching a portion of the program using the program identification.”

Zusätzlich zu Patentanspruch 12 ist auch Patentanspruch 11 der erteilten Fassung bei im Übrigen angepassten Rückbezügen gestrichen.

Patentanspruch 1 gemäß Hilfsantrag [X.]I beruht auf Patentanspruch 1 gemäß Hilfsantrag VI, wobei das neue Merkmal [X.]3 auf Merkmal [X.]0 folgen soll:

[X.]3 “wherein each texture processor only provides an output when it has completed processing for the fragment.”

Patentanspruch 8 gemäß Hilfsantrag [X.]I geht aus von Patentanspruch 8 gemäß Hilfsantrag VI, wobei noch Merkmal [X.].9 hinzugekommen ist:

[X.].9 “wherein each texture processor only provides an output when it has completed processing for the fragment.”

In der Fassung des erstmals in der mündlichen Verhandlung gestellten Hilfsantrags [X.]a vom 19. November 2020 erhalten die Patentansprüche folgende Fassung:

Patentanspruch 1 gemäß Hilfsantrag [X.]a geht aus von Patentanspruch 1 gemäß Hilfsantrag [X.], wobei Merkmal [X.]2 durch Merkmal [X.]2´ ersetzt werden soll:

[X.]2´ “wherein the at least a portion of the program is used by each texture processor using the program identification.“

Patentanspruch 8 gemäß Hilfsantrag [X.]a ist mit Patentanspruch 8 gemäß Hilfsantrag [X.] identisch.

Zusätzlich zu Patentanspruch 12 ist auch Patentanspruch 11 der erteilten Fassung bei im Übrigen angepassten Rückbezügen gestrichen.

Die Beklagte widerspricht dem Vortrag der Klägerinnen in allen Punkten. Die behaupteten offenkundigen Vorbenutzungen hält sie für nicht nachgewiesen; u. a. stellt sie sich auf den Standpunkt, dass ein Auszug aus einem [X.]archiv (wie im Fall von [X.]0 mittels der [X.]-Seite [X.]0a) nicht ausreichend sei.

Außerdem ist die Beklagte der Ansicht, dass den Klägerinnen zu 1 und 2 für ihre Klagen ein Rechtsschutzinteresse fehle: Das Streitpatent sei inzwischen erloschen. Das Verletzungsverfahren, an dem die Klägerin zu 1 als Nebenintervenientin der [X.]n, der [X.], beteiligt gewesen sei, sei aufgrund der Einigung der [X.] mit der [X.] nicht mehr anhängig. Es sei nicht ersichtlich, unter welchen Umständen eine Inanspruchnahme der Klägerin zu 1 noch in Frage kommen könnte. Die Klägerin zu 2 sei weder [X.] gewesen noch einem hinsichtlich des Streitpatents anhängigen Verletzungsverfahren beigetreten noch sei sie Lieferantin der Klägerin zu 5. Die Klägerin zu 2 könne unter keinem rechtlichen Gesichtspunkt aus dem Streitpatent in Anspruch genommen werden, ebenso wenig könnten sich Regressansprüche der Klägerin zu 5 unmittelbar gegen die Klägerin zu 2 richten.

Die Klägerinnen zu 1 und 2 vertreten die Auffassung, für ihre jeweiligen Klagen bestehe auch nach dem Erlöschen des Streitpatents ein Rechtsschutzinteresse. Auch nach Rücknahme der Verletzungsklage der [X.] gegen die [X.], an welcher die Klägerin zu 1 als Nebenintervenientin beteiligt war, sei nicht auszuschließen, dass die Klägerin zu 1 von der [X.] oder der [X.] im Wege der Freistellung aus dem Streitpatent in Anspruch genommen werde; vom Inhalt des zwischen der [X.] und der [X.] geschlossenen Vergleichs habe die Klägerin zu 1 keine Kenntnis, sie sei nicht in den Vergleich einbezogen. Die Klägerin zu 2 habe es im [X.] übernommen, die Nichtigkeitsklage zu betreiben und damit die Klägerin zu 5 als Beklagte im parallelen Verletzungsverfahren zu verteidigen. Die Klägerin zu 2 verfüge über eine Rechtsabteilung für Rechtsangelegenheiten des [X.]s für Europa.

Die jeweiligen Gegenstände der unabhängigen Patentansprüche nach den [X.] bis [X.]I der [X.] in der Fassung vom 21. September 2020 halten die Klägerinnen zu 1, 2 und 5 für nicht patentfähig. Die [X.]V bis [X.]I in der Fassung vom 21. September 2020 halten sie überdies für unzulässig erweitert. Die Klägerin zu 1 sieht die Patentfähigkeit durch die Druckschrift [X.]8 in Frage gestellt, die Klägerinnen zu 2 und 5 beziehen sich auf die Druckschriften zum Thema „PixelFlow“ ([X.]2, [X.]3, [X.]) und auf die behauptete offenkundige Vorbenutzung des [X.]-Grafikkarten-Chipsatzes.

Die Einreichung des Hilfsantrags [X.]a in der Fassung vom 19. November 2020 rügen die Klägerinnen zu 1, 2 und 5 als verspätet.

Der [X.] hat den Parteien mit Schreiben vom 19. August 2020 einen qualifizierten gerichtlichen Hinweis zukommen lassen.

Einen Klageverzicht auf Ansprüche aus dem Streitpatent hat die Beklagte nicht erklärt.

Wegen des Vorbringens der Parteien im Übrigen wird auf deren Schriftsätze mit sämtlichen Anlagen und auf das Protokoll der mündlichen Verhandlung vom 19. November 2020 verwiesen.

Die Klagen der Klägerinnen zu 1, 2 und 5 sind zulässig und begründet. Denn das [X.] hat weder in der erteilten Fassung noch in der Fassung einer der Hilfsanträge Bestand, da ihm der geltend gemachte [X.] der fehlenden Patentfähigkeit (Art. II § 6 Abs. 1 Nr. 1 [X.], Art. 138 Abs. 1 lit. a) EPÜ [X.] Art. 54 Abs. 1, 2 und Art. 56 EPÜ) entgegensteht.

Es bedarf daher keiner Entscheidung, ob dem [X.] auch der weiterhin geltend gemachte [X.] der unzulässigen Erweiterung (Art. II § 6 Abs. 1 Nr. 3 [X.] [X.] Art. 138 Abs. 1 lit. c) EPÜ) entgegensteht.

Die Klagen der Klägerinnen zu 1, 2 und 5 sind auch nach dem Erlöschen des [X.] aufgrund [X.]ablaufs am 2. Mai 2020 weiterhin zulässig. Auch der Beitritt der Klägerin zu 5 ist wirksam erfolgt.

1. Ist ein Patent durch [X.]ablauf erloschen, bedarf es eines schutzwürdigen Interesses des Klägers an der Durchführung des [X.], da ein Interesse der Allgemeinheit an einer Überprüfung der Rechtsbeständigkeit nicht mehr besteht. Die Frage, ob ein solches eigenes Rechtsschutzinteresse vorliegt, darf nicht nach allzu strengen Maßstäben beurteilt werden. Es ist gegeben, wenn der Kläger wegen Verletzung des Patents in Anspruch genommen wird oder für den Kläger Grund zu der Besorgnis besteht, er könne aus dem Patent wegen Handlungen in der [X.] vor dessen Erlöschen in Anspruch genommen werden. Ein Rechtsschutzinteresse ist in solchen Fällen nur zu verneinen, wenn eine solche Inanspruchnahme ernstlich nicht mehr in Betracht kommt (st. Rspr., zuletzt BGH GRUR 2021, 42, Rn. 7 – Truvada m. w. N.). Letzteres ist nicht der Fall.

1.1 [X.] vor dem [X.] (…) 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. [X.], 1084, Rn. 10 – Windenergiekonverter; GRUR 2020, 1074, Rn. 29 – Signalübertragungssystem).

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 [X.] 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 [X.]. 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 [X.] nicht unbegründet, dass sie von der Beklagten wegen Handlungen in der [X.] vor Erlöschen des [X.] wegen Verletzung in Anspruch genommen wird. Hiervon abgesehen könnte die Klägerin zu 1 auch Regressansprüchen der [X.] ausgesetzt sein, zumal der Inhalt des Vergleichs aus dem [X.] gegen die [X.] nicht bekannt ist.

1.2 Auch der Klägerin zu 2, die zwar selbst weder unmittelbar wegen Verletzung des [X.] 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“ ([X.], 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.

Die Klägerin zu 2 gehört zum [X.] und verfügt nach eigenen Angaben, an deren Richtigkeit der Senat keinen Anlass hatte zu zweifeln, über eine Rechtsabteilung für Rechtsangelegenheiten des [X.], und hat es im [X.] übernommen, die vorliegende Nichtigkeitsklage zu betreiben, um die wegen Patentverletzung in Anspruch genommene Klägerin zu 5 als Beklagte im parallelen [X.] vor dem [X.] (Aktenzeichen …) zu verteidigen. Die hiesige Beklagte hat als Verletzungsklägerin in ihrer Klageschrift vom 25. Mai 2018 (Anlage [X.] zum Verfahren 7 Ni 35/19 (EP)) insoweit selbst vorgetragen (Seiten 17, 18), dass in die Spielkonsole „[X.]“, als deren Vertreiberin in [X.] die Klägerin zu 5 verklagt wird, das [X.] N… T210 ([X.]) des „[X.] verbaut“ sei und das genannte [X.] alle Merkmale des [X.] verwirkliche. Ungeachtet einer näheren Auseinandersetzung mit der im konkreten Einzelfall gewählten Form arbeitsteiligen Zusammenwirkens im Konzern ist das auch nach [X.] bestehende rechtliche Interesse des Chipherstellers, die Inanspruchnahme einer [X.] abzuwenden – die Verletzungsklage gegen die [X.] 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. [X.], 1284, Rn. 51 – Datenpaketumwandlung; GRUR 2010, 1084 – Windenergiekonverter).

1.3. Hinsichtlich der Klägerin zu 5 ergibt sich das erforderliche Rechtsschutzinteresse ohne Weiteres daraus, dass sie die [X.] in dem oben unter 1.2 bezeichneten [X.] vor dem [X.] ist.

2. Die Klägerin zu 5 ist auch wirksam der Nichtigkeitsklage 7 Ni 35/19 (EP) als weitere Klägerin beigetreten.

Die Parteierweiterung auf Klägerseite ist nach ständiger Rechtsprechung wie eine Klageänderung nach § 263 ZPO zu behandeln (vgl. [X.], 264; [X.], 3225; [X.]/[X.], ZPO, 33. Aufl., § 263 Rn. 27). Nachdem die Beklagte dem [X.] nicht zugestimmt hat, ist die Klageänderung nur zulässig, wenn sie sachdienlich ist. Hiervon ist aus prozessökonomischen Gründen auszugehen. Da gegen die [X.] eine auf Grundlage des [X.] geführte Verletzungsklage anhängig ist, wird damit ein neuer Prozess, d. h. eine eigene Klage der [X.]n, die sie jederzeit (und zwar auch zu einem späten [X.]punkt) selbst erheben kann, vermieden (vgl. [X.] 32, 204, 205; [X.], Urteil vom 8. Dezember 2016 – 2 Ni 5/15 (EP) unter Gründe [X.]1, juris Rn. 113).

1. Das [X.] betrifft das Anzeigen einer [X.]ung auf einem Computersystem und insbesondere ein Verfahren und System, um eine programmierbare [X.] für eine [X.]ung bereitzustellen ([X.]chrift, Abs. [0001]).

Die Bezeichnung „Struktur“ in der [X.] Fassung des [X.] ([X.] 07 521 T2) steht für „texture“ in der [X.] Sprachfassung und stellt eine missverständliche Übersetzung dar. Im Folgenden wird im [X.] der technisch zutreffende Begriff „Textur“ anstelle von „Struktur“ verwendet.

Laut Beschreibungseinleitung stellen herkömmliche Computergrafiksysteme grafische Bilder von Objekten auf einer Anzeige bzw. einem Display dar. Das Display umfasst eine Mehrzahl von Displayelementen, sogenannten Pixeln, die üblicherweise in einem Gitter angeordnet sind. Um Objekte anzuzeigen, unterteilt ein herkömmliches Grafiksystem jedes Objekt in eine Mehrzahl von Polygonen, welche dann in einer bestimmten Reihenfolge „gerendert“ werden ([X.]chrift, Abs. [0003]).

Jedes Polygon überdeckt oder schneidet eine gewisse Anzahl von Pixeln des Displays. Die Daten für den Teil eines Polygons, der ein bestimmtes Pixel schneidet, werden „Fragment“ für dieses Polygon und dieses Pixel genannt. Sie betreffen typischerweise die Farbe, den [X.] („blending mode“) und die Textur. Um ein Fragment eines Polygons darzustellen (zu „rendern“), muss das Grafikverarbeitungssystem die Farbe und Textur für das Fragment verarbeiten ([X.]chrift, Abs. [0004]). Dies geschieht beispielsweise durch ein Mischen der Farbe und der Textur, um einen endgültigen Farbwert für das Fragment an dem entsprechenden Pixel zu erhalten ([X.]chrift, Abs. [0005]).

Das [X.] beschreibt eine Textur als eine andere Farbe, die gewöhnlich von einer Texturkarte abgeleitet wird ([X.]chrift, Abs. [0005]). Eine solche Textur wird in der Grafikverarbeitung verwendet, um die Oberfläche eines Objekts mit einem „Überzug“ zu versehen, welcher etwa die Farben der Oberfläche, deren optische Beschaffenheit oder auch weitere Effekte wie Lichtreflexe definiert und auf das Objekt aufbringt ([X.]chrift, Abs. [0005], [0006]). Dabei werden auch mehrere Texturen für ein Objekt verwendet, um unterschiedliche Effekte schichtweise auf die Oberfläche aufzubringen. Dies bezeichnet das [X.] als Mehrfachtexturabbildung ([X.]chrift, Abs. [0006]).

Im [X.] geht es grundsätzlich darum, den Fragmenten eines abzubildenden Objekts entsprechende [X.] zuzuordnen. Ein Objekt wird letztlich auf einer Anzeigevorrichtung dargestellt, die eine Mehrzahl von Pixeln aufweist. Deshalb ist es zum Zwecke der Darstellung erforderlich, die Daten eines Fragments so zu verarbeiten, dass daraus ein Wert für das jeweilige Pixel der Anzeigevorrichtung erhalten wird. Wie die für die mehrfache Texturabbildung notwendigen Berechnungen im Stand der Technik ausgeführt werden konnten, wird im [X.] u. a. anhand der [X.]uren 3 und 4 erläutert: Eine Lösung bestand darin, eine einzelne Texturmischeinheit („Texture Blending Unit“) zu verwenden, welche sämtliche Texturberechnungen für ein Fragment nacheinander, also seriell ausführt, wobei das Ergebnis jeder Berechnung in einer Schleife an dieselbe Texturmischeinheit zurückgeführt wird, um dann die nächste Textur darauf anzuwenden ([X.]chrift, Abs. [0018]). Der zugehörige Aufbau ist in [X.]ur 4 gezeigt. Eine andere Variante bestand darin, mehrere [X.] kaskadiert in Reihe zu schalten, so dass jede Texturmischeinheit das Ergebnis der vorhergehenden Stufe verwendet, um dann anhand einer weiteren Textur Berechnungen für ein Fragment auszuführen ([X.]chrift, Abs. [0017]). Diese Variante ist in [X.]ur 3 des [X.] wiedergegeben.

An solchen und ähnlichen herkömmlichen Grafiksystemen wird kritisiert, dass sie entweder in ihrer Funktion zu beschränkt und zu unflexibel seien, oder aber einen komplexen Aufbau erforderten. Dies liege daran, dass sowohl mehrere Fragmente als auch mehrere Texturen nur hintereinander abgearbeitet werden könnten und die [X.] speziell auf bestimmte Mischoperationen ausgebildet werden müssten ([X.]chrift, Abs. [0008]).

2. Ausgehend vom bekannten Stand der Technik stellt sich das [X.] daher die Aufgabe, ein System und ein Verfahren bereitzustellen, das einen „adaptierbaren Mechanismus zum Bereitstellen einer [X.] ohne nachteilige Auswirkung auf die Leistung des Systems“ aufweist ([X.]chrift, Abs. [0009]). Die [X.] soll in vergleichsweise kleinen Einheiten stattfinden können und dabei gleichzeitig flexibel, d. h. adaptierbar in Hinblick auf die ausgeführten Funktionen sein, um den genannten Problemen zu begegnen ([X.]chrift, Abs. [0008], [0009], [0022])

3. Um diese Aufgabe zu lösen, beschreiben die unabhängigen Patentansprüche 1 und 8 ein System und ein Verfahren zur [X.] für eine [X.]ung auf einer Anzeige, mit folgendem Wortlaut (englisch: gemäß [X.]chrift, deutsch: teilweise verbesserte Übersetzung):

Patentanspruch 1 (in Anlehnung an die von der Klägerin zu 1 vorgeschlagene Merkmalsgliederung):

[X.] A system (150) for processing textures for a graphical image on a display (1; 104), the graphical image including an [X.], the [X.] including a plurality of fragments, the system comprising: Ein System (150) zur Verarbeitung von Texturen für eine [X.]ung auf einer Anzeige (1; 104), wobei die [X.]ung ein Objekt umfasst, und das Objekt eine Mehrzahl von Fragmenten umfasst, und das System beinhaltet:

[X.] a plurality of texture processors (154; 190; 300) for processing a portion of the plurality of fragments; [characterised by:] eine Mehrzahl von [X.] (154; 190; 300) zur Verarbeitung eines Teils der Mehrzahl der Fragmente; [gekennzeichnet durch:]

[X.] a memory (156; 160) for storing a portion of a program for processing a plurality of texture portions for the plurality of fragments, einen Speicher (156; 160) zum Speichern eines Teils eines Programms zur Verarbeitung einer Mehrzahl von [X.] für die Mehrzahl der Fragmente,

[X.].3 the portion of the program including a plurality of instructions; wobei der Teil des Programms eine Mehrzahl von Anweisungen umfasst;

[X.].4 said plurality of texture processors (154; 190; 300) [X.] (156; 160), wobei die Mehrzahl der [X.] (154; 190; 300) mit dem Speicher (156; 160) gekoppelt ist;

[X.] each of the plurality of texture processors (154; 190; 300) for processing a portion of the plurality of texture portions for a fragment of the plurality of fragments in [X.], wobei jeder der Mehrzahl der [X.] (154; 190; 300) zur Verarbeitung eines Teils der Mehrzahl der [X.] für ein Fragment der Mehrzahl der Fragmente gemäß dem Programm eingerichtet ist;

[X.] the plurality of texture processors (154; 190; 300) capable of processing a second portion of the plurality of texture portions in parallel, wobei die Mehrzahl der [X.] (154; 190; 300) in der Lage ist, einen zweiten Teil der Mehrzahl der [X.] parallel zu verarbeiten;

[X.] the plurality of texture processors (154; 190; 300) implementing a portion of the plurality of instructions. wobei die Mehrzahl der [X.] (154; 190; 300) einen Teil der Mehrzahl der Anweisungen implementiert.

Patentanspruch 8 (hier mit einer denkbaren Gliederung versehen):

M8 A method for processing textures of a graphical image on a display (1; 104), the graphical image including an [X.], the [X.] including a plurality of fragments, Ein Verfahren zur [X.] für eine [X.]ung auf einer Anzeige (1; 104), wobei das [X.] ein Objekt umfasst und das Objekt eine Mehrzahl von Fragmenten beinhaltet

M8.1 the system comprising a plurality of texture processors (154; 190; 300) for processing a portion of the plurality of fragments; und das System eine Mehrzahl von [X.] (154; 190; 300) zur Verarbeitung eines Teils der Mehrzahl der Fragmente umfasst;

the method characterised by the steps of: wobei das Verfahren gekennzeichnet ist durch die Schritte:

M8.2 (a) providing a plurality of texture portions for the plurality of fragments to a plurality of texture processors (154; 190; 300), and (a) Bereitstellen einer Mehrzahl von [X.] für die Mehrzahl von Fragmenten an eine Mehrzahl von [X.] (154; 190; 300); und

M8.3 (b) processing the plurality of texture portions in the plurality of texture processors (154; 190; 300) in parallel [X.], (b) paralleles Verarbeiten der Mehrzahl von [X.] in der Mehrzahl von [X.] (154; 190; 300) auf Grundlage von wenigstens einem Programm;

M8.3.1 [X.], wobei das wenigstens eine Programm eine Mehrzahl von Anweisungen aufweist,

M8.3.2 the plurality of texture processors (154; 190; 300) implementing a portion of the plurality of instructions, die Mehrzahl von [X.] (154; 190; 300) einen Teil der Mehrzahl der Anweisungen implementiert

M8.3.3 the at least one program thereby controlling processing of the plurality of texture portions by the plurality of texture processors (154; 190; 300). und wenigstens ein Programm auf diese Weise das Verarbeiten der Mehrzahl der [X.] durch die Mehrzahl der [X.] (154; 190; 300) steuert.

4. Als Fachmann, der mit der Aufgabe betraut wird, ein System bzw. Verfahren zur [X.] in der Grafikverarbeitung zu verbessern, ist ein Diplomingenieur der Fachrichtung Elektrotechnik oder Informatik anzusehen, der mehrjährige Berufserfahrung auf dem Gebiet des Designs von Grafikchips zur Anwendung im Bereich von Grafikkarten hat und der insbesondere über fundierte Kenntnisse in der Bildsynthese verfügt.

5. Dieser Fachmann legt den Merkmalen des Patentanspruchs 1 folgendes Verständnis zugrunde:

a) Zum Begriff Textur bzw. Struktur

Für den [X.] Begriff texture im Original des [X.] verwendet die zugehörige [X.] 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 [X.] beschreibt und dem Objekt eine Oberflächenstruktur verleiht. Insoweit entspricht eine Textur gleichzeitig einer Struktur. Ausgehend vom [X.] in der [X.] Originalfassung wird im Folgenden abweichend von der [X.] der technisch zutreffendere Begriff Textur anstelle von Struktur verwendet.

b) Zum Begriff Fragment

Um Objekte auf dem Display eines Grafiksystems anzuzeigen, wird jedes Objekt in eine Vielzahl von Polygonen aufgeteilt ([X.]chrift, 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 ([X.]chrift, Abs. [0004], siehe „[X.] 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 [X.] 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 ([X.]chrift, Abs. [0004], [0014]).

c) Zum Begriff Textur- bzw. Strukturabschnitt

Einem Fragment ist gemäß dem [X.] 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 [X.] genannt – beinhaltet laut [X.] einen Farb- und einen [X.], der eine Transparenzinformation für einen Bildpunkt bzw. ein Pixel angibt ([X.]chrift, Abs. [0005]).

d) Zum Begriff Programm

Anspruchsgemäß steuert ein Programm die [X.] auf einer Mehrzahl von [X.] ([X.]chrift, Abs. [0033]). Infolge dieses Programms können die [X.] an verschiedene Mischoperationen angepasst werden ([X.]chrift, 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 [X.] auf den [X.] ausgeführt werden.

e) Zur Lehre des erteilten Patentanspruchs 1

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

Im [X.] bildet das System einen Teil der Image Generating Unit 120, die eine [X.]ung auf einer Anzeige erzeugt ([X.]chrift, Abs. [0027], [X.]. 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 [X.] und Tiefenwerte eines bestimmten Polygons und Pixels betreffen ([X.]chrift, Abs. [0014]).

Merkmal [X.] besagt, dass das beanspruchte System über eine Mehrzahl von [X.] 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 ([X.]chrift, Abs. [0049], [X.]. 11A).

Gemäß Merkmal [X.] umfasst das System einen Speicher, der der Hinterlegung eines Teils eines Programms zur Verarbeitung einer Mehrzahl von [X.] dient. Als Speicher kommt jede Art von Speicher unabhängig von seiner Lage innerhalb des Systems in Frage (vgl. [X.]chrift, Abs. [0033]). So kann es sich bei dem Speicher laut [X.] etwa um einen Zwischenspeicher ([X.]. 9, Program Cache 160) oder einen Festplattenspeicher handeln ([X.]. 6, Memory 110). Weiterhin wird in Absatz [0042] der [X.]chrift ausgeführt, dass der Zwischenspeicher das komplette Programm zur [X.] 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, [X.] auch sämtliche Teile des Programms umfasst und nicht bloß einen einzigen Teil davon. Zur [X.] können die einzelnen Teile des [X.]n Programms in gleichwirkender Weise sowohl auf einem einzigen Speicher untergebracht als auch über eine Mehrzahl von Speichern verteilt sein.

In Merkmal [X.].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 [X.] übergeben werden und die [X.] von Fragmenten steuern.

Merkmal [X.].4 besagt, dass die Mehrzahl der [X.] an den Speicher gekoppelt ist. Laut [X.] können die [X.] und der Speicher über einen Distributor und einen Argument Decoder miteinander verknüpft sein ([X.]chrift, Abs. [0032], [0039], [X.]. 7, 9). Beide Komponenten sind dafür verantwortlich, dass die Anweisungen des im Speicher hinterlegten Programms an die [X.] verteilt werden. Allerdings ist Merkmal [X.].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 [X.] erst ermöglichen.

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

Außerdem sollen die [X.] in der Lage sein, die [X.] parallel durchzuführen. So sind die [X.] gemäß Merkmal [X.] dazu eingerichtet, einen zweiten Teil der [X.] parallel zu verarbeiten. Der Fachmann wird Merkmal [X.] so verstehen, dass sich der „zweite Teil der [X.]“ von dem in Merkmal [X.] genannten Teil dadurch unterscheidet, dass er andere [X.] einer Texturkarte desselben Fragments betrifft oder aber überhaupt zu einem anderen Fragment gehört. Wie sich den Ausführungen in Absatz [0032] der [X.]chrift entnehmen lässt, sollen die [X.] die [X.] für die entsprechenden Fragmente verarbeiten. Demnach führt jeder Texturprozessor die gesamte [X.] für das Fragment oder die Fragmente durch, das bzw. die er erhält. Alternativ kann ein Texturprozessor auch nur einen Teil der [X.] für ein Fragment durchführen, wobei der Rest der [X.] von einem anderen Texturprozessor übernommen wird ([X.]chrift, Spalte 9, Zeilen 40 bis 45). Merkmal [X.] ist demnach bereits dann erfüllt, wenn die [X.] mehrere [X.] 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 [X.] die parallel verarbeiteten [X.] zu Fragmenten desselben Objekts gehören.

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

Das [X.] hat in der erteilten Fassung keinen Bestand, weil die jeweiligen Gegenstände der unabhängigen Patentansprüche 1 und 8 nicht patentfähig sind.

1. Die Lehre des erteilten Patentanspruchs 1 ist nicht neu gegenüber dem der Druckschrift [X.] entnehmbaren Stand der Technik.

So führt die Druckschrift [X.] den Fachmann zu [X.], einem System zur Bildsynthese und zur Erzeugung von [X.]ungen auf einer Anzeige (Seite 57, Abstract, siehe „[X.] is an architecture for high-speed, [X.], based on the techniques of [X.]-parallelism and image-composition.“; [X.]. 2; Seite 67, rechte Spalte, Abschnitt „Summary“, zweiter Absatz).

[X.] verarbeitet u. a. Texturen, was im Rahmen des [X.] stattfindet, bei dem endgültige Pixelfarbwerte auf der Grundlage von Texturen und [X.] berechnet werden (Seite 57, linke Spalte, Abschnitt „Introduction“, siehe „… to implement realistic rendering techniques such as user-programmable shading, [X.], [X.], [X.].“; Seite 58, linke Spalte, Abschnitt „[X.]“, zweites Aufzählungszeichen, siehe „[X.], [X.]“; Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, erster Absatz, siehe „[X.]“).

Die von [X.] erzeugten [X.]ungen umfassen verschiedene Objekte, [X.] Buchstaben (vgl. [X.]. 2), die sich aus einer Vielzahl von geometrischen [X.]en, [X.] Polygonen, Kugeln oder Quadriken zusammensetzen (Seite 67, rechte Spalte, Abschnitt „Summary“, zweiter Absatz, siehe „… [X.] can render primitives such as spheres, [X.], and volume data with high-quality shading methods …“), die durch Renderer auf Bildschirmkoordinaten abgebildet worden sind (Seite 58, linke Spalte, Abschnitt „[X.]“, erstes Aufzählungszeichen).

Nachdem jeder Renderer von [X.] für denselben vorgegebenen Bildschirmbereich seinen Anteil an [X.]en gerastert hat, werden die von den einzelnen Renderern erzeugten [X.] ([X.] pixel attributes), die diesen Bildschirmbereich betreffen, über ein Netzwerk (composition network) zusammengefasst und zur weiteren Verarbeitung an einen Shader übergeben ([X.]. 2; Seite 58, linke Spalte, Abschnitt „[X.]“, letzter Absatz, siehe „[X.], [X.] a shader.“).

Die berechneten [X.] stellen noch keine endgültigen Pixelfarbwerte dar, sondern bilden geometrische und spezifische [X.], [X.] Flächennormalen-Vektoren und Farben von Oberflächen (Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, erster Absatz, siehe „[X.], [X.] pixel attributes, such as surface-normal vectors and surface color; these attributes, not pixel colors, are composited.“).

Bei den [X.] handelt es sich um die [X.]n Fragmente, d. h. um Daten für Abschnitte von [X.]en bzw. Polygonen, die bestimmte Pixel schneiden, wobei die Fragmente zusammen ein Objekt ausmachen.

Merkmal [X.] ist somit in Druckschrift [X.] offenbart.

Die Weiterverarbeitung der [X.] erfolgt auf dem für den jeweiligen Bildschirmbereich zuständigen Shader, der für die einzelnen Pixel eine [X.] durchführt und endgültige Pixelfarbwerte berechnet (Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, erster Absatz, siehe „[X.]“).

Die Shading-Berechnungen können für viele Pixel simultan ausgeführt werden (Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, letzter Absatz).

Da in dem [X.] eines Shaders jedem [X.] ([X.]) genau ein Pixel bzw. Subpixel zugeordnet wird (Seite 61, linke Spalte, siehe Tabelle; Seite 62, linke Spalte, fünfter Absatz, siehe „The [X.]s are grouped into sets of 1, 4 or 8, [X.].“), kann jedes Pixel bzw. Subpixel unabhängig auf Grundlage der zugehörigen [X.] bzw. Fragmente errechnet werden (Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, erster Absatz, siehe „[X.], every subpixel sample can be shaded independently.“). Die [X.]e ([X.]) in Verbindung mit dem Textur-/Video-Subsystem ([X.]. 4; Seite 63, rechte Spalte, Abschnitt „Texture/Video Subsystem“, siehe [X.]s und [X.]) fungieren als [X.], weil sie u. a. Texturen anwenden (s. o.) und dabei zugleich wenigstens auf den Teil der [X.] bzw. Fragmente zurückgreifen, die an den Shader übergeben worden sind. Im Ergebnis lehrt die Druckschrift [X.] damit ein System, das über eine Mehrzahl von [X.] verfügt und eine Mehrzahl von Fragmenten verarbeitet (Merkmal [X.]).

Das Geometry Processor Board einer Shader Flow Unit umfasst einen [X.], der als Hauptspeicher für den Geometry Processor ([X.]) und als [X.] für [X.] an das [X.] mit [X.] und Textur-Subsystem dient (Seite 60, rechte Spalte, Abschnitt „Geometry Processor“, dritter Absatz). Der beschriebene Speicher stimmt mit dem in [X.]ur 3 dargestellten Program/Data Memory überein.

Darin sind Shader-spezifische [X.] gepuffert, [X.] solche für das Laden einer neuen Shadingfunktion (Seite 66, linke Spalte, zweiter Absatz). Da die Shader mit ihren [X.]en ([X.]) Texturen auf eine Mehrzahl von [X.] bzw. Fragmenten eines Bildschirmbereichs anwenden (Seite 58, linke Spalte, zweites Aufzählungszeichen, siehe „[X.] …“), handelt es sich wenigstens bei einem Teil dieser [X.] um solche für eine [X.], welche laut Druckschrift [X.] auf der Verarbeitung einer Mehrzahl von [X.]n beruht (Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, erster Absatz, siehe „[X.] …“).

Die [X.] gehen im Wesentlichen auf kleine Unterprogramme zurück, die auf einer [X.] hinterlegt sind, dort ablaufen und die Funktionen der [X.] [X.] aufrufen (Seite 66, linke Spalte, zweiter Absatz).

Demnach ist Merkmal [X.] in der Lehre der Druckschrift [X.] verwirklicht.

Dass der für die [X.] zuständige Programmteil tatsächlich über eine Mehrzahl von Anweisungen verfügt, ergibt sich direkt aus den Ausführungen zum Textur-/Video-Subsystem (Abschnitt 3.3). Mehrfaches Nachschlagen in Texturen (texture-lookups), Texturfiltern und [X.] (Seite 63, rechter Absatz, Abschnitt „Texture/Video Subsystem“, erster und zweiter Absatz), aber auch die Unterstützung von Funktionen wie bump mapping (Simulation von Oberflächenunebenheiten) oder environment mapping (Simulation spiegelnder Oberflächen) (Seite 63, rechte Spalte, vorletzter Absatz) sind, wie dem hier zuständigen Fachmann geläufig ist, ohne eine Reihe von [X.] nicht umzusetzen (Merkmal [X.].3).

Weiterhin werden die [X.]e ([X.]) und die [X.]s des [X.] über die Image Generation Controller ASICs ([X.]) durch die [X.] im [X.] des [X.] ([X.]) gesteuert und sind somit auch mit dem Speicher gekoppelt ([X.]. 4; Seite 64, linke Spalte, Abschnitt „[X.]“, erster Absatz – Merkmal [X.].4).

Jedes [X.] ([X.]) ist zusammen mit dem Textur-/Video-Subsystem in der Lage, eine Mehrzahl von [X.]n zu verarbeiten, die sich auf die [X.] eines Pixels und damit auf ein Fragment beziehen (Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, erster Absatz, siehe „[X.], [X.] normal, light sources, etc.“). Die [X.] werden aus einem Texturspeicher in den lokalen Speicher der [X.]e ([X.]) geladen und anschließend durch deren ALUs verarbeitet (Seite 63, rechte Spalte, erster Absatz; [X.]. 6). [X.]e ([X.]) und Textur-/Video-Subsystem werden dabei vollständig durch die [X.] des Geometry Processor Boards gesteuert (Seite 64, linke Spalte, Abschnitt „[X.]“). Die [X.] verläuft gemäß einem Programm, das nach dem [X.] gestaltet ist (Seite 66, linke Spalte, zweiter Absatz – Merkmal [X.]).

Die [X.]e ([X.]) arbeiten auf jedem Shader parallel (Seite 59, rechte Spalte, letzter Absatz, siehe „Shading calculations can be performed for many pixels simultaneously; …), so dass auch die [X.] bzw. die Verarbeitung von [X.]n für alle Pixel und Subpixel parallel erfolgt (siehe oben).

Die parallele [X.] findet für eine Mehrzahl von [X.]n statt, die zwar zu verschiedenen [X.] bzw. Fragmenten, aber zum selben Objekt gehören (Merkmal [X.]).

Die zur [X.] nötigen [X.] des Geometry Processor Boards werden in das [X.] und das Textur-/Video-Subsystem geladen und dort auf den einzelnen [X.]en ([X.]) und [X.]s des [X.]s ausgeführt (Seite 64, linke Spalte, Abschnitt „[X.]“). Durch Verwendung der [X.] [X.] wird die [X.] darüber hinaus auch programmierbar (Seite 65, rechte Spalte, Abschnitt „[X.] [X.]“, zweiter Absatz) (Merkmal [X.]).

Demnach offenbart das [X.]-System der Druckschrift [X.] sämtliche Merkmale des erteilten Patentanspruchs 1.

2. Dem Vorbringen der Beklagten, die Druckschrift [X.] lehre kein Programm mit Anweisungen für eine anspruchsgemäße Texturierung ([X.]), geschweige denn, dass entsprechende [X.] aus einem Speicher von mehreren [X.] parallel ausgeführt werden, kann nicht gefolgt werden.

2.1 In diesem Zusammenhang führt die Beklagte aus, dass die Druckschrift [X.] 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 [X.] 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 [X.] nicht zu finden.

Der Einwand vermag nicht zu überzeugen.

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

2.2 Nach Auffassung der Beklagten ist der Druckschrift [X.] an keiner Stelle zu entnehmen, dass speziell die Texturmischung in irgendeiner Form über die herkömmlichen, im [X.] 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 [X.] der Druckschrift [X.] nur auf [X.]-Version 1.0 beziehen. In dieser [X.]-Version sei aber eine Programmierbarkeit der Texturierung bzw. des [X.]s überhaupt nicht möglich gewesen.

Diese Argumentation ist ebenfalls nicht überzeugend.

Vielmehr kann aufgrund der Verwendung der [X.] [X.] auch auf eine programmierbare [X.] geschlossen werden (Seite 65, rechte Spalte, Abschnitt „[X.] [X.]“, 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 [X.] implementierten Funktionen stützt. Nichts Anderes trifft auf die in der Druckschrift [X.] angesprochene [X.]-Programmierschnittstelle der Version 1.0 zu. Dabei ist davon auszugehen, dass eine Programmierbarkeit i. S. d. [X.] 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 [X.] [X.] eröffnet dem Benutzer [X.] die Möglichkeit, Funktionen für bump mapping und [X.] in ein verteiltes Anwendungsprogramm nach dem [X.] einzubinden und dieses auf „[X.]“ auszuführen (Seite 63, rechte Spalte, vorletzter Absatz). Bump mapping und [X.] stellen bekanntlich prominente Beispiele für Spezialfälle einer [X.] dar. Das Einbinden der entsprechenden Softwarekomponenten aus der [X.]-Programmierschnittstelle in einen Programmcode zur Darstellung komplexer Grafik belegt, dass das in Druckschrift [X.] beschriebene System „als solches“ programmierbar war – wenn auch nicht unmittelbar aus einem beliebigen Grafikprogramm heraus, sondern nur über den Rückgriff auf die [X.]-Programmbibliothek; diese wiederum war aber grundsätzlich anpassbar und änderbar.

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

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

So sind die vom Geometry Processor ([X.]) an den [X.] und das Textur-Subsystem ausgegebenen [X.] im [X.] gepuffert ([X.]. 4; Seite 60, rechte Spalte, dritter Absatz „Memory … buffering [X.] rasterizer“). Wenigstens bei einem Teil dieser [X.] handelt es sich um solche für eine [X.], welche laut Druckschrift [X.] auf der Verarbeitung einer Mehrzahl von [X.]n beruht (Seite 59, rechte Spalte, Abschnitt „Deferred Shading“, erster Absatz, siehe „[X.] …“).

Der Fachmann wird unschwer erkennen, dass es sich bei den gespeicherten [X.] 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 [X.] hinterlegt sind, dort ablaufen und Funktionen der [X.] [X.] aufrufen (Seite 66, linke Spalte, zweiter Absatz). Die Funktionsaufrufe werden an die jeweiligen Shader verteilt und auf deren [X.] ([X.]) ausgeführt, wobei der Code für die jeweiligen [X.]en generiert wird (Seite 66, linke Spalte, zweiter und dritter Absatz). Der [X.] Speicher gemäß Merkmal [X.] ist damit in der Lehre der Druckschrift [X.] in Gestalt des [X.] verwirklicht.

3. Ausgehend von dem im [X.] genannten Stand der Technik argumentiert die Beklagte, die streitpatentgemäße Lösung diene vor allem dazu, über einen vorgefertigten Satz mathematischer Funktionen für ein [X.] hinauszugehen. Sie beruft sich dabei insbesondere auf die Absätze [0008] und [0021] der [X.]chrift, aus denen hervorgehe, dass herkömmliche [X.] allenfalls eine kleine Teilmenge an Mischoperationen unterstützten und deshalb nicht an beliebige Texturmischungen verschiedener Anwendungen angepasst werden konnten (Spalte 2, Zeilen 52 bis 58; Spalte 6, Zeilen 34 bis 38). Die streitpatentgemäße Lösung ermögliche demgegenüber eine solche Anpassbarkeit von [X.] mittels des anspruchsgemäßen Computerprogramms. Die Lehre der Druckschrift [X.] gehe aber nicht über die zum Prioritätstag des [X.] bekannten und im [X.] beschriebenen Lösungen hinaus. Nach Auffassung der Beklagten dürfe der erteilte Patentanspruch 1 nicht derart ausgelegt werden, dass dessen Gegenstand unter den genannten Stand der Technik falle.

Der Einwand der Beklagten geht bereits deswegen fehl, weil eine beliebige Anpassbarkeit von [X.] – was deren freie Programmierbarkeit durch ein beliebiges [X.] voraussetzen würde – in Merkmal [X.] auch in Verbindung mit den Merkmalen [X.] und [X.].3 ersichtlich nicht beansprucht wird. Durch die genannten Merkmale ist lediglich festgelegt, dass die [X.] ihre Berechnungen „in [X.]“ ausführen, wobei dieses (Teil-) Programm mehrere Anweisungen umfasst und in einem Speicher des Systems gespeichert ist. Ob das Programm aus einer Programmbibliothek stammt, die auf einer [X.] hinterlegt ist, oder ob das Programm von einem beliebigen (Grafik-) Programm übermittelt wurde, hat keinen Einfluss auf das [X.] System.

In diesem Zusammenhang ist zu beachten, dass eine Auslegung unterhalb des Wortlauts eines Patentanspruchs generell nicht zulässig ist; dies gilt insbesondere, wenn (wie im Fall des [X.]) der Beschreibung eine Schutzbegrenzung auf bestimmte Ausführungsformen nicht zu entnehmen ist (vgl. [X.], 309 – Schussfädentransport). Dabei erlaubt ein Ausführungsbeispiel regelmäßig keine einschränkende Auslegung eines die Erfindung allgemein kennzeichnenden Patentanspruchs (vgl. [X.], 1023 – Bodenseitige Vereinzelungseinrichtung).

Die aus dem [X.] Verb „to implement“ betreffend Merkmal [X.] abgeleitete Programmierbarkeitseigenschaft der [X.] – d. h. die Möglichkeit, lauffähigen Programmcode zu erstellen und auf diese zu übertragen – schließt nach fachmännischem Verständnis nicht aus, dass der Programmcode aus einer – naturgemäß in ihrem Umfang beschränkten, jedoch erweiterbaren – externen Programmbibliothek stammen könnte. Dass der erteilte Patentanspruch 1 nach einem solchen Verständnis möglicherweise Ausführungsformen mit umfasst, die unter den im [X.] genannten Stand der Technik fallen, ist für eine sachgerechte Auslegung ohne Belang.

4. Unter Berufung auf die von ihr eingeführten Dokumente [X.] bis [X.]0 macht die Beklagte weiterhin geltend, dass die zum Prioritätstag des [X.] bekannten Grafikchipsätze keine [X.] hätten ausführen können, weil sie lediglich eine fixed function pipeline zur Verfügung gestellt hätten. Fixed function bedeute, dass ein solcher Grafikchipsatz gerade nicht – sei es voll oder nur teilweise – programmierbar war und dass jegliche Funktion der Pipeline fest, d. h. unveränderlich in der Hardware vorgegeben gewesen sei („fest verdrahtet“). Den Druckschriften [X.] und [X.] sei diesbezüglich insbesondere zu entnehmen, dass sich der Ansatz der fixed function pipeline in Hinblick auf die Programmierung graphischer Effekte als zu unflexibel erwiesen habe, da die durch die Programmierschnittstellen [X.] und [X.] festgelegten Funktionen in Hardware implementiert gewesen seien (vgl. [X.], Seite 3, zweiter Absatz, siehe „[X.], to answer to the increasing demand for real-time graphics, [X.], i. e. non programmable hardware pipelines to fully programmable highly parallel many-core architectures …“; Seite 5, erster Absatz, siehe „[X.], an [X.], [X.], until the whole graphics pipeline was implemented in hardware on the card ([X.]).”; vgl. [X.], Seite 3, linke Spalte, letzter Absatz, siehe „[X.] was the [X.]. [X.].”). Die ersten auf [X.] voll programmierbaren Grafikkarten seien aber erst ab dem [X.] verfügbar gewesen (vgl. [X.], Seite 3, rechte Spalte, letzter Absatz, siehe „[X.], in 2002, [X.]: N… GeForce FX, ATI Radeon 9700.“).

Auch aus Dokument [X.] gehe hervor, dass bis in die späten 90er Jahre die führende Performance-Grafikhardware durch Fixed Function Pipelines gebildet worden sei, die zwar konfigurierbar, aber nicht programmierbar gewesen seien (vgl. [X.], Seite 22, Abschnitt 2.1.1, siehe „[X.], the leading performance graphics hardware was fixed-function pipelines that were configurable but not programmable“; Seite 26, zweiter Absatz, siehe „[X.] hardware resources and configurability to the pipeline stages, [X.]. [X.] was to make some of these graphics pipeline stages into programmable processors.”).

Ferner weist die Beklagte auf das Dokument [X.] hin, das sich mit der Programmierschnittstelle [X.] 8 (veröffentlicht im Jahr 2000) beschäftigt, die eine Programmierung von Grafikprozessoren auf [X.] ermöglichte (vgl. [X.], Seite 5, dritter Absatz). Im Gegensatz hierzu seien die früheren Versionen von [X.] ([X.] [X.] 6.0) Fixed Function gewesen, so dass Entwickler ihre Hardware nicht frei programmieren konnten und sich auf die statischen Funktionen in der [X.] verlassen mussten (vgl. [X.], Seite 1, zweiter Absatz). Nach Auffassung der Beklagten können die genannten Dokumente damit belegen, dass das [X.]-System der Druckschrift [X.] aus dem [X.] allenfalls über eine fixed function pipeline verfügte, so dass dessen [X.] weder voll noch teilweise programmiert, sondern lediglich konfiguriert werden konnte.

Zwar ist der Beklagten darin zuzustimmen, dass die häufigsten grundlegenden Funktionen des [X.]-Standards, der auch dem [X.]-System zugrunde liegt, rein auf [X.] nutzbar sind, d. h. Werte für die Parameter der [X.] [X.] werden an feste Funktionen übergeben, die dann die Texturierung steuern. Für Funktionalitäten, für die allerdings eine Konfiguration nicht in Frage kommt, kann eine Anwendung zusätzlich durch die Erweiterung von individuellem nativen Programmcode angereichert werden. In [X.] sind hierfür sogenannte Extensions für neue noch nicht vom Standard unterstützte Funktionen vorgesehen. Um eine Programmierbarkeit zu unterstützen, macht man sich auch im [X.]-System der Druckschrift [X.] die Eigenschaften solcher Extensions zunutze. So können unter [X.] [X.] die von einem Programmierer erstellten Prozeduren für Shading und Beleuchtung mittels [X.] Extensions in den Programmcode eines Shaders eingebunden und auf die zuständigen Prozessoren geladen werden. Insbesondere werden im [X.]-System Extensions angewandt, um benutzerdefinierte Parameter für ein Shading bereitzustellen, die von [X.] zu [X.] geändert werden können. Weitere Extensions betreffen u. a. die Festlegung von [X.], die neben anderen Textur- und Umgebungsparametern die Anwendung von Texturen steuern und infolgedessen auch das [X.] beeinflussen (vgl. [X.], Seite 65, Abschnitt 4.1, zweiter Absatz, siehe „[X.]. … We provide other [X.] extensions to set the values of user-defined shading parameters that can change on a primitive by primitive basis. [X.], such as surface normal and texture coordinates, but also arbitrary others, such as noise frequency, etc.”).

Alles in allem muss dieses als eine Programmierbarkeit der [X.] in [X.] verstanden werden. Allerdings handelt es sich hierbei nicht um eine freie, sondern eher um eine teilweise bzw. eingeschränkte Programmierbarkeit, die sich maßgeblich auf die in der [X.] [X.] implementierten Funktionen stützt. Der Patentanspruch 1 des [X.] schließt jedoch einen Zugriff auf [X.] als Quelle für den Programmcode, welcher jeweils die [X.] steuert, in keiner Weise aus.

5. Damit offenbart die Druckschrift [X.] alle Merkmale des Gegenstandes nach dem erteilten Patentanspruch 1. Dem Gegenstand des Patentanspruchs 1 gemäß Hauptantrag fehlt es daher an der für die Patentfähigkeit erforderlichen Neuheit.

6. Der auf „ein Verfahren zur Strukturverarbeitung für eine [X.]ung auf einer Anzeige“ gerichtete, nebengeordnete Patentanspruch 8 ist nicht günstiger als Patentanspruch 1 zu beurteilen, da er inhaltlich nicht über diesen hinausgeht und somit nichts enthält, was eine Patentfähigkeit rechtfertigen würde.

7. Weder der unabhängige Systemanspruch 1 noch der unabhängige Verfahrensanspruch 8 des [X.] haben daher Bestand. In seiner erteilten Fassung ist das [X.], dessen abhängige Unteransprüche die Beklagte nicht gesondert verteidigt hat, insgesamt für nichtig zu erklären.

Das [X.] ist in keiner der Fassungen der zur Akte gereichten [X.] bis [X.], [X.]a und [X.]I patentfähig. Im Hinblick darauf kann dahin gestellt bleiben, ob die Fassungen jeweils zulässig sind.

1. Dem Hilfsantrag I kann nicht stattgegeben werden, weil der Gegenstand seines Patentanspruchs 1 nicht neu ist.

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

Der unabhängige Patentanspruch 8 wurde entsprechend angepasst.

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

1.2 Die Merkmale [X.]´ und [X.].8 sind aus Druckschrift [X.] bekannt.

Bereits zum Hauptantrag ist ausgeführt, dass das [X.]-System der Druckschrift [X.] eine – wenn auch eingeschränkte – Programmierbarkeit der [X.] ermöglichte (Merkmal [X.]´).

Weiterhin ergibt sich aus den in der Druckschrift [X.] genannten Techniken der Bildsynthese, [X.] bump mapping oder [X.] (Seite 63, rechte Spalte, vorletzter Absatz), dass das [X.] eine von [X.] unterstützte Art der [X.] darstellte. So entnimmt der Fachmann der Druckschrift [X.], dass die genannten Techniken Operationen vorsehen, bei denen Texturen mit den Farbwerten von Fragmenten gemischt werden, um endgültige Farbwerte zu bekommen (vgl. [X.], Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz, siehe „[X.], [X.] normal, light sources, etc.“ – Merkmal [X.].8).

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

Zwar ist der Beklagten darin zuzustimmen, dass [X.] für sich gesehen kein programmierbares [X.] 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 [X.] nach fachmännischem Verständnis vielmehr vor, verschiedene Versionen eines originalen Bildes, sogenannte [X.] 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 [X.] aus den MipMap-Texturkarten Farbwerte ermittelt, die einer weiteren [X.] bereitgestellt werden. Dass diese Farbwerte als [X.] einem [X.] zugeführt werden, ergibt sich bereits aus der oben genannten Textstelle auf Seite 59 unter Abschnitt 2.5 der Druckschrift [X.]. Dort wird beschrieben, dass spezifische Pixelattribute, [X.] Farben von Oberflächen, von den [X.]en ([X.]) der Shader zusammen mit [X.]n zu endgültigen [X.]en bzw. -farben verarbeitet – also gemischt – werden (siehe „[X.] rasterizers do not compute pixel colors directly; instead, [X.] pixel attributes, such as surface-normal vectors and surface color; these attributes, not pixel colors, are composited. … [X.], [X.] 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. [X.], Seite 63, rechte Spalte, vorletzter Absatz) gewöhnlich mit einem [X.] verknüpft sind.

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

1.4 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.

Beantragt der Patentinhaber, das Patent in beschränktem Umfang mit einem bestimmten [X.] 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 [X.] als nicht patentfähig erweist (vgl. [X.], 862 – [X.]). 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 ([X.], 57 - Datengenerator).

Im vorliegenden Fall hat die Beklagte nur die Patentansprüche 1 und 8 des Hilfsantrags [X.], 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 [X.] beantragten Ausnahme, also für alle übrigen Hilfsanträge einschließlich des [X.], schließt dies eine separate Betrachtung einzelner Patentansprüche aus, wenn sich ein Patentanspruch des betroffenen [X.]es, wie hier, als nicht patentfähig erweist.

2. Der Hilfsantrag II kann nicht günstiger beurteilt werden, weil das zum Patentanspruch 1 hinzugekommene Merkmal ausgehend von Druckschrift [X.] nahegelegt ist.

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

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

2.2 Die Lehre des Patentanspruchs 1 gemäß Hilfsantrag II hat ausgehend von der Druckschrift [X.] nahegelegen.

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

Insbesondere werden in Druckschrift [X.] auf den Seiten 136 und 137 diejenigen Funktionen beschrieben, die in Abhängigkeit von der Anzahl der Farbanteile der Textur und dem [X.] ([X.], [X.], [X.], [X.]) 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 [X.] hingewiesen, die auf Seite 204 die unter der [X.]-Version 1.1 verfügbaren Funktionen zur Texturmischung näher erläutert.

Die Druckschrift [X.] offenbart damit zumindest die zum Prioritätstag des [X.] unter [X.] verfügbaren Funktionen zur [X.], 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 [X.]-basierten [X.]-System der Druckschrift [X.] die neueste Version der [X.] [X.] mit der größtmöglichen Funktionalität anzuwenden. Die [X.]e eines solchen angepassten [X.]-Systems, die als [X.] 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 [X.].9).

2.3 Die Beklagte macht geltend, dem [X.]-System der Druckschrift [X.] liege allenfalls [X.]-Version 1.0 zugrunde, das keine benutzerprogrammierbare [X.] erlaube. Letzteres gelte ebenso für die [X.]-Version 1.2.1 aus Druckschrift [X.].

Der Einwand der Beklagten geht bereits deswegen fehl, weil [X.] [X.] 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, [X.] [X.] festzulegen, die sich von [X.] zu [X.] ändern können (vgl. [X.], Seite 65, rechte Spalte, Abschnitt 4.1, zweiter Absatz), was sich wiederum auf die [X.] und das [X.] auswirkt. Nichts Anderes gilt nach Auffassung des Senats für ein [X.]-System, das sich auf [X.]-Version 1.2.1 mit Extensions stützt. Dass eine Verwendung von [X.]- Version 1.2.1 unter [X.] zum [X.] des [X.] grundsätzlich möglich gewesen sein muss, ergibt sich bereits aus der Tatsache, dass nahezu alle Komponenten von [X.] programmierbar waren (vgl. [X.], Seite 67, rechte Spalte, Abschnitt 6, zweiter Absatz, siehe „Virtually all of the components of [X.] are programmable: …“) und [X.] auch auf Rechenanlagen mit vielen Ressourcen implementiert werden konnte (vgl. [X.], Seite 67, rechte Spalte, Abschnitt 6, dritter Absatz, siehe „[X.] parallel supercomputer, it can serve as a visualization subsystem for immediate-mode rendering.“).

2.4 Die Beklagte argumentiert, der Spezifikation [X.] sei allenfalls ein begrenzter mathematischer Funktionensatz für ein [X.] zu entnehmen (vgl. [X.], Seite 137), der keine Programmierbarkeit der [X.] gestatte.

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

2.5 Damit ist auch der Patentanspruch 1 in der Fassung des [X.]I nicht patentfähig. Mit dem Patentanspruch 1 fällt der gesamte Hilfsantrag.

3. Hilfsantrag III hat keinen Erfolg, weil der Gegenstand seines Patentanspruchs 1 durch die Druckschrift [X.] zumindest nahegelegt ist.

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

3.2 Aus der Druckschrift [X.] folgt, dass das dort offenbarte [X.]-System aufgrund der [X.] [X.] programmierbar war. Außerdem war das bekannte System nicht auf die Anwendung einer einzigen Textur auf Fragmente eingeschränkt (vgl. [X.], 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 [X.]- Version 1.2.1 basierendes [X.]-System dank der im [X.]-Standard bereitgestellten Texturfunktionen (s. o.) derart programmierbar bzw. anpassbar, dass nicht nur eine, sondern eine Vielfalt an Texturmischungen ausgeführt werden konnte (Merkmal [X.].9´).

3.3 Die Beklagte führt aus, dass aus den Druckschriften [X.] und [X.] keine Vielzahl von Texturmischungen i. S. d. Merkmals [X.].9´ hervorgehe.

Der Einwand überzeugt nicht.

So offenbart die Druckschrift [X.], dass in [X.] grundsätzlich eine Mehrzahl von Texturen mit [X.] angewendet werden konnte (vgl. [X.], Seite 63, Abschnitt 3.3, zweiter Absatz, siehe „[X.]) texture maps can be interleaved across the banks so [X.] separate banks.“), was bei vorgefilterten [X.] je nach Textur und Auflösung zu unterschiedlichen Texturmischungen führte. Außerdem geht aus der Spezifikation [X.] hervor, dass die mathematischen [X.] 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 [X.]-Version 1.2.1 basierendes [X.]-System die Eigenschaft, eine Vielfalt von Texturmischungen durchzuführen.

3.4 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 [X.]

4. Hilfsantrag [X.] hat keinen Erfolg, weil der Gegenstand seines Patentanspruchs 1 nicht neu ist.

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

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

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

So offenbart Druckschrift [X.] in [X.]ur 5, dass ein [X.] und damit auch die jeweiligen [X.]e ([X.]) (die ja als [X.] fungieren) [X.] („instructions“) erhalten. Die jeweils zu verarbeitende Textur wird von einem [X.] ([X.]) über den „Input Buffer“ geladen (vgl. [X.], [X.]. 5, 6; Seite 63, rechte Spalte, erster und zweiter Absatz).

Weiterhin geht – wie bereits zum Hauptantrag ausgeführt - aus der Druckschrift [X.] hervor, dass die vom Geometry Processor ([X.]) erzeugten und im [X.] zwischengespeicherten [X.] über die Controller-[X.] an die [X.]e ([X.]) ausgegeben werden. Die Anweisungen werden von diesen geladen bzw. importiert und demnach auch zur [X.] verwendet (vgl. [X.], Seite 64, linke Spalte, Abschnitt 3.4, erster und zweiter Absatz, siehe „[X.] micro-instruction to the [X.]s.“).

Mit Rücksicht auf die Ausführungen zum Hauptantrag bzw. Hilfsantrag I sind die Merkmale [X.]´ und [X.]´ damit aus der Druckschrift [X.] bekannt.

4.3 Die Beklagte führt aus, in der Lehre der Druckschrift [X.] werde keine Mehrzahl von [X.] an die [X.]e [X.]s übergeben. Dementsprechend werde dort auch kein Programmteil geladen und ausgeführt.

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

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

5. Hilfsantrag V hat keinen Erfolg, da die Lehre seines Patentanspruchs 1 mit Rücksicht auf den der Druckschrift [X.] entnehmbaren Stand der Technik nicht neu ist.

5.1 Der Hilfsantrag V beruht auf dem Hilfsantrag [X.], wobei in Patentanspruch 1 Merkmal [X.]´ gegen Merkmal [X.] ausgetauscht und der Patentanspruch 1 um Merkmal [X.]a ergänzt wurde. Patentanspruch 8 wurde dementsprechend angepasst.

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

5.2 Das neu hinzugekommene Merkmal [X.]a kann eine Patentfähigkeit des Patentanspruchs 1 gemäß Hilfsantrag V nicht begründen, da es aus Druckschrift [X.] bekannt ist.

Druckschrift [X.] zeigt, dass den [X.]en ([X.]), die die Aufgaben von [X.] übernehmen, [X.] und zu verarbeitende Texturen bereitgestellt werden (vgl. [X.], Seite 64, linke Spalte, Abschnitt 3.4, erster und zweiter Absatz, siehe „[X.] micro-instruction to the [X.]s.“; [X.]. 6, siehe „[X.] [X.]“; Seite 63, rechte Spalte, erster und zweiter Absatz). Die den [X.]en ([X.]) zugeführten [X.], die die [X.]n Fragmente repräsentieren (vgl. [X.], Seite 58, linke Spalte, vorletzter Absatz, siehe „[X.] pixel attributes“), setzen sich aus geometrischen und spezifischen [X.] zusammen (Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz, siehe „… instead, [X.] pixel attributes, such as surface-normal vectors and surface color …“). Die Bereitstellung von Fragmenten, [X.] und [X.] für [X.] i. S. d. Merkmals [X.]a geht damit aus der Druckschrift [X.] hervor.

5.3 Die Beklagte argumentiert, in Abschnitt 3.4 der Druckschrift [X.] sei allenfalls ein Strom aus [X.] offenbart, jedoch keinerlei Fragmente, die zudem laut Merkmal [X.]a [X.] beinhalten müssten.

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

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

6. Gleiches gilt für das [X.] in seiner Fassung nach Hilfsantrag VI, weil das gegenüber dem Hilfsantrag V einschränkende Merkmal aus der Druckschrift [X.] bekannt ist.

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

6.2 Das neu hinzugekommene Merkmal [X.]0 geht aus Druckschrift [X.] hervor.

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

Weiterhin ist Druckschrift [X.] nicht nur die Zuordnung der [X.]e ([X.]) zu den einzelnen Pixeln (vgl. [X.], Seite 62, linke Spalte, fünfter Absatz, siehe „The [X.]s are grouped into sets of 1, 4 or 8, [X.].“) zu entnehmen, sondern auch der Hinweis, dass jedes Subpixel (und somit bei 1 [X.] pro Pixel auch jedes Pixel) unabhängig (und vollständig) zusammen mit den Shading-Informationen verarbeitet werden kann (vgl. [X.], Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz, siehe „[X.], every subpixel sample can be shaded independently.“). Hieraus folgt, dass ein einzelnes [X.] ([X.]) 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 [X.] für das Pixel ablaufen kann. Dabei ist zu beachten, dass Merkmal [X.]0 bereits dann erfüllt ist, wenn die gesamte [X.] für eine einzige Textur und ein einziges Pixel auf einem der [X.]e ([X.]) erfolgt.

Merkmal [X.]0 ist somit aus Druckschrift [X.] bekannt.

6.3 Die Beklagte führt aus, Druckschrift [X.] offenbare nicht, dass sämtliche Operationen einer [X.] bzw. eines [X.]s an einem Fragment auf ein und demselben [X.] ([X.]) stattfinden.

Dem Einwand kann nicht zugestimmt werden; denn der Fachmann entnimmt Abschnitt 2.5 der Druckschrift [X.] 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. [X.], Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz). Demnach ist aber auch die ganze [X.] bzw. das ganze [X.] eines Subpixels bzw. Pixels auf dem ihm zugeordneten [X.] ([X.]) unabhängig vom Shading auf den anderen [X.]en ([X.]), d. h. eine Verteilung der [X.] bzw. des [X.]s an einem einzigen Subpixel bzw. Pixel auf mehrere [X.]e ([X.]) lässt sich aus der genannten Textstelle gerade nicht ableiten. Vielmehr ist in der Lehre der Druckschrift [X.] davon auszugehen, dass das gesamte Shading und somit auch die gesamte [X.] an einem Subpixel bzw. Pixel auf einem [X.] ([X.]) ausgeführt wird.

6.4 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.

7. Hilfsantrag [X.] kann nicht günstiger beurteilt werden, da die jeweiligen Lehren seiner unabhängigen Patentansprüche 1 und 8, die von der Beklagten ausdrücklich auch einzeln verteidigt werden, nicht auf erfinderischer Tätigkeit beruhen.

7.1 Der Hilfsantrag [X.] beruht auf dem Hilfsantrag [X.], wobei in Patentanspruch 1 die Merkmale [X.]1 und [X.]2 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 [X.]V hinaus jedes Fragment eine [X.] umfassen, wobei der zur [X.] notwendige „Teil des Programms“ anhand dieser [X.] bestimmt und geholt bzw. importiert wird.

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

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

Dies begründet sich [X.] durch die Druckschrift [X.], welche eine etwas frühere Realisierungsstufe desselben [X.]-Systems betrifft ([X.] Seite 59 „Abstract“, dritter Absatz, siehe „[X.], an [X.]“) und in der Druckschrift [X.] zitiert wird ([X.] Seite 68 „LAST95“).

So offenbart die Druckschrift [X.] die Anwendung verschiedener Programmiermodelle auf das [X.]-System der Druckschrift [X.], insbesondere auf dessen Shader Flow Units (vgl. [X.], Seite 64, Abschnitt „Shader programming model“). Auch anhand der Druckschrift [X.] wird klar, dass eine Programmierung der [X.] vor dem Prioritätsdatum des [X.] bereits bekannt war (vgl. [X.], 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 [X.] beschriebenen Forschungsarbeiten in die [X.]e ([X.]) des SIMD-Prozessors geladen und dort zur Ausführung gebracht werden konnte. Mit anderen Worten: die [X.]e ([X.]), die die Aufgaben von [X.] übernehmen, waren programmierbar.

In diesem Zusammenhang offenbart die Druckschrift [X.] eine [X.] i. S. d. Hilfsantrags [X.], die als [X.] bezeichnet wird und die Bestandteil einer Datenstruktur für „[X.] ist (vgl. [X.], [X.]. 8). Die [X.] wird vom Steuerprogramm für das Shading benutzt, um für jedes Pixel einen Shader Code, d. h. einen Programmteil auszuwählen (vgl. [X.], Seite 65, linke Spalte, Abschnitt 4.1, zweiter Absatz). Dass dieser Shader Code u. a. für die [X.] auf den Shadern bzw. deren [X.]en ([X.]) zuständig ist, ergibt sich [X.] aus [X.]ur 9, wo auf die Anwendung verschiedener Texturen Bezug genommen wird. Der Fachmann wird obige Datenstruktur für „[X.] als das [X.] Fragment verstehen, das u. a. eine [X.] als [X.] beinhaltet und das an die [X.]e ([X.]) zur [X.] übergeben werden muss. Anhand der [X.], die mitsamt dem Fragment übermittelt wird, wird der zum Fragment passende Shading-Programmcode für das [X.] ([X.]) ausgewählt. Die Merkmale [X.]1 und [X.]2 sind demnach aus der Druckschrift [X.] bekannt.

Da die Lehre der Druckschrift [X.] auf das 1995 bekannte experimentelle Grafiksystem [X.] zugeschnitten und auf diesem demonstriert worden war ([X.] Seite 59 „Abstract“, dritter Absatz, siehe „[X.], an [X.]“), war es ohne Weiteres naheliegend, diese Lehre auch noch bei dem konkret zwei Jahre später beschriebenen [X.]-System gemäß Druckschrift [X.] anzuwenden.

7.2.2 Die Beklagte weist darauf hin, dass in der Lehre der Druckschrift [X.] nicht vorgesehen sei, ein Fragment mit [X.] an einen Texturprozessor zu übergeben, mit deren Hilfe der Texturprozessor einen Programmteil importiert.

Dem Einwand kann nicht zugestimmt werden. So lehrt die Druckschrift [X.], dass die „Appearance“- bzw.- „Shader-Parameter“ aus [X.]ur 8, die zusammen ein Fragment bilden, im [X.]-System auf zwei verschiedenen Übertragungswegen an einen Shader kommuniziert werden: einerseits kann die Übertragung über das „Geometry Network“, andererseits über das „Composition Network“ erfolgen (vgl. [X.], Seite 64, linke Spalte, Abschnitt „Shader parameters“, erster und zweiter Absatz, siehe „[X.]. [X.]. [X.].“; Seite 63, linke Spalte, Abschnitt 3.2, zweiter Absatz, siehe „[X.], they send appearance parameters and depth values for each pixel onto the image-composition network, [X.].“). Insbesondere können die Parameter in den lokalen Speicher eines [X.] ([X.]) geschrieben werden, wenn sie dort zur Verarbeitung benötigt werden (vgl. [X.], Seite 64, linke Spalte, Abschnitt „Shader parameters“, zweiter Absatz, siehe „[X.] the local memory of the pixel processors, [X.].“). Der lokale Speicher eines [X.] ([X.]) wird indes in Druckschrift [X.] näher beschrieben (vgl. [X.], Seite 62, Abschnitt „[X.]“ und [X.]. 6). Für den Fachmann ist ohne Weiteres ersichtlich, dass dementsprechend auch die [X.] als [X.] an ein [X.] ([X.]) geschickt werden muss, wenn anhand von [X.]n des Steuerprogramms ein Shader code für ein Pixel ausgewählt und abgearbeitet werden soll (vgl. [X.], Seite 65, linke Spalte, Abschnitt 4.1, zweiter Absatz, siehe „The shader ID is used by the shading control program to select the shader code for each pixel.“).

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

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

Da die Druckschrift [X.] mit der [X.] gerade eine solche [X.] 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 [X.], auf dem der Patentanspruch 8 gemäß Hilfsantrag [X.] beruht, inhaltlich nicht über den Patentanspruch 1 gemäß Hilfsantrag [X.] hinausgeht, ist auch die Lehre des Patentanspruchs 8 gemäß Hilfsantrag [X.] mit Rücksicht auf den den Druckschriften [X.] und [X.] entnehmbaren Stand der Technik nahegelegt.

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

8. Hilfsantrag [X.]a in der Fassung vom 19. November 2020 kann nicht günstiger beurteilt werden, da die Lehre seines Patentanspruchs 1 nicht auf erfinderischer Tätigkeit beruht.

8.1 Patentanspruch 1 gemäß Hilfsantrag [X.]a beruht auf Patentanspruch 1 gemäß Hilfsantrag [X.], wobei Merkmal [X.]2 durch Merkmal [X.]2´ 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“.

Der Senat versteht das neue Merkmal [X.]2´ so, dass unter Verwendung der [X.] wenigstens ein Teil des Programms von jedem Texturprozessor genutzt wird.

Insoweit geht Patentanspruch 1 gemäß Hilfsantrag [X.]a inhaltlich nicht über Patentanspruch 1 gemäß Hilfsantrag [X.] 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 [X.] hingewiesen.

8.2 Mit dem Patentanspruch 1 gemäß Hilfsantrag [X.]a fällt der gesamte Hilfsantrag.

8.3 Unter den vorgenannten Umständen kann dahinstehen, ob der Hilfsantrag [X.]a schon wegen Verspätung nach § 83 Abs. 4 Satz 1 [X.] zurückzuweisen war.

9. In seiner Fassung nach Hilfsantrag [X.]I hat das [X.] keinen Bestand, weil der Gegenstand seines Patentanspruchs 1 nicht neu ist.

9.1 Der Hilfsantrag [X.]I beruht auf dem Hilfsantrag VI, wobei der Patentanspruch 1 um das Merkmal [X.]3 ergänzt wurde. Das neue Merkmal schränkt die Verarbeitung der [X.] dahingehend ein, dass nur dann eine Ausgabe erzeugt wird, wenn die Verarbeitung des Fragments abgeschlossen ist.

Der unabhängige Patentanspruch 8 wurde entsprechend angepasst.

9.2 Das in Patentanspruch 1 gemäß Hilfsantrag [X.]I hinzugekommene Merkmal kann eine Patentfähigkeit nicht begründen.

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

Merkmal [X.]3 ist demnach in der Druckschrift [X.] offenbart.

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

Der Einwand greift nicht durch. So ist bereits zu Hilfsantrag VI ausgeführt, dass im [X.]-System der Druckschrift [X.] ein [X.] ([X.]) das komplette Shading bzw. die gesamte [X.] 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 [X.] ([X.]) abgeschlossen ist, wird dieses an den Framebuffer zur Anzeige ausgegeben (vgl. [X.], Seite 59, rechte Spalte, Abschnitt 2.5, erster Absatz, siehe „[X.], regions of shaded pixels are forwarded to a frame buffer for display.“).

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

10. Aus diesen Gründen war das [X.], das somit in keiner seiner durch die Beklagte verteidigten Fassungen Bestand hatte, insgesamt für nichtig zu erklären.

Nach dem Vorstehenden kommt es auf die Frage einer offenkundigen Vorbenutzung des sogenannten Voodoo

Die Kostenentscheidung beruht auf § 84 Abs. 2 Satz 1 und 2 [X.], § 91 Abs. 1, § 269 Abs. 3 Satz 2 ZPO.

Die Klägerin zu 3, die bereits im Januar 2020 die Klage zurückgenommen hat, ist im [X.] des Urteils hinsichtlich der Gerichtskosten noch zu berücksichtigen, weil die Klagerücknahme nicht den gesamten Streitgegenstand betrifft (vgl. [X.], 599, Rn. 69 – [X.]; [X.], 1741). Einen Antrag nach § 269 Abs. 4 ZPO, über die Kostenverpflichtung bei Klagerücknahme nach § 269 Abs. 3 Satz 2 ZPO zu entscheiden, hat die Beklagte nicht gestellt; über die außergerichtlichen Kosten ist daher insoweit keine Entscheidung veranlasst. Hinsichtlich der Gerichtskosten war hingegen gemäß § 84 Abs. 2 Satz 1 [X.], § 308 Abs. 2 ZPO auch ohne Antrag der Beklagten aus den eingangs genannten Gründen eine einheitliche Entscheidung im Urteil zu treffen.

Der Ausspruch über die vorläufige Vollstreckbarkeit beruht auf § 99 Abs. 1 [X.] [X.] § 709 ZPO.