7 W (pat) 43/11

BUNDESPATENTGERICHT W (pat) 43/11 Verkündet am 15. Mai 2013

…

BESCHLUSS In der Beschwerdesache betreffend die Patentanmeldung 10 2006 033 863.4-53 …

hat der 7. Senat (Technischer Beschwerdesenat) des Bundespatentgerichts auf die mündliche Verhandlung vom 15. Mai 2013 durch den Richter Dipl.-Phys. Dipl.Wirt.-Phys. Maile als Vorsitzenden und die Richter Schwarz, Dipl.-Phys. Dr. rer. nat. Schwengelbeck und Dipl.-Ing. Altvater BPatG 154 05.11 beschlossen:

-2Die Beschwerde wird zurückgewiesen.

Gründe I.

Die Prüfungsstelle für Klasse G 06 F des Deutschen Patent- und Markenamts hat mit Beschluss vom 21. Februar 2008 die Patentanmeldung 10 2006 033 863.4-53 mit der Bezeichnung

„Verschaltungsschnittstelle für flexibles Online/Offline-Deployment einer n-schichtigen Softwareapplikation“

zurückgewiesen.

Die Prüfungsstelle hat die Zurückweisung damit begründet, dass die Gegenstände der jeweiligen Ansprüche 1 des damals geltenden Hauptantrags und der Hilfsanträge 1 bis 3 im Hinblick auf die im Prüfungsverfahren ermittelten Druckschriften nicht auf einer erfinderischen Tätigkeit beruhen würden.

Gegen diesen Beschluss richtet sich die Beschwerde der Anmelderin.

Der Senat hat mit Verfügung vom 7. Mai 2013 auf die Druckschrift D1 US 5 457 797 A als weiteren, möglicherweise relevanten Stand der Technik hingewiesen.

In der mündlichen Verhandlung verteidigt die Anmelderin ihre Patentanmeldung mit jeweils geänderten Ansprüchen 1 bis 15 gemäß Hauptantrag und Hilfsantrag 1, und jeweils geänderten Ansprüchen 1 bis 11 gemäß den Hilfsanträgen 1 bis 4. Sie ist der Ansicht, dass die jeweiligen Anspruchssätze nach Hauptantrag und Hilfsantrag zulässig und patentfähig seien.

Der vom Senat mit einer Gliederung versehene Patentanspruch 1 gemäß Hauptantrag lautet:

(M1) „Verfahren zur Erzeugung einer zumindest zweischichtigen Softwareapplikation (10) mit einer Verarbeitungsschicht (13) und einer Prozessschicht (14),

(M2) wobei jede Schicht (13, 14) in einer generischen Laufzeitumgebung gekapselt ist und

(M3) wobei die gekapselten Schichten (13, 14) über eine Anwendungsschnittstelle (17c) miteinander kommunizieren,

dadurch gekennzeichnet, dass

(M4) die Anwendungsschnittstelle (17c) eine Verschaltungsschnittstelle umfasst, die in Abhängigkeit der zugrunde liegenden Plattformen der einzelnen gekapselten Schichten (13, 14) die für die Kommunikation über die Anwendungsschnittstelle (17c) zwischen den gekapselten Schichten (13, 14) notwendigen Kommunikationsprofile bereitstellt,

(M5) wobei die Verschaltungsschnittstelle durch Konfiguration für unterschiedliche Deployments der Schichten (13, 14) angepasst werden kann, ohne dass hierfür eine Quellcodeanpassung der Verschaltungsschnittstelle erforderlich ist.“

Patentanspruch 1 nach Hilfsantrag 1 weist die Merkmale M1 bis M4 des Anspruchs 1 gemäß Hauptantrag auf, gefolgt von folgendem geänderten Merkmal M5* (Merkmalsgliederung seitens des Senats hinzugefügt):

(M5*) „wobei die Verschaltungsschnittstelle durch Konfiguration in Form einer Kompilierung oder einer dynamischen Verlinkung mit Dateien einer Datenbank für unterschiedliche Deployments der Schichten (13, 14) angepasst werden kann.“

Der vom Senat mit einer Merkmalsgliederung versehene Patentanspruch 1 nach Hilfsantrag 2 lautet (Änderungen gegenüber Anspruch 1 gemäß Hauptantrag gekennzeichnet):

(M1*) „Verfahren zur Erzeugung einer zumindest zweischichtigen Softwareapplikation (10), mit einer Verarbeitungsschicht (13) und einer Prozessschicht (14) die fünf Schichten umfasst, nämlich beginnend bei der untersten Schicht:

(M1.1) - eine Serviceschicht (11) zur Bereitstellung von lokalen und/oder externen Diensten (20a-d) für ein Framework,

(M1.2) - eine Datenzugriffsschicht (12) für den Zugriff auf Daten und zur Bereitstellung von lokalen und/oder externen Daten- und Kommunikationsdiensten (21a-d),

(M1.3) - eine Verarbeitungsschicht (13) zur Bereitstellung von Verarbeitungsdiensten und/oder Verarbeitungskomponenten (22a-d),

(M1.4) - eine Prozessschicht (14) zur Bereitstellung einer Business-Logik und/oder eines Service-Busses,

(M1.5) - eine Präsentationsschicht (15) zur Darstellung von Daten und/oder Komponenten (23a-c),

(M2) wobei jede Schicht (11-15) in einer generischen Laufzeitumgebung gekapselt ist und

(M3) wobei die gekapselten Schichten (11-15) über Anwendungsschnittstellen (17a-d) miteinander kommunizieren,

dadurch gekennzeichnet, dass

(M4*) wobei jede Anwendungsschnittstelle (17a-d) eine Verschaltungsschnittstelle umfasst, die in Abhängigkeit der zugrunde liegenden Plattformen der einzelnen gekapselten Schichten (11-15) die für die Kommunikation über die Anwendungsschnittstelle (17a-d) zwischen den gekapselten Schichten (11-15) notwendigen Kommunikationsprofile bereitstellt, und

(M5*) wobei die Verschaltungsschnittstelle durch Konfiguration, für unterschiedliche Deployments der Schichten (13,14) angepasst werden kann, ohne dass hierfür eine Quellcodeanpassung der Verschaltungsschnittstelle erforderlich ist, für folgende Deployments der Schichten (11-15) angepasst werden kann:

(M5.1) - Ein Fat-Client-Deployment (25a), bei dem alle Schichten (1115) auf einem einzigen Rechner (16b) implementiert sind;

(M5.2) - ein Rich-Client Deployment (25b), bei dem die Serviceschicht (11) auf einem oder mehreren Servern (16a) implementiert ist, und bei dem die Datenzugriffsschicht (12), die Verarbeitungsschicht (13), die Prozessschicht (14) und die Präsentationsschicht (15) auf einem Client (16b) implementiert sind; (M5.3) - ein Smart-Client-Deployment (25c), bei dem die Serviceschicht (11) auf dem Server (16a) implementiert ist, bei dem die Prozessschicht (14) und die Präsentationsschicht (15) auf dem Client (16b) implementiert sind, und bei dem Bestandteile der Verarbeitungsschicht (13) und der Datenzugriffsschicht (12) auf dem Client (16b), und andere Bestandteile Verarbeitungsschicht (13) und der Datenzugriffsschicht (12) auf einem oder mehreren Servern (16a) verteilt sind; (M5.4) - ein Rich-Thin-Client-Deployment (25d), bei dem die Serviceschicht (11), die Datenzugriffsschicht (12) und Verarbeitungsschicht (13) auf dem Server (16a) implementiert sind, und bei dem die Prozessschicht (14) und die Präsentationsschicht (15) auf dem Client (16b) implementiert sind; sowie (M5.5) - ein Thin-Client-Deployment (25e), bei dem die Serviceschicht (11), die Datenzugriffsschicht (12), die Verarbeitungsschicht (13) und die Prozessschicht (14) auf einem oder mehreren Servern (16a) implementiert sind, und bei dem die Präsentationsschicht (15) auf dem Client (16b) implementiert ist.“

Patentanspruch 1 nach Hilfsantrag 3 weist die Merkmale des Anspruchs 1 gemäß Hilfsantrag 2 auf, unter Hinzufügen des Merkmals M6 (Merkmalsgliederung seitens des Senats hinzugefügt):

(M6) „wobei die in den gekapselten Schichten (11-15) implementierten Dienste und/oder Komponenten und/oder Daten (20a-d, 21a-d, 22a-d, 23a-c) bezüglich standardisierter Anwendungsschnittstellen (17a-d) konzipiert werden.“

Patentanspruch 1 nach Hilfsantrag 4 weist die Merkmale M1*, M1.1 bis M1.5, M2, M4*, M5* und M5.1 bis M5.5 des Anspruchs 1 gemäß Hilfsantrag 2 auf, unter Hinzufügen des geänderten Merkmals M3* (Merkmalsgliederung seitens des Senats hinzugefügt, Änderungen gegenüber Hilfsantrag 2 unterstrichen):

(M3*) „wobei die gekapselten Schichten (11-15) über Anwendungsschnittstellen (17a-d) der jeweiligen generischen Laufzeitumgebung miteinander kommunizieren,“

Wegen des Wortlauts der jeweils ein System, ein Datenverarbeitungsprogramm und einen Datenträger betreffenden nebengeordneten Ansprüche 11, 14 und 15 nach Haupt- bzw. Hilfsantrag 1, der jeweils nebengeordneten Ansprüche 8, 10 und 11 nach Hilfsantrag 2, Hilfsantrag 3 bzw. Hilfsantrag 4, sowie der weiteren abhängigen Ansprüche nach Hauptantrag und den Hilfsanträgen 1 bis 4 wird auf den Akteninhalt verwiesen.

Die Anmelderin stellt den Antrag,

den Beschluss der Prüfungsstelle für Klasse G 06 F des Deutschen Patent- und Markenamtes vom 21. Februar 2008 aufzuheben und auf die Anmeldung ein Patent mit den folgenden Unterlagen zu erteilen:

- Patentansprüche 1 bis 15 laut dem in der mündlichen Verhandlung vom 15. Mai 2013 überreichten neuen Hauptantrag hilfsweise:

(1. Hilfsantrag) Patentansprüche 1 bis 15 laut dem in der mündlichen Verhandlung vom 15. Mai 2013 überreichten geänderten Hilfsantrag 1

(2. Hilfsantrag) Patentansprüche 1 bis 11 laut dem in der mündlichen Verhandlung vom 15. Mai 2013 überreichten geänderten Hilfsantrag 2

(3. Hilfsantrag) Patentansprüche 1 bis 11 laut dem in der mündlichen Verhandlung vom 15. Mai 2013 überreichten geänderten Hilfsantrag 3

(4. Hilfsantrag) Patentansprüche 1 bis 11 laut dem in der mündlichen Verhandlung vom 15. Mai 2013 überreichten neuen Hilfsantrag 4

- ggfs. anzupassende Beschreibung und Zeichnungen (Fig. 1 bis 4) laut Offenlegungsschrift Wegen der weiteren Einzelheiten wird auf den Akteninhalt verwiesen.

II.

Die zulässige Beschwerde hat nach dem Ergebnis der mündlichen Verhandlung keinen Erfolg. Eine Patenterteilung scheidet auch auf der Grundlage der neuen Anträge aus, da die jeweiligen Gegenstände der Ansprüche 1 nach Hauptantrag und Hilfsantrag 1 über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinausgehen (§ 38 PatG) und sich die Gegenstände der jeweiligen Ansprüche 1 nach den Hilfsanträgen 2 bis 4 als nicht patentfähig erweisen (§ 1 bis 5 PatG).

1. Die Patentanmeldung betrifft ein Verfahren zur Erzeugung einer nschichtigen, d.h. mindestens zweischichtigen Softwareapplikation mit einer Verarbeitungsschicht und einer Prozessschicht, wobei jede Schicht gekapselt und damit plattformunabhängig lauffähig ist und die gekapselten Schichten über eine Anwendungsschnittstelle miteinander kommunizieren. Die Erfindung betrifft ebenfalls ein System zur Erzeugung einer Applikation mit einer flexiblen Verschaltungsschnittstelle innerhalb einer Anwendungsschnittstelle zwischen gekapselten Schichten (vgl. OS, Abs. [0001]).

Hiervon ausgehend liegt der vorliegenden Patentanmeldung die Aufgabe zugrunde, eine zentralisierte Entwicklung von n-schichtigen Applikationen unabhängig von der zugrunde liegenden Softwarearchitektur unter Berücksichtigung der verwendeten Plattformen und Ablauforte in einem Computernetzwerk zu ermöglichen (vgl. OS, Abs. [0012]).

Diese Aufgabe soll durch die jeweiligen Merkmale der nebengeordneten Ansprüche 1, 11, 14 und 15 nach Haupt- und Hilfsantrag 1, sowie die jeweiligen Merkmale der nebengeordneten Ansprüche 1, 8, 10 und 11 nach den Hilfsanträgen 2 bis 4 gelöst werden.

2. Die Gegenstände der Ansprüche 1 nach Haupt- und nach Hilfsantrag 1 gehen über den Inhalt der Anmeldung in der ursprünglich eingereichten Fassung hinaus.

a) Zum Hauptantrag Das Verfahren nach Anspruch 1 gemäß Hauptantrag ist unzulässig erweitert.

Denn mit Anspruch 1 gemäß Hauptantrag wird ein „Verfahren zur Erzeugung einer zumindest zweischichtigen Softwareapplikation“ beansprucht, bei welchem u.a. „die Verschaltungsschnittstelle durch Konfiguration für unterschiedliche Deployments der Schichten angepasst werden kann, ohne dass hierfür eine Quellcodeanpassung der Verschaltungsschnittstelle erforderlich ist“ (Merkmal M5). Eine Konfiguration ohne Quellcodeanpassung ist in der ursprünglichen Beschreibung jedoch ausschließlich im Zusammenhang mit dem Ausführungsbeispiel einer fünfschichtigen Softwareapplikation offenbart (Fig. 1 in Verbindung mit der zugehörigen Beschreibung, OS, Abs. [0037], insbesondere erster und drittletzter Satz). Somit stellt das auf eine beliebige mehrschichtige Applikation gerichtete Verfahren nach Anspruch 1 eine Verallgemeinerung des ursprünglich nur für eine fünfschichtige Softwareapplikation beschriebenen Merkmals dar und geht damit über den ursprünglichen Inhalt der Anmeldung hinaus.

Der von der Anmelderin mit Verweis auf Abs. [0015] der Offenlegungsschrift vertretenen Auffassung, dass sich eine Anpassung der Verschaltungsschnittstelle ohne Quellcodeanpassung unabhängig von der Zahl der Schichten der Softwareapplikation bereits aus der Beschreibung einer zentralisierten Softwareentwicklung ergebe, kann nicht gefolgt werden. Denn die von der Anmelderin in der mündlichen Verhandlung angeführte Textstelle offenbart lediglich, dass ein zentraler Teil des Quellcodes („Quellcodestämme“) – mithin nicht der gesamte Quellcode – für verschiedene Deployments unverändert verwendet werden kann, wobei der Applikationsentwickler nur einmal seine grundlegende Schichtenarchitektur seiner Applikation erarbeiten muss. Eine – wie jetzt beansprucht – Anpassung der Verschaltungsschnittstelle ohne Quellcodeanpassung der Verschaltungsschnittstelle (d.h. eine vollständige Übernahme der Quellcodes) im Zusammenhang mit einer zumindest zweischichtigen Softwareapplikation kann auch der von der Anmelderin angegebenen Textstelle nicht entnommen werden.

Insofern ist der Gegenstand des Anspruchs 1 nach Hauptantrag unzulässig erweitert und daher nicht schutzfähig.

b) Zum Hilfsantrag 1 Auch das Verfahren nach Anspruch 1 gemäß Hilfsantrag 1 ist unzulässig erweitert.

So wird jetzt ein „Verfahren zur Erzeugung einer zumindest zweischichtigen Softwareapplikation“ – und somit einer beliebig mehrschichtigen Softwareapplikation – beansprucht, bei der „die Verschaltungsschnittstelle durch Konfiguration in Form einer Kompilierung oder einer dynamischen Verlinkung mit Dateien einer Datenbank für unterschiedliche Deployments der Schichten (13,14) angepasst werden kann“ (Merkmal M5*). Hierbei ist zumindest die beanspruchte alternativ Ausführungsform einer Konfiguration in Form einer Kompilierung in der ursprünglichen Beschreibung ebenfalls nur für eine fünfschichtige Softwareapplikation offenbart (vgl. Ausführungsform nach Fig. 1 i.V.m. OS, Abs. [0037], erster und letzter Satz).

Die von der Anmelderin in der mündlichen Verhandlung im Zusammenhang mit der Ursprungsoffenbarung genannte Textstelle, wonach die jetzt beanspruchte Anpassung der Verschaltungsschnittstelle aus der in den ursprünglichen Unterlagen genannten Möglichkeit, „mittels XML- oder DLL-Konfigurationsdateien für die Konfigurierung der flexiblen Verschaltungsschnittstelle […], die Applikation plattformunabhängig und unabhängig vom Deployment zu kompilieren“ (vgl. OS, Abs. [0021]) offenbart sei, bezieht sich dabei lediglich auf die weitere beanspruchte Alternative der Anpassung durch eine dynamische Verlinkung, die ohne weitere Kompilie- rung lauffähig sein soll (ebd., letzter Satz), und kann somit nicht die Zulässigkeit der vorstehend genannten Alternative begründen.

Damit ist der Gegenstand des Anspruchs 1 nach Hilfsantrag 1 ebenfalls unzulässig erweitert, so dass der Anspruch 1 nach Hilfsantrag 1 ebenfalls nicht patentierbar ist.

3. Die Gegenstände der jeweiligen Ansprüche 1 nach den Hilfsanträgen 2 bis 4 beruhen unter Berücksichtigung des Standes der Technik gemäß Druckschrift D1 nicht auf einer erfinderischen Tätigkeit des zuständigen Fachmanns. Als Fachmann ist dabei vorliegend ein Diplom-Informatiker mit Fachhochschulabschluss und mehrjähriger Erfahrung auf dem Gebiet der Software-Architekturen und Entwurfsumgebungen für verteilte Software-Applikationen anzusehen.

a) Zum Hilfsantrag 2 Anspruch 1 nach Hilfsantrag 2 beruht, ausgehend von der Druckschrift D1 verbunden mit fachmännischem Handeln, nicht auf einer erfinderischen Tätigkeit des zuständigen Fachmanns.

So ist aus Druckschrift D1 ein Verfahren zur Erzeugung einer Softwareapplikation („application program“) bekannt, die eine Mehrzahl an Schichten umfasst (vgl. Fig. 3 bis 5, „Data Management“, „Application Logic“ und „Presentation Services“; vgl. Fig. 3 bis 5, i.V.m. zugehörigen Beschreibung, Sp. 4, Z. 5 ff.). Aus den Figuren 3 bis 5 ist zudem ersichtlich, dass, ausgehend vom im Stand der Technik nach Figur 2 bekannten Schichtenmodell, die jeweiligen Schichten entsprechend durch „Partitionieren“ angepasst werden können. Beispielsweise lehrt die Fig. 3 das „Partitionieren“ der Präsentationsschicht in zwei abgeschlossene eigenständige Schichten auf dem Server und dem Client. Gleiches lehrt die Fig. 4 im Zusammenhang mit der Datenmanagement-Schicht bzw. die Fig. 5 mit der Applikationsschicht.

Weiter offenbart die D1 in Fig. 9, dass beim Vorgang des „Partitionierens“ unabhängige, gekapselten Schichten in weitere unabhängig gekapselte Schichten unterteilt werden (vgl. bspw. „Presentation Services“ in Fig. 3, und „Distributed Presentation“, Sp. 4, Zn. 5 ff) und jeweils auf mehrere Server und Clients zu verteilen (vgl. bspw. „Data Management“ in Fig. 4 und „Distributed Data Management“, Sp. 4, Zn. 18 ff).

Weiter ist in der D1 ausgeführt, dass der Systemnutzer in der Festlegung der Aufteilung der Schichten frei ist, da die Zuordnung auf der Ebene einzelner Objekte durchgeführt werden kann (vgl. Sp. 5, Zn. 19-22, und Sp. 9, Zn. 22 ff). Somit entnimmt der Fachmann dem Offenbarungsgehalt der Druckschrift D1 eine – abhängig vom jeweiligen Anwendungsfall – abstrakte Zuordnung von beliebigen Teilen der Softwareapplikation auf Clients und Server.

Mithin fällt die jetzt im Anspruchswortlaut explizit geforderte Unterteilung der Softwareapplikation in 5 Schichten unter den allgemeinen Offenbarungsgehalt der Druckschrift D1 (Merkmal M1).

Ausgehend von dieser für den Fachmann beliebigen Unterteilung der Softwareapplikation beispielsweise in 5 Schichten, liegt es im Belieben des Fachmanns, die in Druckschrift D1 in den verschiedenen Ausführungsbeispielen offenbarten Schichten „Data Management“, „Application Logic“ und „Presentation Services“ so zu unterteilen, dass die fünf Schichten, beginnend mit der untersten Schicht, folgende Schichten umfassen:

- eine Serviceschicht als Bestandteil der „Data Management“-Schicht zur Bereitstellung von lokalen Daten-Diensten – d.h. eine dem Datenmanagement der Applikation selbst dienende Datenzugriffschicht - für ein Framework – hier dem Programm „Forté service“ (vgl. Fig. 3, i.V.m. mit den zugehörigen Beschreibungsstellen in Sp. 4, Z. 5-17 und Sp. 7, Z. 12 -36: „Each distributed service with which the application interacts is an object. For example, a database management […]“, i.V.m. „[…] an object that provides a Forté service […]“ / Merkmal M1.1 in einer beanspruchten Alternative),

- eine ebenfalls der „Data Management“-Schicht zugeordneten, dem Datenmanagement der Applikation selbst dienenden Datenzugriffschicht („database accesses from the application program […]“, vgl. Sp. 7, Zn. 13 ff) für den Zugriff auf Daten und zur Bereitstellung von lokalen und/oder externen Daten- und Kommunikationsdiensten zu unterteilen (vgl. hierzu auch die in Fig. 3 aufgeführte „SQL“-Datenbanksprache zum Bearbeiten und Abfragen von Datenbeständen zu unterteilen / Merkmal M1.2).

- eine Verarbeitungsschicht als Bestandteil der „Application Logic“ zur Bereitstellung von Verarbeitungsdiensten zur Verarbeitung von Daten, die durch das „Data Management“ bereitgestellt werden, (vgl. Fig. 3 mit zugehörigen Beschreibung / Merkmal M1.3 in einer beanspruchten Alternative),

- einer zusätzlichen ebenfalls der „Application Logic“ zugeordneten Prozessschicht zur Bereitstellung einer Business-Logik, also eine Funktionalität zur Aufbereitung der verarbeiteten Daten an Hand von „business rules“, wie dies als Prozessschritt in der Druckschrift D1, Sp. 10, Zn. 8-9 offenbart ist (Merkmal M1.4),

und

- eine Präsentationsschicht („Presentation Services“) zur Darstellung von Daten (vgl. bspw. Fig. 3 und den zugehörigen Text / Merkmal M1.5 in einer beanspruchten Alternative).

Die weitere Aufteilung der aus Druckschrift D1 bekannten übergeordneten Schichten („Data Management“, „Application Logic“ und „Presentation Services“) durch den Fachmann in genau 5 Schichten entspricht dabei lediglich einer – aus der D1 prinzipiell bekannten - Anpassung der technischen Lehre der Druckschrift D1 an eine konkrete Hardwareausgestaltung. Beispielsweise hätte vorliegend bei Bedarf zusätzlich auch die Präsentationsschicht entsprechend aufgeteilt werden können. Eine solche, im Belieben des Fachmanns liegende Vorgehensweise kann aber keine erfinderische Tätigkeit begründen.

Aus Druckschrift D1 ist weiter bekannt, dass jede der Schichten in einer generischen Laufzeitumgebung gekapselt ist („distributed runtime environment“, vgl. Sp. 21, Z. 44), wobei sich die Kapselung aus der unabhängigen Lauffähigkeit der jeweiligen Schicht im Zusammenhang mit der vorstehend abgehandelten Aufteilung resp. Partitionierung von Schichten ergibt („supports object orientation with encapsulation, […]“, vgl. Sp. 18, Zn. 18-20 / Merkmal M2),

Die D1 beschreibt weiter, dass die gekapselten Schichten über Anwendungsschnittstellen miteinander kommunizieren (vgl. „data stream“, „SQL“ bzw. „Messages” in Fig. 3-5, i.V.m. Sp. 20, Zn. 37-38 : „Each partition is serviced by a collection of Forté system services that manage communications among partitions […]“/ Merkmal M3).

Ferner offenbart die D1 im Zusammenhang mit den dortigen Figuren 3 bis 5, dass jede Anwendungsschnittstelle eine Verschaltungsschnittstelle („local object request broker“) umfasst, die in Abhängigkeit von den zugrunde liegenden Plattformen der einzelnen gekapselten Schichten die für die Kommunikation über die Anwendungsschnittstelle zwischen den gekapselten Schichten notwendigen Kommunikationsprofile bereitstellt (vgl. Sp. 7, Zn. 49-66, insbesondere Z. 58ff, „a broker reproduces the interface of a corresponding service object so that when a method is invoked on the service object, all requests are captured by the lolkal object request broker then forewarded to the actual service object for processing“ i.V.m. Sp. 9, Zn. 22-29, und Zn. 35-41/ Merkmal M4*).

Gemäß der Lehre der D1 kann dabei die Verschaltungsschnittstelle durch Konfiguration für unterschiedliche Deployments der Schichten angepasst werden, ohne dass hierfür eine Quellcodeanpassung der Verschaltungsschnittstelle erforderlich ist (vgl. Sp. 5, Zn. 27-29, „The original partitioning […] can be modified automatically“; sowie: Sp. 9, Zn. 26-29, „It automates the communications among the different application partitions so that the application will function the same whether it runs entirely on the client or is distributed across several machines.“). Dabei kann jede Anwendungsschnittstelle (einschließlich der Verschaltungsschnittstelle) durch Konfiguration an bestimmte Deployments der Schichten angepasst werden (vgl. Sp. 5, Zn. 19-23, „Each object is assigned to a partition and each partition is assigned to a target computer and loaded to allow the application program to run“, i.V.m. vorstehender Textstelle Sp. 9, Zn. 26-29 / Merkmal M5*).

Das Verfahren gemäß D1 ermöglicht dem Entwickler mit der vorstehend beschriebenen Ausgestaltung, verschiedene Deployments zu realisieren. So ist in der D1 auf Seite 9, Zn. 22 ff, ausgeführt, dass mit der beliebigen Partitionierung eine Applikation als eine Sammlung - beliebig definierter - einzelner Serviceobjekte (Schichten) möglich ist, wodurch es dem Anwender oder dem Programmierer möglich ist, die Applikation – in beliebiger Weise – auf Server und Clients zu verteilen.

Konkret offenbart die Druckschrift D1 an dieser Textstelle ein Fat-ClientDeployment, bei dem alle Schichten auf einem einzigen Rechner implementiert sind („It automates the communications among the different application partitions so that the application will function the same whether it runs entirely on the client or is distributed across several machines“, vgl. Sp. 9, Zn. 26-29 / Merkmal M5.1).

Mit dem an dieser Textstelle genannten beliebigen Verteilen der Applikationsteile auf verschiedene Maschinen, d.h. Server und Clients, hat der Fachmann zudem die Anregung, je nach Bedarf auch andere Ausgestaltungen der Deployments zu wählen.

Diesbezüglich wird er die verschiedenen Möglichkeiten der Aufteilung einer 5-schichtigen Applikation abhängig von der vorhandenen Hardwarekonfiguretion in Erwägung ziehen, wobei ihm gemäß vorstehender allgemeiner Ausführungen ersichtlich ist, dass mit dem Verfahren zur Erzeugung einer fünfschichtigen Softwareapplikation nach Druckschrift D1 die Verschaltungsschnittstelle ohne Quellcodeanpassung neben dem Fat-Client-Deployment auch für die folgenden Deployments angepasst werden kann:

- Ein Rich-Client Deployment, bei welchem die Serviceschicht (als ein unterster Teil der „Data Management“-Schicht in D1) auf einem oder mehreren Servern implementiert ist, und bei dem die Datenzugriffsschicht (als ein weiterer Teil der „Data Management“-Schicht in D1), die Verarbeitungsschicht und die Prozessschicht (in D1 zusammengefasst als „Application Logic“-Schicht), und die Präsentationsschicht

(„Presentation Services“-Schicht) auf einem Client implementiert sind, ergibt sich naheliegend aus Fig. 4 unter einer weiteren Aufteilung der „Data Managment“-Schicht auf Client und Server, bspw. analog zur Aufteilung der „Application-Logic“-Schicht in Figur 5 (Merkmal M5.2).

- Ein Smart-Client-Deployment. Dies ergibt sich aus der D1 in naheliegender Weise aus Fig. 5, gemäß welcher die Serviceschicht und Bestandteile der Datenzugriffsschicht („Data Management“-Schicht) auf dem Server implementiert sind, die Prozessschicht und Bestandteile der Verarbeitungsschicht („Application Logic“-Schicht) und die Präsentationsschicht („Presentation Services“-Schicht) auf dem Client implementiert sind, und wobei weitere Bestandteile der Verarbeitungsschicht (als ein weiterer Teil der „Application Logic“-Schicht) auf dem Client implementiert sind. Eine weitergehende Aufteilung der Datenzugriffsschicht (als Teil „Data Management“-Schicht) zur Implementierung dieses Teils auf dem Client liegt ausgehend von der Lehre der Druckschrift D1, bspw. in Analogie zu möglichen Aufteilungsvarianten nach Fig. 9 nahe (Merkmal M5.3).

- Ein Rich-Thin-Client-Deployment, bei dem die Serviceschicht, die Datenzugriffsschicht (in D1 zusammengefasst als „Data Management“Schicht) und die Verarbeitungsschicht („Application Logic“-Schicht) auf dem Server implementiert sind, und bei dem die Prozessschicht (als ein weiterer Teil der „Application Logic“-Schicht) und die Präsentationsschicht („Presentation Services“-Schicht) auf dem Client implementiert sind. Dies ergibt sich direkt aus Figur 5 (Merkmal M5.4).

- Ein Thin-Client-Deployment, bei dem die Serviceschicht, die Datenzugriffsschicht (in D1 zusammengefasst als „Data Management“-Schicht), die Verarbeitungsschicht und die Prozessschicht (in D1 zusammengefasst als „Application Logic“-Schicht) auf einem oder mehreren Ser- vern implementiert sind, und bei dem die Präsentationsschicht („Presentation Services“-Schicht) auf dem Client implementiert ist. Dies ergibt sich naheliegend aus Fig. 3 für eine nicht weiter aufgeteilte Präsentationsschicht analog zur „Presentation Services“-Schicht in den Ausführungsbeispielen der Figuren 4 und 5 (Merkmal M5.5).

Das Verfahren nach Anspruch 1 gemäß Hilfsantrag 2 ergibt sich somit zumindest in einer Ausführungsform für den Fachmann in naheliegender Weise aus der Lehre der Druckschrift D1 und beruht daher nicht auf einer erfinderischen Tätigkeit, weshalb das entsprechende Verfahren nicht patentfähig ist.

b) Zum Hilfsantrag 3 Anspruch 1 nach Hilfsantrag 3 beruht, ausgehend von der Druckschrift D1 verbunden mit fachmännischem Handeln, ebenfalls auf keiner erfinderischen Tätigkeit des zuständigen Fachmanns.

Anspruch 1 gemäß Hilfsantrag 3 unterscheidet sich vom Anspruch 1 des Hilfsantrags 2 durch das zusätzlich angefügte Merkmal M6, wonach „die in den gekapselten Schichten implementierten Dienste und/oder Komponenten und/oder Daten bezüglich standardisierter Anwendungsschnittstellen konzipiert werden“.

Das zusätzlich aufgenommene Merkmal M6 vermag die erfinderische Tätigkeit jedoch ebenfalls nicht zu begründen. Denn gemäß Druckschrift D1 werden für die gekapselten Schichten der Anwendungssoftware mit dem Kommunikationssystem des Frameworks für die implementierten Dienste ebenfalls standardisierte Anwendungsschnittstellen bereitgestellt (vgl. Sp. 21, Zn. 54-56, „Forté provides communications among application partitions with its own distributed messaging system.“) und eine Reihe standardisierter Anwendungsschnittstellen unterstützt (vgl. Sp. 16, Z. 54, Hinweis auf „Network-TCP/IP, DECnet, Novell, AppleTalk“, / Merkmal M6 in zumindest einer Alternative).

Wegen der restlichen Merkmale wird auf die Ausführungen zum Anspruch 1 nach Hilfsantrag 2 verwiesen, die hier in gleicher Weise gelten.

Auch das Verfahren gemäß Anspruch 1 nach Hilfsantrag 3 ergibt sich somit zumindest in einer Ausführungsform für den Fachmann in naheliegender Weise aus Druckschrift D1 und beruht daher nicht auf einer erfinderischen Tätigkeit.

c) Zum Hilfsantrag 4 Auch Anspruch 1 nach Hilfsantrag 4 beruht auf der Grundlage der Druckschrift D1 sowie dem fachmännischen Handeln auf keiner erfinderischen Tätigkeit.

Anspruch 1 gemäß Hilfsantrag 4 unterscheidet sich vom Anspruch 1 des Hilfsantrags 2 durch das geänderte Merkmal M3*, wonach die Kommunikation der gekapselten Schichten miteinander „über Anwendungsschnittstellen der jeweiligen generischen Laufzeitumgebung“ erfolgt.

Das geänderte Merkmal M3* vermag allerdings keine erfinderische Tätigkeit zu begründen, denn die D1 offenbart – wie bereits zuvor dargelegt – den Verfahrensschritt, dass gekapselte Schichten über Anwendungsschnittstellen der jeweiligen generischen Laufzeitumgebung miteinander kommunizieren („Forté provides communications among application partitions with its own distributed messaging system.“, vgl. Sp. 21, Zn. 54-56,

i.V.m. „[…] the distributed runtime environment must provide communications among the application partitions.“, vgl. Sp. 21, Zn. 44-46 / Merkmal M3*).

Wegen der restlichen Merkmale wird ebenfalls auf die Ausführungen zum Anspruch 1 nach Hilfsantrag 2 verwiesen.

Auch das Verfahren gemäß Anspruch 1 nach Hilfsantrag 4 ergibt sich somit für den Fachmann in naheliegender Weise aus Druckschrift D1 und beruht daher nicht auf einer erfinderischen Tätigkeit.

4. Mit den jeweils nicht zulässigen Ansprüchen 1 nach Hauptantrag und Hilfsantrag 1, sowie den nicht patentfähigen Ansprüchen 1 nach den Hilfsanträgen 2 bis 4 sind auch jeweils die weiteren Ansprüche nicht schutzfähig, da auf diese Ansprüche kein eigenständiges Patentbegehren gerichtet ist (vgl. BGH GRUR 2007, 862, Leitsatz – „Informationsübermittlungsverfahren II“).

5. Nachdem die jeweiligen Anspruchssätze nach Hauptantrag bzw. den jeweiligen Hilfsanträgen 1 bis 4 nicht patentfähig sind, war die Beschwerde zurückzuweisen.

Maile Schwarz Dr. Schwengelbeck Altvater Hu