18 W (pat) 88/14

BUNDESPATENTGERICHT W (pat) 88/14 Verkündet am 27. März 2015

…

BESCHLUSS In der Beschwerdesache betreffend die Patentanmeldung 10 2008 044 843.5 - 53

…

BPatG 154 05.11 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. OttenDünnweber und den Richter Dipl.-Ing. Altvater beschlossen:

Die Beschwerde der Anmelderin wird zurückgewiesen.

Gründe 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 Patentund 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 < http://www.daimi.au.dk/fileadmin/images/common/secretaries/ HansenSS.pdf > (recherchiert von der Prüfungsstelle am 18. Juni 2009)

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 gemäß Hauptantrag lautet:

M1 „Verfahren zum Verteilen von Applikationen (A1, A2) in einem Datenverarbeitungsnetzwerk (1),

M2 mit mindestens zwei Applikationen (A1, A2) zur Verarbeitung von Bilddaten, die mit bildgebenden Diagnosegeräten (3,4) gewonnen wurden,

M3 welche Applikationen (A1, A2) sich hinsichtlich der zu verarbeitenden Datenmengen voneinander unterscheiden,

M4 wobei es sich bei der zur Verarbeitung der kleineren Datenmenge vorgesehen Applikation (A1) um eine 2D-Applikation und bei der zur Verarbeitung der größeren Datenmenge vorgesehen Applikation (A2) um eine 3D-Applikation 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 mehrschichtige 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 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 medizintechnischer Bilddaten.“

Wegen der geltenden abhängigen Ansprüche 2, 3 und 5 bis 11 gemäß Hauptantrag wird auf den Akteninhalt verwiesen.

Patentanspruch 1 gemäß Hilfsantrag 1 unterscheidet sich von Anspruch 1 gemäß Hauptantrag durch Anfügen des folgenden Merkmals M6a nach Merkmal M5c:

„[…], M6a wobei das Datenverarbeitungsnetzwerk (1) ein zentrales Archiv (2) aufweist, mit welchem sowohl die zur Verarbeitung einer größeren Datenmenge 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 gemäß Hauptantrag ebenfalls durch Anfügen des vorstehend aufgeführten Merkmals M6a am Ende des Anspruchs.

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äß Hilfsantrag 1 wird auf den Akteninhalt verwiesen.

Patentanspruch 1 gemäß Hilfsantrag 2 unterscheidet sich von Anspruch 1 gemäß 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 Applikation eine Rich Client Konfiguration bildet, und M5f wobei die zur Verarbeitung der größeren Datenmenge vorgesehene Applikation eine Rich Thin Client Konfiguration bildet,

M6a wobei das Datenverarbeitungsnetzwerk (1) ein zentrales Archiv (2) aufweist, mit welchem sowohl die zur Verarbeitung einer größeren Datenmenge vorgesehene Applikation (A2) als auch die zur Verarbeitung einer kleineren Datenmenge vorgesehene Applikation (A1) zusammenwirkt,

M6b das der Speicherung und Verarbeitung der zweidimensionalen und dreidimensionalen Bilddaten dient.“

Patentanspruch 4 gemäß Hilfsantrag 2 unterscheidet sich von Anspruch 1 gemäß Hauptantrag durch Anfügen der folgenden Merkmale am Ende des Anspruchs:

„[…],

wobei jede Applikation (A1, A2) eine Präsentationsschicht (V), eine Geschäftsprozess-Schicht (M) und eine Controllerschicht (C) umfasst, wobei die zur Verarbeitung der kleineren Datenmenge vorgesehene Applikation (A1) eine Rich Client Konfiguration bildet, und wobei die zur Verarbeitung der größeren Datenmenge vorgesehene Applikation (A2) eine Rich Thin Client Konfiguration bildet, wobei das Datenverarbeitungsnetzwerk (1) ein zentrales Archiv (2) aufweist, mit welchem sowohl 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äß Hauptantrag.

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.

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 einem Datenverarbeitungsnetzwerk einer medizinischen Einrichtung (vgl. geltende 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 Darstellung von Informationen und für Benutzerinteraktionen, eine Geschäftsprozess-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 Szenarien zum Tragen kommen, nämlich Thin-Client, Rich-Thin-Client, RichClient, Adaptive-Client, Fat-Client und Web-Service. Im Fall eines RichThin-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 Vorgänge abgearbeitet werden könnten. Vorzugsweise seien die verschiedenen Schichten unabhängig von der Deployment-Strategie programmiert. Die flexible, je nach Bedarf und Einsatzumgebung herunterladbare Applikations-Architektur erkenne, in welchem Einsatz sich eine Applikation gerade befinde. Häufig verwendete Bezeichnungen für Schichten einer solchen Systemarchitektur seien „Model“, „View“ und „Controller“, die zusammenfassend auch als MVC Softwaremuster bezeichnet würden. In diesem Zusammenhang verweist die Anmeldung beispielgebend auf die als DE 196 25 841 A1 und DE 10 2005 010 405 A1 veröffentlichten Patentanmeldungen. 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 Datenverarbeitungsnetzwerken zu beherrschen sei. (vgl. geltende Beschreibung, S. 1, Z. 10 bis S. 2, Z. 30).

Die Anmeldung nennt als Aufgabe, die Leistungsfähigkeit von Datenverarbeitungssystemen, welche mit mehrschichtigen Applikationen arbeiten, insbesondere 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 Applikationen auf lokale und entfernte Datenverarbeitungseinheiten eines Datenverarbeitungssystems 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 Informationstechnik 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- daten dienen, verteilt in einem Datenverarbeitungsnetzwerk abgearbeitet werden. Die Applikationen unterscheiden sich hinsichtlich der zu verarbeitenden Datenmengen. So sollen mit einer der mindestens zwei Applikationen 2D-Bilddaten und damit eine kleinere Datenmenge verarbeitet werden, 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 Datenverarbeitungseinheit, 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 Verarbeitung 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 Datenmenge 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ätigkeit.

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

Hierbei sind verschiedene (d. h. mindestens zwei) Applikationen zur Verarbeitung 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 voneinander 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 Anforderungen an die Leistungsfähigkeit des Zielrechners bei der dreidimensionalen Wiedergabe der Daten – also die Verwendung von 3D-Applikationen – explizit hingewiesen ist (vgl. Abs. [0013]). Der Fachmann entnimmt hieraus, 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 kleinere Datenmengen handelt (Merkmal M4). Die jeweiligen Applikationen sind mehrschichtig aufgebaut (vgl. Abs. [0015] / Merkmal M5), wobei die einzelnen Schichten der Applikationen auf unterschiedliche Hardwareressourcen, nämlich auf mindestens eine lokale Datenverarbeitungseinheit (Client, Desktop-Deployment) und mindestens eine entfernte Datenverarbeitungseinheit (Server, Web-Deployment), verteilt werden (vgl. Abs. [0015] sowie Abs. [0043] i. V. m. Abs. [0048]-[0051] / Merkmale M5a, M5b). Hierbei ist der Anteil der auf der lokalen Datenverarbeitungseinheit installierten Schichten für Applikationen mit verschiedenen zu verarbeitenden Datenmengen unterschiedlich (vgl. DeploymentStrategien, Abs. [0043] i. V. m. Abs. [0048]-[0051]), ohne dass ein Verhältnis von Schichten zu Applikationen mit unterschiedlicher zu verarbeitender Datenmenge explizit angegeben ist. Die Verteilung der Schichten erfolgt anhand der Eigenschaften der Einsatzumgebung, welche die jeweils verfügbar gemachten – also jeweils zu verarbeitenden – Datenmengen und die Leis- 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 jeweils nur eine Applikation betrachtet und deren Schichtenaufteilung hinsichtlich 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 beansprucht. Dabei setzt die Anmeldung jedoch voraus, dass es bei den Applikationen 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 Einsatzumgebung der betrachteten Applikation zu berücksichtigen, welche alle Aspekte 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. vorliegend Datenmengen und Nutzerverhalten – bei der Festlegung der Aufteilung der Schichten der jeweiligen Applikation mit berücksichtigen. Aufgrund der begrenzten Geschwindigkeit bzw. Bandbreite der Netzwerkverbindungen liegt es daher ausgehend von Druckschrift D1 im Rahmen des fachmännischen Handelns, von den Nutzern besonders intensiv genutzte Daten unabhängig von der erwarteten Größe der zu verarbeitenden Datensätze vorzugsweise lokal zu verarbeiten. Umgekehrt gilt für selten 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 Datenverarbeitungsressourcen bereits vorgesehen sind. Hinzu kommt, dass lokale Rechner (d. h. Arbeitsplatzrechner der Nutzer) aufgrund ihrer begrenzten Rechenleistung ein Auslagern rechenintensiver Verarbeitungsschritte – wie sie bei großen Datenmengen in 3D-Applikationen anfallen – auf Server des Netzwerks nahelegen. Da Druckschrift D1 eine Mehrzahl an Verteilungsstrategien für verschiedene 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 unterschiedliche Verteilungsstrategie für die jeweiligen Schichten dieser Applikationen (Merkmal M5c).

Der Auffassung der Anmelderin, dass Druckschrift D1 für bildgebende Systeme 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 Implementierung 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 Zielrechnerressourcen und Netzwerkverbindungen verwiesen, die zur Bestimmung des geeigneten Deployments zu berücksichtigen sind und aus denen sich Vorteile eines „Adaptive Client“ ergeben könnten – aber nicht zwangslä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äß einer der in Druckschrift D1 ausführlich dargestellten Deploymentstrategien zu wählen.

Der Gegenstand des Anspruchs 1 gemäß Hauptantrag beruht daher ausgehend von Druckschrift D1 nicht auf einer erfinderischen Tätigkeit.

3. Das Verfahren nach Anspruch 1 gemäß Hilfsantrag 1 beruht für den Fachmann ausgehend von der Lehre der Druckschrift D1 ebenfalls nicht auf einer 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 Verarbeitung einer kleineren Datenmenge vorgesehene Applikation zusammenwirkt (vgl. Merkmal M6a).

Hinsichtlich der gegenüber dem Patentanspruch 1 gemäß Hauptantrag unveränderten Merkmale M1 bis M5c wird auf die entsprechenden vorstehenden 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- tung der Bilddaten durch das zentrale Archiv in der Anmeldung keine Anhaltspunkte finden. Unter einem zentralen Archiv versteht die Anmeldung beispielsweise ein im Bereich der Verwaltung medizinischer Bilddaten gebrä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äuchliches 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 Fachmann naheliegend aus der Lehre der Druckschrift D1 (Merkmal M6a).

Die Anmelderin vertritt die Auffassung, dass aus der gemeinsamen Verwendung 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 Anmeldung weder im Zusammenwirken der Schichten der einzelnen Applikationen 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.

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 unveränderten Merkmale M1 bis M5c wird auf die entsprechenden vorstehenden Ausführungen unter Abschnitt II.2. dieses Beschlusses verwiesen.

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 Steuerung 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 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 Applikationen 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, seitenübergreifender Abs.) und setzt dabei die Kommunikation mit einem zentralen Archiv über eine Netzwerkverbindung voraus (vgl. Hilfsantrag 2, Anspruch 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 Verarbeitung 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 vorgesehen 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 rechenaufwendige 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“ Konfiguration anhand der vorgegebenen Randbedingungen und den jeweiligen aus Druckschrift D1 bekannten Vorteilen liegt daher im Rahmen des fachmännischen Handelns und ist nicht geeignet, eine erfinderische Tätigkeit zu begründen (Merkmal M5f).

Nach Anspruch 1 gemäß Hilfsantrag 2 dient das zentrale Archiv der Speicherung und Verarbeitung der jeweiligen Bilddaten (vgl. Merkmal M6b). Wie im Zusammenwirken mit dem Archiv gemäß Merkmal M6a (vgl. vorstehende 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 Verarbeitung 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 ebenfalls 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 Ansprüche jeweils kein eigenständiges Patentbegehren gerichtet ist und über einen Antrag nur einheitlich entschieden werden kann (vgl. BGH, Beschluss X ZB 6/05 vom 27. Juni 2007, GRUR 2007, 862, Abs. III. 3. aa – Informationsübermittlungsverfahren II).

6. Nachdem die Anspruchssätze gemäß Hauptantrag sowie gemäß Hilfsantrag 1 und 2 jeweils nicht patentfähig sind, war die Beschwerde zurückzuweisen.

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.

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