Urteil des BPatG vom 27.03.2015

Stand der Technik, Aufteilung, Patentanspruch, Zusammenwirken

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

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

DE 10 2006 051 189 A1

und

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

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

28. August 2008, Seiten 2, 3 und 3a eingegangen am 26. August 2009,

- Figuren 1 bis 5, eingegangen am 28. August 2008.

Patentanspruch 1

mäß Hauptantrag lautet:

„Verfahren zum Verteilen von Applikationen (A1, A2) in einem Datenver-

arbeitungsnetzwerk (1),

mit mindestens zwei Applikationen (A1, A2) zur Verarbeitung von Bilddaten,

die mit bildgebenden Diagnosegeräten (3,4) gewonnen wurden,

- 4 -

welche Applikationen (A1, A2) sich hinsichtlich der zu verarbeitenden Da-

tenmengen voneinander unterscheiden,

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,

wobei jede Applikation (A1, A2) mehrschichtig aufgebaut ist und

M5a

unterschiedliche Hardwareressourcen (5, 6, 7),

M5b

mindestens eine entfernte Datenverarbeitungseinheit (7), verteilt werden,

M5c

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

„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

„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

mäß Hauptantrag durch Anfügen des folgenden Merkmals M6a nach Merkmal

M5c:

„[…],

M6a

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

mäß Hauptantrag ebenfalls durch Anfügen des vorstehend aufgeführten Merkmals

M6a am Ende des Anspruchs.

- 6 -

Anspruch 12

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

mäß Hauptantrag durch Anfügen der folgenden Merkmale M5d bis M6b nach

Merkmal M5c:

„[…],

M5d

Schicht und eine Controllerschicht umfasst,

M5e

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

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

mensionalen Bilddaten dient.

“

Patentanspruch 4

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

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)

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.

Anspruch 1

von der Lehre gemäß Druckschrift D1 nicht auf einer erfinderischen Tätig-

keit.

Druckschrift D1

Applikationen

(„Deployment“) in einem Datenverarbeitungsnetzwerk (vgl.

Merkmal M1

- 11 -

Hierbei sind verschiedene (d. h. mindestens zwei) Applikationen zur Verar-

beitung von Bilddaten vorgesehen, die mit bildgebenden Diagnosegeräten

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-

Merkmal M4

Die jeweiligen Applikationen sind mehrschichtig aufgebaut (vgl. Abs. [0015]

Merkmal M5

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

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.

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-

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.

Anspruch 1

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-

Merkmale M1 bis M5c

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-

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.

Anspruch 1

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-

Merkmale M1 bis M5c

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 ei

ne 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

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-

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,

Merkmale M6a und M6b

Der Gegenstand des Anspruchs 1 gemäß Hilfsantrag 2 beruht daher eben-

falls nicht auf einer erfinderischen Tätigkeit.

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

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

das beschließende Gericht nicht vorschriftsmäßig besetzt war,

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,

einem Beteiligten das rechtliche Gehör versagt war,

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,

der Beschluss aufgrund einer mündlichen Verhandlung ergangen ist, bei

der die Vorschriften über die Öffentlichkeit des Verfahrens verletzt worden

sind, oder

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