18 W (pat) 133/14

BUNDESPATENTGERICHT W (pat) 133/14 Verkündet am 22. März 2017

…

BESCHLUSS In der Beschwerdesache betreffend die Patentanmeldung 10 2011 083 887.2-53 …

BPatG 154 05.11 hat der 18. Senat (Techn. Beschwerdesenat) des Bundespatentgerichts auf die mündliche Verhandlung vom 22. März 2017 durch die Vorsitzende Richterin Dipl.-Ing. Wickborn sowie die Richter Kruppa, Dipl.-Phys. Dr. Schwengelbeck und Dr.-Ing. Flaschke beschlossen:

1. Die Beschwerde wird zurückgewiesen. 2. Der Antrag auf Rückzahlung der Beschwerdegebühr wird zurückgewiesen.

Gründe I.

Die am 30. September 2011 beim Deutschen Patent- und Markenamt eingereichte Patentanmeldung 10 2011 083 887.2 mit der Bezeichnung

„Automatisches Selbsttestverfahren für medizinische Geräte“

wurde durch die Prüfungsstelle für Klasse G 06 F des Deutschen Patent- und Markenamts mit in der Anhörung vom 21. September 2012 verkündeten Beschluss zurückgewiesen.

Die Prüfungsstelle hat ihren Zurückweisungsbeschluss damit begründet, dass die Gegenstände des jeweiligen Patentanspruchs 1 nach Haupt- und (damals geltendem) Hilfsantrag 1 sowie der Gegenstand des Patentanspruchs 11 nach (damals geltendem) Hilfsantrag 2 mangels erfinderischer Tätigkeit nicht gewährbar seien, wobei auf folgenden Stand der Technik verwiesen wurde:

D1: US 2008/0168434 A1 und D3: DUNN, R.: Windows Update Agent force script, email results version

2.6; A VBScript script in the WSUS category; 2009. URL:http://community.spiceworks.com/scripts/show/82-windowsupdate-agent-force-script-email-results-version-2-6, Archiviert in http://www.archive.org am 16.10.2009 [abgerufen am 30.05.2012].

Gegen diesen Beschluss ist die Beschwerde der Anmelderin gerichtet.

Mit Ladungszusatz vom 22. Februar 2017 hat der Senat die Druckschriften D4: US 2008/0184219 A1 und D5: DE 10 2008 003 440 A1 ins Verfahren eingeführt und darauf hingewiesen, dass die Gegenstände der nebengeordneten Patentansprüche - soweit offenbart - gegenüber Druckschrift D4 in Verbindung mit Druckschrift D5 nicht auf einer erfinderischen Tätigkeit beruhen dürften.

Die Anmelderin beantragt, 1. den Beschluss der Prüfungsstelle für Klasse G 06 F des Deutschen Patent- und Markenamts vom 21. September 2012 aufzuheben und das Patent auf der Grundlage der folgenden Unterlagen zu erteilen:

- Patentansprüche 1 bis 12, eingegangen am 28. Juni 2012, hilfsweise gemäß Hilfsantrag I Patentansprüche 1 bis 11, eingereicht in der mündlichen Verhandlung, hilfsweise gemäß Hilfsantrag II Patentansprüche 1 bis 12, eingereicht in der mündlichen Verhandlung, hilfsweise gemäß Hilfsantrag III Patentansprüche 1 bis 11, eingereicht in der mündlichen Verhandlung,

- Beschreibung Seiten 1 bis 27, - Figuren 1 bis 3,

jeweils eingegangen am 30. September 2011,

2. die Rückzahlung der Beschwerdegebühr anzuordnen.

Der seitens des Senats mit einer Gliederung versehene Anspruch 1 nach Hauptantrag lautet:

M1 „Verfahren zur Validierung zumindest eines Betriebssystem-Patches (P) für eine Applikation, die auf einem medizinischen bildgebenden Gerät (30) eines Applikationssystems (AS) implementiert ist, umfassend folgende Verfahrensschritte:

M2 - Ausgabe eines Betriebssystem-Patches (P) seitens eines Betriebssystemherstellersystems (10)

M3 - Bereitstellen eines Patchmoduls (PM) auf dem medizinischen bildgebenden Gerät (30)

M4 - Empfang des Betriebssystem-Patches (P) seitens des Patchmoduls (PM)

M5 - Ausführen eines automatischen Selbsttests auf dem medizinischen bildgebenden Gerät (30) seitens des Patchmoduls (PM) auf Basis des empfangenen Betriebssystem-Patches (P) und M6 Senden eines Validierungssignals (V) bei erfolgreichem Selbsttestergebnis,

M7 wobei der automatische Selbsttest unter Anwendung der Applikation für das medizinische bildgebende Gerät (30) mit Testdaten, insbesondere mit medizinischen Bilddaten, ausgeführt wird M8 und einen klinischen Probebetrieb des medizinischen bildgebenden Gerätes (30) simuliert.“

Wegen der Ansprüche 2 bis 12 nach Hauptantrag wird auf die Akte verwiesen.

Der seitens des Senats mit einer Gliederung versehene Anspruch 1 nach Hilfsantrag I lautet (Änderungen gegenüber dem Anspruch 1 nach Hauptantrag hervorgehoben):

M1* „Verfahren zum zur Validierenung zumindest eines BetriebssystemPatches (P) für eine Applikation, die auf einem medizinischen bildgebenden Gerät (30) eines Applikationssystems (AS) implementiert ist, mit den umfassend folgende Verfahrensschritten:

M2* - Ausgebenabe eines Betriebssystem-Patches (P) seitens eines Betriebssystemherstellersystems (10); M3* - Bereitstellen eines Patchmoduls (PM) auf dem medizinischen bildgebenden Gerät (30); M4* - Empfangen des Betriebssystem-Patches (P) seitens des Patchmoduls (PM); und M5* - Ausführen eines automatischen Selbsttests auf dem medizinischen bildgebenden Gerät (30) seitens des Patchmoduls (PM) auf Basis des empfangenen Betriebssystem-Patches (P)

M7* wobei der automatische Selbsttest unter Anwendung der Applikation für das medizinische Gerät (30) mit medizinischen Bilddaten als Testdaten, insbesondere mit medizinischen Bilddaten, ausgeführt wird M8* Simulieren eines und einen klinischen Probebetriebs des medizinischen bildgebenden Gerätes (30) simuliert und M6 Senden eines Validierungssignals (V) bei erfolgreichem Selbsttestergebnis.“

Wegen der Ansprüche 2 bis 11 nach Hilfsantrag I wird auf die Akte verwiesen.

Der seitens des Senats mit einer Gliederung versehene Anspruch 1 nach Hilfsantrag II lautet (Änderungen gegenüber dem Anspruch 1 nach Hilfsantrag I hervorgehoben):

M1* „Verfahren zum Validieren eines Betriebssystem-Patches (P) für eine Applikation, die auf einem medizinischen Gerät (30) eines Applikationssystems (AS) implementiert ist, mit den Verfahrensschritten:

M2* - Ausgeben eines Betriebssystem-Patches (P) seitens eines Betriebssystemherstellersystems (10); M3* - Bereitstellen eines Patchmoduls (PM) auf dem medizinischen Gerät (30); M4* - Empfangen des Betriebssystem-Patches (P) seitens des Patchmoduls (PM); und M5** - Ausführen eines automatischen Selbsttests für die Applikation auf dem medizinischen Gerät (30) seitens des Patchmoduls (PM) auf Basis des empfangenen Betriebssystem-Patches (P) und M7* unter Anwendung der Applikation für das medizinische Gerät (30) mit medizinischen Bilddaten als Testdaten,

M8* Simulieren eines Probebetriebs des medizinischen Gerätes (30) M6* Senden eines Validierungssignals (V) bei erfolgreichem Selbsttestergebnis an das Betriebssystemherstellersystem.“

Wegen der Ansprüche 2 bis 12 nach Hilfsantrag II wird auf die Akte verwiesen.

Der seitens des Senats mit einer Gliederung versehene Anspruch 1 nach Hilfsantrag III lautet (Änderungen gegenüber dem Anspruch 1 nach Hilfsantrag II hervorgehoben):

M1** „Verfahren zum Validieren eines Betriebssystem-Patches (P) für eine Applikation zum Steuern eines medizinischen Gerätes, die auf eindem medizinischen Gerät (30) eines Applikationssystems (AS) implementiert ist, mit den Verfahrensschritten:

M2* - Ausgeben eines Betriebssystem-Patches (P) seitens eines Betriebssystemherstellersystems (10); M3* - Bereitstellen eines Patchmoduls (PM) auf dem medizinischen Gerät (30); M4* - Empfangen des Betriebssystem-Patches (P) seitens des Patchmoduls (PM); und M5*** - Ausführen eines automatischen Selbsttests für die Applikation auf dem medizinischen Gerät (30) seitens des Patchmoduls (PM) auf Basis des empfangenen Betriebssystem-Patches (P) und einer Validierung, ob die Applikation in der bereitgestellten Funktionalität mit dem Betriebssystem-Patch funktioniert und M6 Senden eines Validierungssignals (V) bei erfolgreichem Selbsttestergebnis an das Betriebssystemherstellersystem M9 und das Ausgeben und/oder Empfangen des Betriebssystem-Patches (P) nach konfigurierbaren Zeitintervallen ausgeführt werden.“

Wegen der Ansprüche 2 bis 11 nach Hilfsantrag III wird auf die Akte verwiesen.

Die Anmelderin macht hierzu geltend, dass die geänderten Anspruchsfassungen zulässig seien, die Gegenstände der Ansprüche neu seien und auf einer erfinderischen Tätigkeit beruhten.

Wegen der weiteren Einzelheiten wird auf den Akteninhalt verwiesen.

II.

Die zulässige Beschwerde hat in der Sache keinen Erfolg. Denn die Gegenstände der jeweiligen Ansprüche 1 nach Hauptantrag sowie nach den Hilfsanträgen I, II und III beruhen nicht auf einer erfinderischen Tätigkeit (§ 4 PatG). Die Fragen der Zulässigkeit der geltenden Ansprüche nach Hauptantrag sowie nach den Hilfsanträgen I, II und III sowie der Neuheit der Anspruchsgegenstände können somit dahinstehen (vgl. BGH, Urteil vom 18. September 1990 – X ZR 29/89, GRUR 1991, 120, 121 li. Sp. Abs. 3 - Elastische Bandage).

1. Die Anmeldung betrifft ein automatisches Selbsttestverfahren für medizinische Geräte. Gemäß der Beschreibungseinleitung seien medizinische Geräte, wie beispielsweise Medizingeräte für diagnostisch bildgebende Verfahren oder Geräte im Rahmen einer Koloskopie, Laborgeräte, Ultraschallgeräte oder Magnetresonanztomographen, durch Software gesteuert und umfassten ein Betriebssystem oder eine bestimmte Schicht einer informationstechnologischen Infrastruktur, die als Verteilungsplattform für anwendungsbezogene Dienste diene. Im Stand der Technik sei eine Dreiteilung hinsichtlich der grundlegenden Systeme vorgesehen: Einerseits gebe es den Hersteller des Betriebssystems oder der jeweiligen Middleware, der üblicherweise kommerzielle Softwareprodukte vertreibe. Andererseits gebe es Hersteller medizintechnischer Geräte, die die Geräte herstellten und mit Software auf Basis des Betriebssystems ausrüsteten und an klinische Einrichtungen lieferten. Zudem gebe es klinische Einrichtungen, die die medizinischen Geräte anwendeten (Krankenhäuser, Arztpraxen, etc.). Aufgrund von Vorschriften sei es erforderlich, dass die im Einsatz befindlichen medizinischen Geräte ständig auf Einhaltung von Sicherheitsvorschriften überwacht werden würden. Dazu sei es notwendig sicherzustellen, dass stets die neueste Softwareversion des Betriebssystems aufgespielt sei. Dafür sei vorgesehen, dass der Betriebssystemhersteller sogenannte Patches, also Korrekturauslieferungen der Software, erstelle und ausliefere. Bisher liefere der Betriebssystemhersteller die Patches an den Gerätehersteller aus, der diese auf Zulässigkeit validiere. Erst nachdem die Zulässigkeit des Patches geprüft worden sei, könne der Patch an die medizinische Einrichtung (z. B. Krankenhaus) ausgeliefert werden, was üblicherweise zu deutlichen Verzögerungszeiten führe. Ein wesentlicher Nachteil des bisherigen Vorgehens sei demnach die beträchtliche Zeitdauer und die Befassung von unterschiedlichen Institutionen. Nach Ausgabe des Patches wäre es erforderlich gewesen, zunächst darauf zu warten, dass der Gerätehersteller den Patch validiere. Des Weiteren hätte gewartet werden müssen, bis der Gerätehersteller den Patch an seine Kunden weiterleite, welche dann eine Überprüfung vornehmen würden. Im Fehlerfall könne dann über den Gerätehersteller der Betriebssystemhersteller informiert werden. Hier komme es zu Zeitverzögerungen, wenn ein Verzug bei einem Glied der vorstehend genannten Kette auftrete (vgl. Beschreibung, S. 1, Z. 3 - S. 2, Z. 32).

Als Aufgabe wird sinngemäß angegeben, das Testen von Betriebssystem-Patches für medizintechnische Geräte zu beschleunigen, zu verbessern und fehlerfreier ausführbar zu machen (vgl. Beschreibung S. 2, letzter Abs.).

Der Fachmann, der mit der Lösung der Aufgabenstellung betraut wird, hat eine abgeschlossene Hochschulausbildung auf dem Gebiet der Informations- oder Elektrotechnik und besitzt Kenntnisse in der Entwicklung von sicherheitsrelevanter Software. Darüber hinaus verfügt er über eine langjährige Erfahrung im Patch-Management für medizinische Geräte.

Die genannte Aufgabe soll unter anderem durch die Merkmale des Anspruchs 1 nach Hauptantrag gelöst werden. Danach ist ein Verfahren zur Validierung zumindest eines seitens eines Betriebssystemherstellersystems ausgegebenen Betriebssystem-Patches für eine Applikation, die auf einem medizinischen bildgebenden Gerät eines Applikationssystems implementiert ist, vorgesehen, wobei das medizinische Gerät ein Patchmodul bereitstellt. Das Patchmodul empfängt das Betriebssystem-Patch und führt einen automatischen Selbsttest auf dem medizinischen Gerät durch, wobei der Test unter Anwendung der Applikation für das medizinische bildgebende Gerät mit Testdaten ausgeführt und ein klinischer Probebetrieb des medizinischen bildgebenden Gerätes simuliert wird. Bei erfolgreichem Selbsttestergebnis wird ein Validierungssignal gesendet.

Im Anspruch 1 nach Hilfsantrag I ist konkretisiert, dass die Testdaten medizinische Bilddaten sind, während im Anspruch 1 nach Hilfsantrag II zusätzlich aufgeführt wird, dass das Validierungssignal an das Betriebssystemherstellersystem gesandt wird.

In der Fassung des Hilfsantrags III ist zusätzlich vorgesehen, dass die Applikation zum Steuern eines medizinischen Gerätes dient, und dass eine Validierung, ob die Applikation in der bereitgestellten Funktionalität mit dem BetriebssystemPatch funktioniert, ausgeführt wird. Zudem soll das Ausgeben und/oder Empfangen des Betriebssystem-Patches nach konfigurierbaren Zeitintervallen ausgeführt werden.

2. Einige Merkmale bedürfen der Auslegung:

Der Anspruch 1 nach Hauptantrag sowie die jeweiligen Ansprüche 1 nach den Hilfsanträgen I bis III betreffen Verfahren zur Validierung bzw. zum Validieren eines Betriebssystem-Patches (vgl. Merkmale M1, M1*, M1**). Bei dem Betriebssystem-Patch kann es sich um ein Update handeln, welches zu fest konfigurierten Zeitintervallen vom Hersteller bereitgestellt wird. Ebenso kann es einen sogenannten Hotfix oder Bugfix umfassen, um erkannte Sicherheitslücken des Betriebssystems im medizinischen Gerät schließen zu können (vgl. S. 6, Z. 19 - S. 7, Z. 15 der geltenden Beschreibung). Das Patch liegt als ausführbarer Code vor und wird vom Betriebssystemhersteller an das das Gerät umfassende Applikationssystem (z. B. klinische Einrichtung) ausgegeben (vgl. Abs. S. 5, Z. 6 - S. 7, Z. 15; Merkmal M2). Von zentraler Bedeutung ist das Patchmodul (vgl. Merkmal M3). Bei dem Patchmodul handelt es sich um Software und/oder Hardware, die als Instanz des Betriebssystemherstellers auf dem medizinischen bildgebenden Gerät bereitgestellt wird (vgl. Abs. S. 5, zweiter Abs. u. Brückenabs. S. 8 / 9). Im zweiten Absatz auf Seite 20 wird beschrieben, dass das Patchmodul alternativ auch auf dem Rechner implementiert sein kann, der das medizinische Gerät steuert. Außerdem kann sich das Patchmodul auch auf einem zentralen Rechner befinden (vgl. Fig. 1 i. V. m. S. 20, zweiten Abs.). Im Wesentlichen hat das Patchmodul folgende vier Funktionen:

a) Empfang des Betriebsystem-Patches (vgl. Merkmal M4). Im jeweiligen Anspruch 1 wird nicht eindeutig angegeben, ob das Patchmodul das Update selbst empfängt oder nur den Download auf die medizinischen Geräte steuert. Der Beschreibung ist zu entnehmen, dass das Update direkt vom Patchmodul empfangen wird (vgl. Brückenabs. S. 8 / 9, S. 20, erster Abs. u. S. 26, zweiter Abs.). Insbesondere wird es nach konfigurierbaren Zeitintervallen empfangen (vgl. Merkmal M9).

b) Installation des Patches auf dem medizinischen Gerät (vgl. Brückenabs. S. 8 / 9 u. Brückenabs. S. 12 / 13).

c) Ausführen eines Selbsttestes (vgl. Merkmal M5). Dieser wird direkt auf dem medizinischen Gerät unter der Verwendung von Testdaten durchgeführt (vgl. Brückenabs. S. 10 / 11; Merkmal M7). Den Test, der als Validierung durchgeführt wird, versteht der Fachmann als Prüfung, ob die Anforderungen an das Update speziell für das medizinische bildgebende Gerät erfüllt sind (vgl. Merkmale M1, M5***). Bei den Testdaten kann es sich um vorverarbeitete Messdaten, simulierte Patientendaten oder Testbilder handeln (vgl. Brückenabsatz S. 10 / 11 u. S. 21, Z. 14 - S. 23, Z. 3). Gemäß Anspruch 1 nach Hilfsantrag I soll der automatische Selbsttest mit medizinischen Bilddaten als Testdaten ausgeführt werden (vgl. Merkmal M7*). Handelt es sich bei dem medizinischen Gerät beispielsweise um einen Computertomographen zur Ausführung einer virtuellen Koloskopie, so werden während des Selbsttests Testbilder als Eingangsgrößen bereitgestellt. Die Applikation zur Darstellung der Bilder wird dann auf Basis der Testbilder ausgeführt (vgl. S. 8, Z. 6 - 31 u. S. 10, Z. 30 - 37). Auf diese Weise wird quasi ein Probebetrieb des medizinischen bildgebenden Gerätes simuliert (vgl. Merkmal M8).

d) Senden eines Validierungssignals (vgl. Merkmal M6): Bei Übereinstimmung des Selbsttestergebnisses mit einem Referenzergebnis gilt der Selbsttest als erfolgreich. In diesem Fall wird ein Validierungssignal generiert, das einen erfolgreichen Selbsttest indizieren soll. Das Validierungssignal kann ein digitales Signal (z. B. ein Flag), ein akustisches und/oder optisches Signal sein (vgl. Brückenabsatz S. 10 / 11). Das Validierungssignal wird bei einem erfolgreichen Selbsttestergebnis an das Betriebssystemherstellersystem gesendet (Merkmal M6*).

3. Das Verfahren gemäß Anspruch 1 nach Hauptantrag beruht für den Fachmann in Kenntnis der Druckschriften D4 und D5 nicht auf einer erfinderischen Tätigkeit (§ 4 PatG).

Druckschrift D4 befasst sich - ebenso wie die vorliegende Anmeldung - mit einem automatischen Selbsttestverfahren für medizinische Geräte (vgl. Fig. 1, 2 u. 6A i. V. m. Abs. [0022], [0033], [0074] u. Anspruch 1). Konkret wird ein Verfahren zur Validierung eines Software-Updates für eine Applikation beschrieben, die auf einem medizinischen bildgebenden Gerät implementiert ist (vgl. Fig. 1, Bezugszeichen 300, 301, 304 u. Fig. 2 i. V. m. Abs. [0022] vierter u. sechster Satz sowie Anspruch 1). Dem Absatz [0052] entnimmt der Fachmann in Verbindung mit Absatz [0005], dass die vorgesehenen Software-Updates auch Betriebssystem-Patches umfassen. Das medizinische bildgebende Gerät 300 ist mit einem Service-Terminal 200 verbunden. Beide Geräte befinden sich am gleichen Ort, z. B. in einem Krankenhaus (vgl. Fig. 1 u. 3 i. V. m. Abs. [0022] u. [0025]). Damit ist das medizinische bildgebende Gerät auch in ein Applikationssystem eingebunden (Merkmal M1).

Des Weiteren ist das Service-Terminal 200 über das Internet mit einem FernWartungssystem 100 verbunden (vgl. Fig. 1 - 3 u. Abs. [0047] u. [0025]). Dieses verfügt über eine Datenbank 103, in der Updates für verschiedene Applikationssysteme und verschiedene Programm-Versionen gespeichert sind (vgl. Fig. 2 u. Abs. [0028]). Nach einer Kompatibilitätsprüfung stellt das Wartungssystem ein neues Betriebssystem-Patch zum Download bereit (vgl. Abs. [0052] u. [0056] i. V. m. Fig. 2 u. 6A). Für den Fachmann liegt es auf der Hand, dass das FernWartungssystem seitens des Software-Herstellers betrieben wird und damit als Betriebssystemherstellersystem anzusehen ist (Merkmal M2).

Das vom Hersteller ausgegebene Patch wird an das Terminal des medizinischen Gerätes übertragen. Dort wird eine Systemüberwachungs-Software bereitgestellt, welche das Betriebssystem-Patch empfängt (vgl. Bezugszeichen 204 in Fig. 1, 3, Fig. 6A i. V. m. Abs. [0030], [0040], [0058] u. [0063]). Die SystemüberwachungsSoftware sieht der Fachmann als Patchmodul an (Merkmal M4, teilweise Merkmal M3, ohne dass das Patchmodul auf dem medizinischen Gerät bereitgestellt wird).

Zur Validierung des Betriebssystem-Patches werden zwei Tests durchgeführt: Zunächst wird ein automatischer Selbsttest durchgeführt, bevor das Update auf dem medizinischen Gerät installiert wird. Hierbei wird das Betriebssystem-Patch zunächst auf dem Service-Terminal zwischengespeichert und seitens des Patch- Moduls getestet (vgl. Abs: [0033]; teilweise Merkmal M5, ohne Ausführen des Tests auf dem medizinischen Gerät). Der Test wird unter Anwendung der Applikation für das medizinische bildgebende Gerät mit Testdaten ausgeführt. Auf diese Weise wird ein klinischer Probebetrieb des medizinischen bildgebenden Gerätes simuliert (vgl. Abs. [0033] u. [0061] i. V. m. Fig. 4 u. 6A; teilweise Merkmal M7, ohne Ausführen des Tests auf dem medizinischen Gerät). Ist das Selbsttestergebnis erfolgreich, wird ein Validierungssignal versendet (vgl. Abs. [0061]; Merkmale M6). Nach erfolgreichem Test wird das Update schließlich auf das medizinische Gerät gespiegelt (vgl. Abs. [0065] u. [0071]). Nach der Installation des Updates soll ein zusätzlicher Test durch einen Service-Techniker direkt am medizinischen Gerät durchgeführt werden. Auf diese Weise soll sichergestellt werden, dass die Anforderungen an das Update auch speziell für das medizinische Gerät erfüllt sind (vgl. Abs. [0074], [0078] u. Fig. 7A, 7B). Wie der zusätzliche Test konkret abläuft, wird nicht beschrieben.

Auf diese Weise wird ein klinischer Probebetrieb, also ein Betrieb unter den spezifischen Konfigurationen und applikationsspezifischen Anpassungen des konkreten medizinischen Geräts simuliert. Dies ergibt sich auch daraus, dass Patch und Selbsttest unmittelbar im Anschluss an die Verwendung des Geräts in der realen Umgebung ausgeführt werden (D4: Abs. [0033], [0063] u. [0074], [0078]; Merkmal M8).

Demzufolge unterscheidet sich das in Druckschrift D4 beschriebene Verfahren vom vorliegenden Verfahren darin, dass sich das Patchmodul nicht auf dem medizinischen bildgebenden Gerät befindet, sondern auf dem am medizinischen Gerät angeschlossenen Service-Terminal. Zudem wird der automatische Selbsttest nicht auf dem medizinischen bildgebenden Gerät selbst, sondern auf dem Service-Terminal ausgeführt (vgl. Abs. [0033] u. [0061] i. V. m. Fig. 4 u. 6A).

Der Fachmann entnimmt Druckschrift D4 jedoch den Hinweis, dass der auf dem Service-Terminal durchgeführte Selbsttest insbesondere bei sicherheitskritischen Applikationen – wie beim Einstellen einer Strahlendosis bei medizinischen Röntgengeräten – nicht zuverlässig ist. Insbesondere wird offenbart, dass ein zusätz- licher Test auf dem medizinischen Gerät durchgeführt werden muss, nachdem das Update dort installiert wurde. So soll sichergestellt werden, dass die Anforderungen an das Update auch speziell für das medizinische Gerät erfüllt sind. Der Test auf dem medizinischen Gerät soll durch einen Service-Techniker durchgeführt werden (vgl. Abs. [0074], [0078] u. Fig. 7A, 7B). Wie der zusätzliche Test konkret abläuft, wird nicht angegeben. Es sei jedoch zu beachten, dass der Wartungs- und Zeitaufwand möglichst gering sein soll.

Der Fachmann, der das aus Druckschrift D4 bekannte Verfahren nachbilden soll, hat aufgrund der Forderung in den Absätzen [0005] und [0006] bezüglich des Wartungs- und Zeitaufwands sicherheitsrelevanter Tests hinreichend Veranlassung, im Stand der Technik nach weiteren Informationen zu suchen, wie neue Softwarekomponenten auf einem medizinischen bildgebenden Gerät schneller getestet werden könnten.

Eine Information dazu findet der Fachmann in Druckschrift D5. Diese Schrift beschreibt ein Verfahren zur automatisierten Erkennung von fehlerhaften Softwarekomponenten innerhalb eines medizinischen bildgebenden Gerätes (vgl. Abs. [0002], [0006], [0007] u. [0021]). Hierzu wird ein Verifizierungsmodul auf dem medizinischen bildgebenden Gerät bereitgestellt (vgl. Fig. 1 u. 2 i. V. m. Abs. [0032]). Mit Hilfe dieses Verifizierungsmoduls wird auf dem medizinischen bildgebenden Gerät ein automatischer Selbsttest unter realen Bedingungen durchgeführt (vgl. Abs. [0032] - [0034] u. [0013]). Der automatische Selbsttest soll unter Anwendung der Applikation für das medizinische bildgebende Gerät mit Testdaten ausgeführt werden und einen klinischen Probebetrieb des medizinischen bildgebenden Gerätes simulieren (vgl. Abs. [0006], [0009], [0030] u. Ansprüche 1, 2).

Aus wirtschaftlichen Erwägungen heraus wird der Fachmann die Verwendung des in Druckschrift D5 beschriebenen Verifizierungsmoduls auf dem medizinischen bildgebenden Gerät gemäß Druckschrift D4 in Betracht zu ziehen. Dabei ist es naheliegend, das Verifizierungsmodul so auszugestalten, dass das vom Wartungssystem ausgegebene, zu testende Patch direkt an das Verifizierungsmodul übertragen wird. Damit ist das Verifizierungsmodul als Patchmodul anzusehen,

welches auf dem medizinischen bildgebenden Gerät bereitgestellt wird (Merkmal M3). Dies bedeutet nichts anderes, als dass die Ausführung des automatischen Selbsttests seitens des Patchmoduls auf dem medizinischen bildgebenden Gerät und unter Anwendung der Applikation für das medizinische bildgebende Gerät mit Testdaten erfolgt (Merkmale M5, M7).

Der Gegenstand des Anspruchs 1 nach Hauptantrag ist dem Fachmann daher in Kenntnis von Druckschrift D4 in Verbindung mit Druckschrift D5 nahegelegt. Der geltende Patentanspruch 1 nach Hauptantrag ist somit nicht patentfähig.

4. Das Verfahren gemäß Anspruch 1 nach Hilfsantrag I beruht für den Fachmann in Kenntnis der Druckschriften D4 und D5 nicht auf einer erfinderischen Tätigkeit (§ 4 PatG).

Patentanspruch 1 nach Hilfsantrag I unterscheidet sich vom Anspruch 1 nach Hauptantrag darin, dass in Merkmal M7* konkretisiert ist, dass der automatische Selbsttest "mit medizinischen Bilddaten als Testdaten" ausgeführt wird. Die übrigen Merkmale enthalten lediglich redaktionelle Änderungen und sind inhaltsgleich zu den Merkmalen des Anspruchs 1 nach Hauptantrag. Nach Auffassung der Anmelderin ist die Besonderheit darin zu sehen, dass die Bilddatenverarbeitung zuverlässig funktionieren soll und daher der Inhalt der Testdaten, die Bilddaten, für die Sicherheit des medizinischen Gerätes entscheidend seien. Diese Argumentation überzeugt nicht. Wie bereits zum Hauptantrag im Abschnitt II.3. ausgeführt, befasst sich Druckschrift D4 mit einem automatischen Selbsttestverfahren für medizinische bildgebende Geräte, die zwei- oder dreidimensionale Bilddaten liefern. Der Test und die Simulationen der jeweiligen Applikation werden dabei unter Verwendung von medizinischen Bilddaten als Testdaten ausgeführt (vgl. dummy data, image processing hardware control dummy data in Abs. [0034], [0037], [0039] i. V. m. Fig. 4; Merkmal M7*). Darüber hinaus ist es dem hier zuständigen Fachmann überaus geläufig, Bilddaten zunächst als Testdaten für medizinische bildgebende Verfahren vorzusehen, um einen Betrieb eines konkreten medizinischen Geräts unter seinen applikationsspezifischen Konfigurationen und Anpassungen zu testen und zu simulieren. Somit kann die Präzisierung gemäß Anspruch 1 nach Hilfsantrag I eine erfinderische Tätigkeit nicht begründen. Patentanspruch 1 nach Hilfsantrag I ist damit nicht patentfähig.

5. Auch das Verfahren gemäß Anspruch 1 nach Hilfsantrag II beruht für den Fachmann in Kenntnis der Druckschriften D4 und D5 nicht auf einer erfinderischen Tätigkeit (§ 4 PatG).

Anspruch 1 nach Hilfsantrag II unterscheidet sich vom Anspruch 1 nach Hilfsantrag I darin, dass Merkmal M6* ergänzt wurde und die Merkmale M7* und M8* gestrichen wurden. Merkmal M5** ist inhaltsgleich zu Merkmal M5*. Mit Merkmal M6* wird konkretisiert, dass das Validierungssignal bei erfolgreichem Selbsttestergebnis „an das Betriebssystemherstellersystem“ gesendet wird.

Nach Auffassung der Anmelderin wird durch das Informieren des Herstellers sichergestellt, dass dieser im Fehlerfall das Betriebssystem anpassen kann. Diese Änderung des Anspruchs 1 ist nicht geeignet, die erfinderische Tätigkeit zu begründen. Denn Druckschrift D5 offenbart, dass das als Betriebssystemherstellersystem zu verstehende Fern-Wartungssystem bei jedem Testergebnis über das Testergebnis informiert wird (vgl. Abs. [0061], letzter Satz). Demzufolge wird ein Validierungssignal auch dann an das Betriebssystemherstellersystem versendet, wenn das Selbsttestergebnis erfolgreich ist (Merkmal M6*). Deshalb ist das beanspruchte Verfahren auch in der Anspruchsfassung nach Hilfsantrag II nicht patentfähig.

6. Auch das Verfahren gemäß Anspruch 1 nach Hilfsantrag III beruht für den Fachmann in Kenntnis der Druckschriften D4 und D5 nicht auf einer erfinderischen Tätigkeit (§ 4 PatG).

Anspruch 1 nach Hilfsantrag III unterscheidet sich inhaltlich vom Anspruch 1 nach Hilfsantrag II darin, dass Merkmal M9 angefügt wurde. Merkmal M9 konkretisiert die Verfahrensschritte gemäß den Merkmalen M2* und M4*, wonach „das Ausgeben und/oder Empfangen des Betriebssystem-Patches (P) nach konfigurierbaren Zeitintervallen ausgeführt werden“. Auch dieses zusätzlich aufgenommene Merkmal vermag eine erfinderische Tätigkeit nicht zu begründen. Denn Druckschrift D4 entnimmt der Fachmann auch bereits den Hinweis, dass das Empfangen und damit auch das Ausgeben des Betriebssystem-Patches nach konfigurierbaren Zeitintervallen ausgeführt werden sollte (z. B. bei regelmäßigen Inspektionen; vgl. Abs. [0053] i. V. m. Fig. 5 u. Abs. [0042], [0045], [0054]; Merkmal M9).

Die Änderungen in den Merkmalen M1** und M5*** fügen den übrigen Merkmalen in der Sache nichts hinzu (vgl. Abschnitt II.2).

Da der Fachmann in naheliegender Weise vom Stand der Technik zum Gegenstand des geltenden Patentanspruchs 1 gemäß Hilfsantrag III gelangt, ist auch dieser Anspruch nicht patentfähig.

7. Mit dem jeweils nicht patentfähigen Anspruch 1 nach Hauptantrag und nach den Hilfsanträgen I bis III sind auch die übrigen Ansprüche nicht schutzfähig, da auf diese Ansprüche kein eigenständiges Patentbegehren gerichtet war und über einen Antrag nur einheitlich entschieden werden kann (vgl. BGH, Beschluss vom 27. Juni 2007 – X ZB 6/05, GRUR 2007, 862, Abschnitt III. 3. a) aa) – Informationsübermittlungsverfahren II).

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

III.

Der Antrag der Anmelderin auf Rückzahlung der Beschwerdegebühr nach § 80 Abs. 3 PatG ist zurückzuweisen, weil ein Billigkeitsgrund hierfür nicht besteht.

Die Beschwerdegebühr ist gemäß § 80 Abs. 3 PatG zurückzuzahlen, wenn dies der Billigkeit entspricht. Maßgebend dafür sind alle Umstände des Falles (vgl. Benkard/Schäfers, PatG, 11. Aufl., § 80 Rn. 22; Schulte/Püschel, PatG, 9. Auflage, § 80 Rn. 111, 112). Die Billigkeit kann demnach eine Rückzahlung erfordern, wenn sich die Zurückweisung der Anmeldung als eine unangemessene Sachbehandlung darstellt, die sich beispielsweise aus zumindest einem schwerwiegenden Verfahrensfehler durch das Deutsche Patent- und Markenamt oder aus einer anderweitig unsachgemäßen Behandlung der Sache zu Lasten eines Beteiligten ergibt, und zum anderen, dass aus der Sicht eines verständigen Beschwerdeführers gerade dieser Verfahrensfehler oder diese unsachgemäße Sachbehandlung Anlass für die Einlegung der Beschwerde war (vgl. Benkard/Schäfers, a. a. O; Schulte/Püschel, a. a. O., § 73 Rn. 131 ff., insb. Rn. 132; Busse/Engels, PatG, 8. Aufl., § 80 Rn. 85 ff., insb. Rn. 95; BPatGE 2, 61, 64 ff.; 2, 69, 72 ff., 77; 49, 154, 160 ff.). Eine Ursächlichkeit zwischen Verfahrensverstoß und Beschwerdeeinlegung liegt vor, wenn der Erlass einer anderen, nicht zur Beschwerdeeinlegung zwingenden Entscheidung ohne den Fehler jedenfalls nicht ausgeschlossen werden kann. Die Rückzahlung der Beschwerdegebühr scheidet aber aus, wenn ein verständiger Beschwerdeführer die Beschwerde auch bei ordnungsgemäßer Sachbehandlung eingelegt hätte.

Die Prüfungsstelle hat ausweislich der Amtsakte am 21. September 2012 eine Anhörung durchgeführt und in der Begründung ihres Beschlusses keine Gründe genannt, zu denen die Anmelderin noch keine Stellung nehmen konnte, so dass das rechtliche Gehör gewahrt worden ist (vgl. Schulte/Püschel, a. a. O., § 73 Rn. 142; Benkard, a. a. O., § 80 Rn. 28; Busse/Engels, PatG, a. a. O., § 80 Rn. 100). Auch hat der Prüfer seine Gründe sowohl im Ladungszusatz zur Anhörung als auch im Zurückweisungsbeschluss ausführlich dargelegt. Die von der Anmelderin im Schriftsatz vom 19. Dezember 2012 beanstandete fehlerhafte Nummerierung der relevanten Druckschriften im Abschnitt III. des Zurückweisungsbeschlusses rechtfertigt die beantragte Rückzahlung der Beschwerdegebühr nicht. Denn dem Gesamtzusammenhang des Beschlusses lässt sich zweifelsfrei entnehmen, auf welche Druckschriften sich der Zurückweisungsbeschluss stützt. Daher ist in der Verfahrensführung der Prüfungsstelle kein schwerwiegender Verfahrensfehler, keine unsachgemäße Sachbehandlung und kein Verstoß gegen die Verfahrensökonomie zu sehen, welche eine Rückerstattung der Beschwerdegebühr rechtfertigen würden (vgl. Schulte/Püschel, a. a. O., § 73, Rn. 155). Auch die unsachgemäße Recherche durch die Prüfungsstelle stellt allein kein Grund für die Rückzahlung der Beschwerdegebühr dar (vgl. Schulte/Püschel, a. a. O., § 73 PatG, Rn. 137).

IV.

Rechtsmittelbelehrung Gegen diesen Beschluss steht den 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 Beschlusses beim Bundesgerichtshof, Herrenstr. 45 a, 76133 Karlsruhe, durch einen beim Bundesgerichtshof zugelassenen Rechtsanwalt als Bevollmächtigten schriftlich einzulegen.

Wickborn Kruppa Dr. Schwengelbeck Dr. Flaschke Hu