18 W (pat) 88/14  - 18. Senat (Techn.Beschw.)

BPatG 154 05.11 BUNDESPATENTGERICHT 18 W (pat) 88/14 _______________ (Aktenzeichen) Verkündet am 27. März 2015 … B E S C H L U S S In der Beschwerdesache betreffend die Patentanmeldung 10 2008 044 843.5 - 53 … - 2 - hat der 18. Senat (Techn. Beschwerdesenat) des Bundespatentgerichts auf die mündliche Verhandlung vom 27. März 2015 durch die Vorsitzende Richterin Dipl.-Ing. Wickborn sowie den Richter Kruppa, die Richterin Dipl.-Phys. Dr. Otten-Dünnweber und den Richter Dipl.-Ing. Altvater beschlossen: Die Beschwerde der Anmelderin wird zurückgewiesen. G r ü n d e I. Die am 28. August 2008 beim Deutschen Patent- und Markenamt eingereichte Patentanmeldung 10 2008 044 843.5 mit der Bezeichnung „Verfahren und System zum Verteilen von Applikationen“ wurde mit Beschluss der Prüfungsstelle für Klasse G 06 F des Deutschen Patent- und Markenamts vom 29. Oktober 2010 mit der Begründung zurückgewiesen, dass der Gegenstand des Patentanspruchs 1 nicht patentierbar sei, da er im Hinblick auf die Druckschriften D1 DE 10 2006 051 189 A1 und D2 Hansen, S.: Composite Device Using a Distributed MVC Architecture. Center for Pervasive Computing, Univ. of Aarhus, 2005 (recherchiert von der Prüfungsstelle am 18. Juni 2009) - 3 - nicht auf erfinderischer Tätigkeit beruhe. Gegen diesen Beschluss richtet sich die Beschwerde der Anmelderin. Sie beantragt, den Beschluss der Prüfungsstelle für G06F des Deutschen Patent- und Markenamts vom 29. Oktober 2010 aufzuheben und das Patent auf der Grundlage der folgenden Unterlagen zu erteilen: - Patentansprüche 1 bis 12, eingegangen am 26. August 2009, hilfsweise gemäß Hilfsantrag 1 Patentansprüche 1 bis 12, eingereicht in der mündlichen Verhandlung, hilfsweise gemäß Hilfsantrag 2 Patentansprüche 1 bis 8, eingereicht in der mündlichen Verhandlung, - Beschreibung, Seiten 1 und 4 bis 12, eingegangen am 28. August 2008, Seiten 2, 3 und 3a eingegangen am 26. August 2009, - Figuren 1 bis 5, eingegangen am 28. August 2008. Der seitens des Senats mit einer Gliederung versehene Patentanspruch 1 ge-mäß Hauptantrag lautet: M1 „Verfahren zum Verteilen von Applikationen (A1, A2) in einem Datenver-arbeitungsnetzwerk (1), M2 mit mindestens zwei Applikationen (A1, A2) zur Verarbeitung von Bilddaten, die mit bildgebenden Diagnosegeräten (3,4) gewonnen wurden, - 4 - M3 welche Applikationen (A1, A2) sich hinsichtlich der zu verarbeitenden Da-tenmengen voneinander unterscheiden, M4 wobei es sich bei der zur Verarbeitung der kleineren Datenmenge vorge-sehen Applikation (A1) um eine 2D-Applikation und bei der zur Verarbeitung der größeren Datenmenge vorgesehen Applikation (A2) um eine 3D-Appli-kation handelt, M5 wobei jede Applikation (A1, A2) mehrschichtig aufgebaut ist und M5a einzelne Schichten (M, V, C) der Applikationen (A1, A2) derart auf unterschiedliche Hardwareressourcen (5, 6, 7), M5b nämlich mindestens eine lokale Datenverarbeitungseinheit (5, 6) und mindestens eine entfernte Datenverarbeitungseinheit (7), verteilt werden, M5c dass der Anteil der auf der lokalen Datenverarbeitungseinheit (5, 6) installierten Schichten (M, V, C) an der Gesamtzahl der Schichten (M, V, C) der jeweiligen Applikation (A1, A2) bei derjenigen Applikation (A2), welche zur Verarbeitung der größeren Datenmenge vorgesehen ist, kleiner ist als bei der zur Verarbeitung der kleineren Datenmenge vorgesehenen Applikation (A1).“ Patentanspruch 4 gemäß Hauptantrag lautet: „System zum Verteilen von Applikationen (A1, A2) zur Verarbeitung von Bilddaten, die mit bildgebenden Diagnosegeräten (3, 4) gewonnen wurden, umfassend mindestens eine lokale Datenverarbeitungseinheit (5, 6) und mindestens eine entfernte Datenverarbeitungseinheit (7), wobei auf die Datenverarbeitungseinheiten (5, 6, 7) mindestens zwei, jeweils mehrschich-tige Applikationen (A1, A2) verteilt sind, von welchen eine Applikation (A2) zur Verarbeitung einer größeren Datenmenge und eine weitere Applikation (A1) zur Verarbeitung einer kleineren Datenmenge vorgesehen ist, wobei es sich bei der zur Verarbeitung der kleineren Datenmenge vorgesehen - 5 - Applikation (A1) um eine 2D-Applikation und bei der zur Verarbeitung der größeren Datenmenge vorgesehen Applikation (A2) um eine 3D-Applikation handelt und wobei der Anteil der auf der lokalen Datenverarbeitungseinheit (5, 6) installierten Schichten (M, V, C) an der Gesamtzahl der Schichten (M, V, C) der jeweiligen Applikation (A1, A2) bei derjenigen Applikation (A2), welche zur Verarbeitung der größeren Datenmenge vorgesehen ist, kleiner als bei der zur Verarbeitung der kleineren Datenmenge vorgesehenen Applikation (A1) ist.“ Anspruch 12 gemäß Hauptantrag lautet: „Verwendung des Systems nach Anspruch 4 zur Verarbeitung medizintech-nischer Bilddaten.“ Wegen der geltenden abhängigen Ansprüche 2, 3 und 5 bis 11 gemäß Haupt-antrag wird auf den Akteninhalt verwiesen. Patentanspruch 1 gemäß Hilfsantrag 1 unterscheidet sich von Anspruch 1 ge-mäß Hauptantrag durch Anfügen des folgenden Merkmals M6a nach Merkmal M5c: „[…], M6a wobei das Datenverarbeitungsnetzwerk (1) ein zentrales Archiv (2) auf-weist, mit welchem sowohl die zur Verarbeitung einer größeren Daten-menge vorgesehene Applikation (A2) als auch die zur Verarbeitung einer kleineren Datenmenge vorgesehene Applikation (A1) zusammenwirkt.“ Patentanspruch 4 gemäß Hilfsantrag 1 unterscheidet sich von Anspruch 4 ge-mäß Hauptantrag ebenfalls durch Anfügen des vorstehend aufgeführten Merkmals M6a am Ende des Anspruchs. - 6 - Anspruch 12 gemäß Hilfsantrag 1 ist wortidentisch zu Anspruch 12 gemäß Hauptantrag. Wegen der geltenden abhängigen Ansprüche 2, 3 und 5 bis 11 gemäß Hilfs-antrag 1 wird auf den Akteninhalt verwiesen. Patentanspruch 1 gemäß Hilfsantrag 2 unterscheidet sich von Anspruch 1 ge-mäß Hauptantrag durch Anfügen der folgenden Merkmale M5d bis M6b nach Merkmal M5c: „[…], M5d wobei jede Applikation eine Präsentationsschicht, eine Geschäftsprozess-Schicht und eine Controllerschicht umfasst, M5e wobei die zur Verarbeitung der kleineren Datenmenge vorgesehene Appli-kation eine Rich Client Konfiguration bildet, und M5f wobei die zur Verarbeitung der größeren Datenmenge vorgesehene Appli-kation eine Rich Thin Client Konfiguration bildet, M6a wobei das Datenverarbeitungsnetzwerk (1) ein zentrales Archiv (2) auf-weist, mit welchem sowohl die zur Verarbeitung einer größeren Datenmen-ge vorgesehene Applikation (A2) als auch die zur Verarbeitung einer kleine-ren Datenmenge vorgesehene Applikation (A1) zusammenwirkt, M6b das der Speicherung und Verarbeitung der zweidimensionalen und dreidi-mensionalen Bilddaten dient.“ Patentanspruch 4 gemäß Hilfsantrag 2 unterscheidet sich von Anspruch 1 gemäß Hauptantrag durch Anfügen der folgenden Merkmale am Ende des An-spruchs: „[…], - 7 - wobei jede Applikation (A1, A2) eine Präsentationsschicht (V), eine Ge-schäftsprozess-Schicht (M) und eine Controllerschicht (C) umfasst, wobei die zur Verarbeitung der kleineren Datenmenge vorgesehene Appli-kation (A1) eine Rich Client Konfiguration bildet, und wobei die zur Verarbeitung der größeren Datenmenge vorgesehene Appli-kation (A2) eine Rich Thin Client Konfiguration bildet, wobei das Datenver-arbeitungsnetzwerk (1) ein zentrales Archiv (2) aufweist, mit welchem so-wohl die zur Verarbeitung einer größeren Datenmenge vorgesehene Applikation (A2) als auch die zur Verarbeitung einer kleineren Datenmenge vorgesehene Applikation (A1) zusammenwirkt, das der Speicherung und Verarbeitung der zweidimensionalen und dreidimensionalen Bilddaten dient.“ Anspruch 8 gemäß Hilfsantrag 2 ist wortidentisch zu Anspruch 12 gemäß Haupt-antrag. Wegen der geltenden abhängigen Ansprüche 2, 3 und 5 bis 7 gemäß Hilfsantrag 2 wird auf den Akteninhalt verwiesen. Die Beschwerdeführerin führt aus, dass die geltenden Ansprüche zulässig und im Lichte des im Verfahren befindlichen Standes der Technik patentfähig seien. Wegen der weiteren Einzelheiten wird auf den Akteninhalt verwiesen. II. Die form- und fristgerecht eingelegte und auch im Übrigen zulässige Beschwerde ist nicht begründet, da sich der Gegenstand des jeweiligen Anspruchs 1 des Hauptantrags und der Hilfsanträge 1 und 2 jeweils als nicht patentfähig erweist. - 8 - Die Frage der Zulässigkeit des jeweils verteidigten Verfahrens gemäß Anspruch 1 kann daher dahinstehen (vgl. BGH, Urteil X ZR 29/89 vom 18. September 1990, GRUR 1991, 120, 121 li. Sp. Abs. 3 – Elastische Bandage). 1. Die Anmeldung betrifft ein Verfahren und ein System zum Verteilen von Applikationen in einem Datenverarbeitungsnetzwerk, insbesondere in ei-nem Datenverarbeitungsnetzwerk einer medizinischen Einrichtung (vgl. gel-tende Beschreibung, Seite 1, Zn. 5-9). Die Anmeldung geht davon aus, dass aus Druckschrift D1 ein Verfahren zum Erstellen und Ausführen zumindest einer mehrschichtigen Applikation in Abhängigkeit von einer Einsatzumgebung bekannt sei. Die Applikation sei n-schichtig strukturiert und weise eine Präsentationsschicht zur Dar-stellung von Informationen und für Benutzerinteraktionen, eine Geschäfts-prozess-Schicht, die unterschiedliche Geschäfts-Prozess-Logik-Module umfasse, sowie eine Controllerschicht auf. Im Rahmen der Verteilung der Schichten dieser Applikation („Deployment“) könnten verschiedene Szena-rien zum Tragen kommen, nämlich Thin-Client, Rich-Thin-Client, Rich-Client, Adaptive-Client, Fat-Client und Web-Service. Im Fall eines Rich-Thin-Client könne die Controller-Schicht zweigeteilt beziehungsweise als Netzwerkfunktionalität ausgelegt sein, wodurch auf einem leistungsstarken Rechner, den sich mehrere Anwender teilen, viele rechenaufwändige Vor-gänge abgearbeitet werden könnten. Vorzugsweise seien die verschiede-nen Schichten unabhängig von der Deployment-Strategie programmiert. Die flexible, je nach Bedarf und Einsatzumgebung herunterladbare Appli-kations-Architektur erkenne, in welchem Einsatz sich eine Applikation gera-de befinde. Häufig verwendete Bezeichnungen für Schichten einer solchen Systemarchitektur seien „Model“, „View“ und „Controller“, die zusammen-fassend auch als MVC Softwaremuster bezeichnet würden. In diesem Zu-sammenhang verweist die Anmeldung beispielgebend auf die als - 9 - DE 196 25 841 A1 und DE 10 2005 010 405 A1 veröffentlichten Patentan-meldungen. Die Anmeldung geht weiter davon aus, dass in Krankenhäusern vermehrt PACS-Systeme (Picture Archiving and Communication System) zum Einsatz kämen, deren Anwendungsmöglichkeiten zum Beispiel in der als DE 10 2006 033 861 A1 veröffentlichten Patentanmeldung offenbart seien. PACS-Systeme seien prinzipiell zur Verarbeitung jeglicher in digitaler Form vorliegender Bilddaten geeignet. Ein grundsätzliches Problem stelle das zunehmende Datenvolumen dar, welches in medizintechnischen Datenver-arbeitungsnetzwerken zu beherrschen sei. (vgl. geltende Beschreibung, S. 1, Z. 10 bis S. 2, Z. 30). Die Anmeldung nennt als Aufgabe, die Leistungsfähigkeit von Datenverar-beitungssystemen, welche mit mehrschichtigen Applikationen arbeiten, ins-besondere im Hinblick auf limitierte Netzwerkressourcen, gegenüber dem Stand der Technik zu steigern (vgl. geltende Beschreibung, S. 3, Zn. 1-5). Die objektive technische Problemstellung ist darin zu sehen, eine geeignete Aufteilung der Abarbeitung von einzelnen Schichten mehrschichtiger Appli-kationen auf lokale und entfernte Datenverarbeitungseinheiten eines Daten-verarbeitungssystems bei der Verarbeitung von medizinischen Bilddaten in Form von 3D-Bilddaten mit großen Datenmengen sowie 2D-Bilddaten mit geringen Datenmengen vorzunehmen. Diese Aufgabe richtet sich an einen Fachmann, der eine abgeschlossene Hochschulausbildung auf dem Gebiet der Elektrotechnik oder Informations-technik aufweist und Erfahrung auf dem Gebiet verteilter, mehrschichtiger Applikationen in Datenverarbeitungsnetzen besitzt. Zur Lösung der vorstehend genannten Aufgabe sollen nach Anspruch 1 gemäß Hauptantrag mindestens zwei unterschiedliche Applikationen, die zur Verarbeitung von mit bildgebenden Diagnosegeräten gewonnenen Bild-- 10 - daten dienen, verteilt in einem Datenverarbeitungsnetzwerk abgearbeitet werden. Die Applikationen unterscheiden sich hinsichtlich der zu verarbei-tenden Datenmengen. So sollen mit einer der mindestens zwei Applika-tionen 2D-Bilddaten und damit eine kleinere Datenmenge verarbeitet wer-den, und mit einer weiteren Applikation 3D-Bilddaten und damit eine grö-ßere Datenmenge. Jede dieser Applikationen ist mehrschichtig aufgebaut und die Schichten werden je nach zu verarbeitender Datenmenge auf unterschiedliche Hardwareressourcen, nämlich auf mindestens eine lokale Datenverarbeitungseinheit und mindestens eine entfernte Datenverarbei-tungseinheit, verteilt. Bei einer Applikation zur Verarbeitung der kleineren Datenmenge wird eine größere Anzahl der Schichten auf einer lokalen Datenverarbeitungseinheit als bei einer Applikation zur Verarbeitung einer größeren Datenmenge ausgeführt. Damit wird bei einer Applikation zur Ver-arbeitung der größeren Datenmenge eine größere Anzahl der Schichten auf einer entfernten Datenverarbeitungseinheit als bei einer Applikation zur Verarbeitung einer kleineren Datenmenge ausgeführt. Nach Anspruch 1 gemäß Hilfsantrag 1 ist außerdem ein zentrales Archiv zur Speicherung der Daten vorgesehen. Nach Anspruch 1 gemäß Hilfsantrag 2 wird zusätzlich der Schichtenaufbau der Applikationen präzisiert. Zur Verarbeitung der kleineren Datenmenge ist eine Rich Client Konfiguration und zur Verarbeitung der größeren Da-tenmenge ist eine Rich Thin Client Konfiguration vorgesehen. 2. Das Verfahren nach Anspruch 1 gemäß Hauptantrag beruht ausgehend von der Lehre gemäß Druckschrift D1 nicht auf einer erfinderischen Tätig-keit. Der Fachmann entnimmt Druckschrift D1 ein Verfahren zum Verteilen von Applikationen („Deployment“) in einem Datenverarbeitungsnetzwerk (vgl. Abs. [0026], [0043] i. V. m. Abs. [0013] und Abs. [0030] / Merkmal M1). - 11 - Hierbei sind verschiedene (d. h. mindestens zwei) Applikationen zur Verar-beitung von Bilddaten vorgesehen, die mit bildgebenden Diagnosegeräten gewonnen wurden (vgl. Abs. [0001], [0005], [0009], [0020] / Merkmal M2). Der Fachmann liest bei den Datenmengen, die der Applikation in ihrer jeweiligen Einsatzumgebung verfügbar gemacht werden, mit, dass sich die Applikationen hinsichtlich der jeweils zu verarbeitenden Datenmengen von-einander unterscheiden können (vgl. Abs. [0069] i. V. m. Abs. [0013] / Merkmal M3). Die Applikationen dienen der Verarbeitung und Darstellung medizinischer Daten (vgl. Abs. [0036]), wobei unter anderem auf die besonderen Anforde-rungen an die Leistungsfähigkeit des Zielrechners bei der dreidimensio-nalen Wiedergabe der Daten – also die Verwendung von 3D-Applikationen – explizit hingewiesen ist (vgl. Abs. [0013]). Der Fachmann entnimmt hie-raus, dass es sich bei 3D-Applikationen um Applikationen zur Verarbeitung einer größeren Datenmenge handelt, woraus implizit folgt, dass es sich bei 2D-Daten zur Verarbeitung durch 2D-Applikationen in der Regel um klei-nere Datenmengen handelt (Merkmal M4). Die jeweiligen Applikationen sind mehrschichtig aufgebaut (vgl. Abs. [0015] / Merkmal M5), wobei die einzelnen Schichten der Applikationen auf un-terschiedliche Hardwareressourcen, nämlich auf mindestens eine lokale Datenverarbeitungseinheit (Client, Desktop-Deployment) und mindestens eine entfernte Datenverarbeitungseinheit (Server, Web-Deployment), ver-teilt werden (vgl. Abs. [0015] sowie Abs. [0043] i. V. m. Abs. [0048]-[0051] / Merkmale M5a, M5b). Hierbei ist der Anteil der auf der lokalen Daten-verarbeitungseinheit installierten Schichten für Applikationen mit verschie-denen zu verarbeitenden Datenmengen unterschiedlich (vgl. Deployment-Strategien, Abs. [0043] i. V. m. Abs. [0048]-[0051]), ohne dass ein Verhäl-tnis von Schichten zu Applikationen mit unterschiedlicher zu verarbeitender Datenmenge explizit angegeben ist. Die Verteilung der Schichten erfolgt an-hand der Eigenschaften der Einsatzumgebung, welche die jeweils verfügbar gemachten – also jeweils zu verarbeitenden – Datenmengen und die Leis-- 12 - tungsfähigkeit und Verwendung des jeweiligen Zielrechners umfasst (vgl. Abs. [0065] und Abs. [0069]) (teilweise Merkmal M5c). Bei den in Druckschrift D1 beschriebenen Deployment-Strategien wird je-weils nur eine Applikation betrachtet und deren Schichtenaufteilung hin-sichtlich ihrer jeweils zu verarbeitenden Datenmenge wird nicht explizit mit einer anderen Applikation verglichen (vgl. Merkmal M5c). In Anspruch 1 ist in Merkmal M5c die Aufteilung der Applikationsschichten ausschließlich auf Basis der jeweils vorgegebenen zu verarbeitenden Datenmengen bean-sprucht. Dabei setzt die Anmeldung jedoch voraus, dass es bei den Appli-kationen mit kleineren zu verarbeitenden Datenmengen (Applikationen zur Verarbeitung von 2D-Daten) zu sehr viel mehr Nutzerinteraktionen kommt als bei den Applikationen mit größeren zu verarbeitenden Datenmengen (vgl. Beschreibung, S. 4, Zn. 9-21). Gemäß Druckschrift D1 ist bei der Festlegung des Deployments der Applikationsschichten die Einsatzum-gebung der betrachteten Applikation zu berücksichtigen, welche alle Aspek-te außerhalb der Applikation umfasst, die auf das Laufzeitverhalten der Applikation oder ihre Wechselwirkung mit der Hardware oder anderen Applikationen des Zielsystems Einfluss nehmen. Dazu zählen neben der zur Verarbeitung vorgesehenen, bereitgestellten Datenmenge auch die Leistungsfähigkeit der Netzwerkverbindung sowie die Verwendung und die Leistungsfähigkeit des Zielrechners (vgl. Abs. [0013] i. V. m. Abs. [0092] und Anspruch 11). Unter Kenntnis der Lehre der Druckschrift D1 würde der Fachmann folglich alle ihm bekannten Randbedingungen – wie u. a. vorlie-gend Datenmengen und Nutzerverhalten – bei der Festlegung der Auftei-lung der Schichten der jeweiligen Applikation mit berücksichtigen. Aufgrund der begrenzten Geschwindigkeit bzw. Bandbreite der Netzwerk-verbindungen liegt es daher ausgehend von Druckschrift D1 im Rahmen des fachmännischen Handelns, von den Nutzern besonders intensiv ge-nutzte Daten unabhängig von der erwarteten Größe der zu verarbeitenden Datensätze vorzugsweise lokal zu verarbeiten. Umgekehrt gilt für selten - 13 - genutzte, größere Datensätze, diese vorzugsweise zentral zu verarbeiten, da durch die in Druckschrift D1 angesprochene Verwendung in Verbindung mit einem PACS-System (vgl. Abs. [0085], letzter Spiegelstrich) aufgrund der zentralen Archivierung der Daten hierfür geeignete Datenverarbeitungs-ressourcen bereits vorgesehen sind. Hinzu kommt, dass lokale Rechner (d. h. Arbeitsplatzrechner der Nutzer) aufgrund ihrer begrenzten Rechen-leistung ein Auslagern rechenintensiver Verarbeitungsschritte – wie sie bei großen Datenmengen in 3D-Applikationen anfallen – auf Server des Netz-werks nahelegen. Da Druckschrift D1 eine Mehrzahl an Verteilungsstrategien für verschiede-ne zu berücksichtigenden Randbedingungen beschreibt, ergibt sich zwangsläufig aus der unabhängigen Betrachtung der unterschiedlichen Vorgaben für die beiden Applikationen gemäß Anspruch 1 auch eine un-terschiedliche Verteilungsstrategie für die jeweiligen Schichten dieser Appli-kationen (Merkmal M5c). Der Auffassung der Anmelderin, dass Druckschrift D1 für bildgebende Sys-teme in der Medizintechnik (bspw. PACS-Systeme) eine „Adaptive Client“ Konfiguration vorsehe und damit von der beanspruchten Lösung wegweise, kann sich der Senat nicht anschließen. Zwar beschreibt Druckschrift D1 einen „Adaptive Client“ als eine aus Leistungsgründen für PACS-Systeme vorteilhafte Konfiguration. Dies geschieht aber nur in Abgrenzung zu einem „Thin Client“ und „Web Client“ Deployment, die beide allenfalls die Imple-mentierung der Benutzerschnittstelle auf dem lokalen Rechner vorsehen (vgl. Abs. [0092] i. V. m. Abs. [0090] und [0091]). Dies ist somit als Hinweis an den Fachmann zu verstehen, zumindest Teile der Datenverarbeitung durch die jeweilige Applikation auf dem lokalen Zielrechner und nicht nur auf dem zentralen Rechner vorzusehen. Es wird zudem auch in diesem Zusammenhang wieder auf die verschiedenen Randbedingungen wie Ziel-rechnerressourcen und Netzwerkverbindungen verwiesen, die zur Bestim-mung des geeigneten Deployments zu berücksichtigen sind und aus denen - 14 - sich Vorteile eines „Adaptive Client“ ergeben könnten – aber nicht zwangs-läufig ergeben. Der Fachmann hat somit auch ausgehend von der zitierten Textstelle zu bildgebenden Systemen in der Medizintechnik Veranlassung, für die in der vorliegenden Anmeldung vorgegebenen Randbedingungen jeweils eine geeignete Verteilung der Schichten der Applikation gemäß ei-ner der in Druckschrift D1 ausführlich dargestellten Deploymentstrategien zu wählen. Der Gegenstand des Anspruchs 1 gemäß Hauptantrag beruht daher aus-gehend von Druckschrift D1 nicht auf einer erfinderischen Tätigkeit. 3. Das Verfahren nach Anspruch 1 gemäß Hilfsantrag 1 beruht für den Fach-mann ausgehend von der Lehre der Druckschrift D1 ebenfalls nicht auf ei-ner erfinderischen Tätigkeit. Anspruch 1 gemäß Hilfsantrag 1 unterscheidet sich von Anspruch 1 des Hauptantrags darin, dass das Datenverarbeitungsnetzwerk zusätzlich ein zentrales Archiv aufweist, mit welchem sowohl die zur Verarbeitung einer größeren Datenmenge vorgesehene Applikation, als auch die zur Verar-beitung einer kleineren Datenmenge vorgesehene Applikation zusammen-wirkt (vgl. Merkmal M6a). Hinsichtlich der gegenüber dem Patentanspruch 1 gemäß Hauptantrag un-veränderten Merkmale M1 bis M5c wird auf die entsprechenden vorste-henden Ausführungen unter Abschnitt II.2. dieses Beschlusses verwiesen. Das Zusammenwirken der beiden Applikationen mit dem zentralen Archiv gemäß Merkmal M6a ist als Zugreifen auf die im Archiv gespeicherten Daten durch die Applikationen zu verstehen, da sich für eine über die Speicherung und das Ermöglichen des Zugriffs hinausgehende Verarbei-- 15 - tung der Bilddaten durch das zentrale Archiv in der Anmeldung keine An-haltspunkte finden. Unter einem zentralen Archiv versteht die Anmeldung beispielsweise ein im Bereich der Verwaltung medizinischer Bilddaten ge-bräuchliches Bildarchivierungs- und Kommunikationssystem (PACS) (vgl. Beschreibung, S. 6, Zn. 26-32 i. V. m. S. 7, Zn. 4-8). Ein solches im Bereich der Verwaltung medizinischer Bilddaten gebräuch-liches Bildarchivierungs- und Kommunikationssystem (PACS) ist auch in Druckschrift D1 vorgesehen (vgl. Abs. [0046] i. V. m. Abs. [0085], letzter Spiegelstrich), so dass der Fachmann ein zentrales Archiv mitliest, in dem alle Daten nicht nur lokal, sondern auch über ein Netzwerk bereitgestellt werden können. Das Vorsehen eines zentrales Archivs, in dem sowohl die Daten von Applikationen mit einer größeren Datenmenge als auch einer kleineren Datenmenge abgespeichert sind, ergibt sich daher für den Fach-mann naheliegend aus der Lehre der Druckschrift D1 (Merkmal M6a). Die Anmelderin vertritt die Auffassung, dass aus der gemeinsamen Verwen-dung des zentralen Archivs durch die Applikationen eine Abhängigkeit zwischen diesen Applikationen folge und sich daraus eine Besonderheit in der anspruchsgemäßen asymmetrischen Aufteilung der Schichten der Applikationen ergebe. Die beanspruchte Aufteilung der Schichten ist jedoch unabhängig von einer zentralen Archivierung der durch die Applikationen verarbeiteten Bilddaten. Denn gemäß Anspruch 1 erfolgt diese Aufteilung allein anhand der jeweils zu verarbeitenden Datenmengen. Ein technischer Zusammenhang zwischen den Applikationen ist in der vorliegenden Anmel-dung weder im Zusammenwirken der Schichten der einzelnen Applika-tionen mit dem Archiv ersichtlich, noch sind Zusammenhänge genannt, durch welche das Zusammenwirken mit dem zentralen Archiv die jeweilige Aufteilung der Schichten der Applikationen beeinflussen würde. - 16 - Auch Merkmal M6a ist daher nicht geeignet, ausgehend von Druckschrift D1 die Patentfähigkeit des Anspruchs 1 zu begründen. Der Gegenstand des Anspruchs 1 gemäß Hilfsantrag 1 beruht daher ebenfalls nicht auf einer erfinderischen Tätigkeit. 4. Das Verfahren nach Anspruch 1 gemäß Hilfsantrag 2 beruht für den Fachmann ausgehend von der Lehre der Druckschrift D1 ebenfalls nicht auf einer erfinderischen Tätigkeit. Anspruch 1 gemäß Hilfsantrag 2 unterscheidet sich von Anspruch 1 des Hilfsantrags 1 in einer Festlegung der Deployment-Strategien für die beiden anspruchsgemäßen Applikationen (Merkmale M5d bis M5f) sowie in der Charakterisierung des zentralen Archivs als eines zur Speicherung und Verarbeitung der zweidimensionalen und dreidimensionalen Bilddaten (Merkmal M6b). Hinsichtlich der gegenüber dem Patentanspruch 1 gemäß Hauptantrag un-veränderten Merkmale M1 bis M5c wird auf die entsprechenden vor-stehenden Ausführungen unter Abschnitt II.2. dieses Beschlusses verwie-sen. Druckschrift D1 ist auch zu entnehmen, dass die Applikationen allgemein eine Präsentationsschicht (Schicht „View“ zur Nutzerinteraktion), eine Geschäftsprozess-Schicht (Schicht „Model“ zur Verarbeitung von und zum Zugriff auf Daten) und eine Controllerschicht (Schicht „Control“ zur Steue-rung des Ablaufs innerhalb einer Aktivität) umfassen (vgl. Abs. [0036] / Merkmal M5d). Hierbei geht Druckschrift D1 davon aus, dass es sich bei den drei Schichten um eine allgemeine Aufteilung handelt, auf die eine beliebige Zahl weiter - 17 - untergliederter Schichten von n-schichtigen Applikationen abgebildet bzw. die um weitere Schichten ergänzt werden kann (vgl. Abs. [0045]-[0047] und Fig. 2). Die einzelnen Deploymentstrategien für mehrschichtige Applikati-onen sind in Druckschrift D1 am Beispiel einer fünfschichtigen Applikation beschrieben (vgl. Abs. [0048]-[0051]). Diesem Beispiel einer fünfschichtigen Applikation entnimmt der Fachmann unter anderem das Konzept der „Rich Client“ Konfiguration entsprechend Merkmal M5e. Die vorliegende Anmeldung versteht unter einer „Rich Client“ Konfiguration ein Vorsehen sämtlicher Schichten einer Applikation auf einer einzigen, lokalen Datenverarbeitungseinheit (vgl. Beschreibung, S. 7-8, sei-tenübergreifender Abs.) und setzt dabei die Kommunikation mit einem zen-tralen Archiv über eine Netzwerkverbindung voraus (vgl. Hilfsantrag 2, An-spruch 1, Merkmal M5e i. V. m. Merkmalen M6a und M6b). Dies entspricht der aus Druckschrift D1 bekannten „Rich Client“ Konfiguration, die sich im Vorhandensein der Netzwerkverbindung von einer „Fat Client“ Konfiguration für Stand-Alone-Applikationen ohne Netzwerkanbindung unterscheidet (vgl. Abs. [0048]). Für eine Anwendung, die eine Netzwerkverbindung voraussetzt sowie viele Nutzerzugriffe erwarten lässt und damit eine vorzugsweise lokale Verarbei-tung der Daten nahelegt (vgl. Ausführungen zu Merkmal M5c), entnimmt der Fachmann Druckschrift D1 die „Rich Client“ Konfiguration als geeignete Deploymentstrategie (Merkmal M5e). Für eine Anwendung, die zur Verarbeitung größerer Datenmengen vorge-sehen ist, entnimmt der Fachmann Druckschrift D1 die „Rich Thin Client“ Konfiguration als geeignete Deploymentstrategie (vgl. Abs. [0049] f), welche die Anforderungen an den lokalen Zielrechner verringert, da viele rechen-aufwendige Schritte, also bspw. vorliegend die Verarbeitung von 3D-Daten, auf einen leistungsstarken zentralen Rechner (Server) verlagert werden (vgl. Abs. [0089]). Die Entscheidung für eine „Rich Thin Client“ Konfigu-ration anhand der vorgegebenen Randbedingungen und den jeweiligen aus - 18 - Druckschrift D1 bekannten Vorteilen liegt daher im Rahmen des fachmänni-schen Handelns und ist nicht geeignet, eine erfinderische Tätigkeit zu be-gründen (Merkmal M5f). Nach Anspruch 1 gemäß Hilfsantrag 2 dient das zentrale Archiv der Spei-cherung und Verarbeitung der jeweiligen Bilddaten (vgl. Merkmal M6b). Wie im Zusammenwirken mit dem Archiv gemäß Merkmal M6a (vgl. vor-stehende Ausführungen zu Hilfsantrag 1) ist auch die Speicherung und Verarbeitung der Bilddaten als das Speichern und Ermöglichen des Zugriffs auf diese Bilddaten zu verstehen. Für eine darüber hinausgehende Ver-arbeitung der Daten durch das zentrale Archiv finden sich in der Anmeldung keine Hinweise. Die Verwendung eines zentralen Archivs gemäß Merkmal M6a und dessen Eigenschaften zur Archivierung von Bilddaten gemäß Merkmal M6b sind ausgehend von dem Druckschrift D1 (vgl. Abs. [0046] und Abs. [0085], letzter Spiegelstrich) entnehmbaren Zusammenwirken eines Datenverarbeitungsnetzwerks mit einem PACS-System – welches der zentralen Speicherung von medizinischen Bilddaten dient – nicht geeignet, eine erfinderische Tätigkeit zu begründen (Merkmale M6a und M6b). Der Gegenstand des Anspruchs 1 gemäß Hilfsantrag 2 beruht daher eben-falls nicht auf einer erfinderischen Tätigkeit. 5. Mit dem jeweils nicht patentfähigen Anspruch 1 des Hauptantrags und der Hilfsanträge 1 und 2 sind auch die jeweils nebengeordneten Patentansprü-che 4 und 12 des Hauptantrags und des Hilfsantrags 1, die Patentansprü-che 4 und 8 des Hilfsantrags 2 sowie die auf diese Ansprüche direkt oder indirekt rückbezogenen Unteransprüche nicht schutzfähig, da auf diese An-sprüche jeweils kein eigenständiges Patentbegehren gerichtet ist und über einen Antrag nur einheitlich entschieden werden kann (vgl. BGH, Beschluss - 19 - X ZB 6/05 vom 27. Juni 2007, GRUR 2007, 862, Abs. III. 3. aa – Informa-tionsübermittlungsverfahren II). 6. Nachdem die Anspruchssätze gemäß Hauptantrag sowie gemäß Hilfsan-trag 1 und 2 jeweils nicht patentfähig sind, war die Beschwerde zurückzu-weisen. III. Rechtsbehelfsbelehrung Gegen diesen Beschluss steht der am Beschwerdeverfahren Beteiligten das Rechtsmittel der Rechtsbeschwerde zu. Da der Senat die Rechtsbeschwerde nicht zugelassen hat, ist sie nur statthaft, wenn gerügt wird, dass 1. das beschließende Gericht nicht vorschriftsmäßig besetzt war, 2. bei dem Beschluss ein Richter mitgewirkt hat, der von der Ausübung des Richteramtes kraft Gesetzes ausgeschlossen oder wegen Besorgnis der Befangenheit mit Erfolg abgelehnt war, 3. einem Beteiligten das rechtliche Gehör versagt war, 4. ein Beteiligter im Verfahren nicht nach Vorschrift des Gesetzes vertreten war, sofern er nicht der Führung des Verfahrens ausdrücklich oder stillschweigend zugestimmt hat, 5. der Beschluss aufgrund einer mündlichen Verhandlung ergangen ist, bei der die Vorschriften über die Öffentlichkeit des Verfahrens verletzt worden sind, oder 6. der Beschluss nicht mit Gründen versehen ist. - 20 - #Die Rechtsbeschwerde ist innerhalb eines Monats nach Zustellung des Beschlus-ses beim Bundesgerichtshof, Herrenstr. 45 a, 76133 Karlsruhe, durch einen beim Bundesgerichtshof zugelassenen Rechtsanwalt als Bevollmächtigten schriftlich einzulegen. Wickborn Kruppa Dr. Otten-Dünnweber Altvater Hu

Full & Egal Universal Law Academy