T 0673/11 (Organisieren von Software/B BRAUN AVITUM) of 15.10.2014

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung vom 7. Oktober 2010, die Anmeldung zu­­rückzuweisen mangels erfinderischer Tätigkeit, Arti­kel 56 EPÜ 1973, gegenüber den Dokumenten

D1: DE 199 53 837 A1 und

D2: US 2003/086107 A1.

II. Am 23. November 2011 legte die Anmeldering Beschwerde ge­gen diese Entscheidung ein und entrichtete die Beschwer­­de­gebühr. Die Beschwerdebegründung ging am 4. Febru­ar 2011 ein. Die Beschwerdeführerin beantragte die Aufhebung der Entscheidung und die Erteilung eines Patents auf der Basis eines zweier Anspruchssätze, die mit der Be­schwerdebegründung eingereicht wurden. Die Beschwerde­führe­rin machte auch eine Verletzung ihres rechtlichen Ge­hörs durch die Prüfungsabteilung geltend.

III. Mit einer Ladung zur mündlichen Verhandlung teilte die Kammer der Beschwerdeführerin ihre vorläufige Meinung mit, dergemäß es der beanspruchten Erfindung gegenüber D1 in Verbindung mit D2 und allgemeinem Fachwissen an einer erfinderischen Tätigkeit mangele, Artikel 56 EPÜ 1973. Die Kammer erhob auch verschiedene Klarheits­ein­wände, Artikel 84 EPÜ 1973.

IV. In Erwiderung auf die Ladung, mit Schreiben vom 11. Au­gust 2014, reichte die Beschwerdeführerin geänderte An­spruchssätze gemäß Haupt- und Hilfsantrag ein, um die Klarheitseinwände der Kammer auszuräumen.

V. Im Verlauf der mündlichen Verhandlung, die am 15. Okto­ber 2014 wie geplant stattfand, legte die Beschwerde­füh­­rerin leicht geänderte Ansprüche 1-14 gemäß Haupt- und Hilfsantrag sowie neue Ansprüche 1-10 gemäß einem zweiten Hilfsantrag vor und be­antragte die Erteilung eines Patents auf dieser Grundlage in Verbindung mit Be­schreibungsseiten 1, 2, 2a und 3-9 wie mit der Be­schwer­debegründung eingereicht und der ursprünglichen Abbildungsseite 1.

VI. Anspruch 1 des Hauptantrags lautet wie folgt.

"Verfahren zum Organisieren der Software eines Fluidmanagementsystems in Form eines medizinischen Behandlungsgeräts, das mindestens ein Prozessorsystem (10) mit CPU (12), Speichereinrichtung und darin gespeicherter Software enthält, dadurch gekennzeichnet

dass die Software unterteilt ist in eine die Patientenbehandlung steuernde, überwachende und dokumentierende Behandlungssoftware (22) und eine die Serviceaktivitäten bei der Wartung des Geräts und/oder Produktionsaktivitäten bei der Herstellung des Geräts steuernde und überwachende Tool-Software (26),

dass in dem Prozessorsystem (10) die Behandlungssoftware als residente, dauerhaft in dem Prozessorsystem installierte Software (22) gespeichert wird, während die Tool-Software als nicht-residente Software (26) auf einem externen Datenspeichergerät (40) außerhalb des Prozessorsystems gespeichert, zur Installation auf das Prozessorsystem übertragen und beim Abschalten der Stromversorgung oder beim Abchalten des Geräts aus dem Prozessorsystem (10) gelöscht wird."

Anspruch 1 des ersten Hilfsantrags entspricht dem des Hauptantrags, ergänzt um das folgende Merkmal:

"..., und dass die Tool-Software in Teilfunktionen wir Softwareupdate, Serviceunterstützung, Produktionsunterstützung unterteilt ist, wobei der von der Tool-Software benutzte Speicherplatz in dem Prozessorsystem nur die Größe einer Teilfunktion hat."

Anspruch 1 des zweiten Hilfsantrags entspricht dem des ersten Hilfsantrags, ergänzt um das weitere Merkmal

", und dass ein Update der Tool-Software in dem externen Datenspeichergerät (40) außerhalb des Prozessorsystems (10) durchgeführt wird."

Haupt- und erster Hilfsantrag umfassen einen zweiten un­abhängigen Anspruch 11, der auf eine "Patienten­be­hand­lungsmaschine" gerichtet ist und dessen Wortlaut dem jeweiligen Verfahrensanspruch 1 eng entspricht. Der zweite Hilfsantrag enthält einen solchen Anspruch nicht.

VII. Am Ende der Verhandlung verkündete der Vorsitzende die Entscheidung der Kammer.

Entscheidungsgründe

Keine Verletzung des rechtlichen Gehörs

1. Die Beschwerdeführerin bezieht sich auf ihre Aus­füh­rungen vom 14. Dezember 2009, in der sie dargelegt habe, dass und warum es sich bei der Unterteilung in Be­handlungssoftware und Tool-Software um technische Merk­male handele, und bringt vor, die Prüfungsabteilung ha­be dieses Argument nicht zur Kenntnis genommen und da­mit der Anmelderin/Beschwerdeführerin das rechtliche Ge­hör versagt (Beschwerdebegründung, Punkt 4). Die Prü­fungsabteilung habe insbesondere die Eigenarten der beiden Arten von Software ignoriert und dadurch "die Technizität der beiden unterschiedlichen Module (ohne nähere Begründung) in Abrede gestellt" (Punkte 6).

2. Die Kammer kann den Ausführungen der Beschwerdeführerin nicht folgen. Zwar setzt sich die Entscheidung nicht explizit mit der Argumentation der Beschwerde­führerin hinsichtlich Technizität auseinander, stellt sie aber auch nicht in Frage: Vielmehr wird ausdrück­lich einge­räumt, dass "diese beiden Programme eine tech­­­nische Natur haben" (Gründe 4.1). Die Prüfungsabteilung stellt aber fest, dass "keine weiteren Merkmale" zu diesen Programmen definiert seien und kommt daher zu dem Schluss, dass diese als "fachübliche Programme" (ebd.) zu betrachten seien. Die Kammer ver­steht dieses Argu­ment so, dass nach Ansicht der Prü­fungs­abteilung die tatsächlichen oder möglichen tech­ni­sche Unterschie­de zwischen den beanspruchten Programmen und den aus D2 be­kannten mangels technischer Details für die Bewertung der erfinderischen Tätigkeit nicht von Bedeutung seien. Die Kammer kann daher nicht er­kennen, dass die Prü­fungs­abteilung die Argumente der Beschwer­de­führerin ignoriert und damit deren rechtliches Gehör (Artikel 113 (1) EPÜ 1973) verletzt hätte. Damit weist das Verfahren vor der ersten Instanz keine Mängel auf und die Anwendung des Artikels 11 VOBK scheidet aus.

Die Erfindung

3. Die Anmeldung bezieht sich auf ein Fluid­ma­nage­­ment­system in Form eines "medizinischen Behandlungs­geräts" zur Durchführung beispielsweise einer Hämodialyse (ur­sprüngliche Beschreibung, S. 1, letzter Abs.).

3.1 Solche Geräte unterlägen hohen Anforderungen an Zu­ver­lässigkeit und Genauigkeit" und "daher" sei die ver­wen­dete Software "sehr komplex". Man könne dabei zwischen "Behandlungssoftware" und "Tool-Software" unter­scheiden (S. 2, Zn. 3-5), wobei jene solche Pro­gramme umfasse, "de­nen der Patient ausgesetzt ist", und diese "Service- und Produktionsprogramme" (Zn. 5-7). Konkrete Details über diese beide Arten von Software enthält die Anmel­dung nicht, wie auch die Beschreibung die Unterteilung nur als "grob" bezeichnet (loc. cit.).

3.2 Die Anmeldung offenbart, dass beide Arten von Pro­grammen Up­dates benötigen, die Behandlungssoftware jedoch sel­te­ner als die Tool-Software (S. 2, Zn. 7-10; S. 3, 2. Abs. und letzter ganzer Satz). Gleichzeitig wird offen­bart, dass der Speicherplatzbedarf in einem Fluidma­nage­mentsystem sehr hoch ist (S. 2, letzter gan­zer Satz), von dem etwa 20% für die Bedienungssoft­ware und etwa 80% für die Tool-Software benötigt werden (S. 3, letzter Abs.). Die Anmeldung stellt sich die Auf­gabe, das "Verwalten und Updaten" der Software zu vereinfachen (S. 3, 3. Absatz).

3.3 Als Lösung schlägt die Anmeldung vor, "nur die Behand­lungssoftware als residente Software" zu übernehmen, "während die Tool-Software außerhalb des Prozessor­sys­tems abgespeichert wird" (Satz zwischen S. 3 und S. 4). Dabei wird "residente Software" als solche defi­niert, die "dauerhaft installiert" ist, "während nicht resi­den­te Software [z. B.] beim Abschalten der Stromversor­gung" gelöscht wird (S. 4, 2. Abs., 1. Satz). Auf diese Weise, sei es möglich, ein Update der Tool-Software vor­zunehmen, ohne das Prozessorsystem der Patientenbe­hand­­lungs­maschine zu blockieren, so dass dieses für die Patientenbehandlung benutzt werden könne (S. 4, letzte fünf Zeilen - S. 5, Z. 2).

Stand der Technik

4. D1 offenbart ein medizinisches Gerät, z. B. ein extra­kor­porales Blutbehandlungsgerät wie eine Dialyse­ma­schi­ne (Sp. 2, Zn. 9-11; Sp. 4, Zn. 30-34) und damit ein Fluidmanagementsystem wie beansprucht.

4.1 Das Gerät aus D1 ist modular aufgebaut und seine Hard­warekonfiguration kann so flexibel gestaltet werden (Sp. 1, Zn. 11-28). Die Einzelkomponenten sind als un­ter­schiedliche "Prozessorsysteme" ausgestaltet, in de­ren Speicher die jeweils benötigte Software abgelegt ist (Sp. 1, Zn. 33- 35). Wenn ein Update der Software ansteht, wird die Aktualisierungs-Software auf einem externen Datenträger bereitgestellt, sei es eine CD oder ein Laptop (Sp. 2, Zn. 38-44 und 65-67). Im Gerät ist ein "Er­kennungssystem" vorgesehen, das ermittelt, wel­che Software­programme in einem konkreten System und zum gegebenen Zeitpunkt zu la­den sind (Sp. 2, Zn. 23-33): Dabei wird sowohl die individuelle Hard­warekonfiguration berücksichtigt (Zn. 34-37) als auch, welche der relevanten Software veraltet ist und ein Update benötigt (Sp. 3, Zn. 14-21).

4.2 Nach dem Verständnis der Kammer ist gemäß D1 die Soft­ware des Behandlungsgeräts ebenso wie die Er­kennungs­­software "resident" im Sinne der Ansprüche. Ei­ne Unter­scheidung in Behandlungssoftware und Tool-Soft­ware wird in D1 nicht getroffen, wenngleich einer­seits natürlich eine "Behandlungssoftware" vorliegen muss, und anderer­seits die "Erkennungssoftware" als ein für den "Soft­ware­update" benötigtes "Tool" angesehen werden kann und weitere Funktionen genannt werden, die "Tool"-Charakter haben (Messung, Überwachung, Fehler­be­hand­lung; Sp. 1, Z. 16-17 und 26).

Erfinderische Tätigkeit

Hauptantrag

5. Die Entscheidung und die Beschwerdeführern gehen bei der Analyse der erfinderischen Tätigkeit von D1 aus. Die Kammer schließt sich dieser Wahl an.

6. Anspruch 1 des Hauptantrags unterscheidet sich von D1 dadurch, dass

a) zwischen Behandlungs- und Tool-Software explizit unterschieden wird, und dass

b) Behandlungssoftware "als residente, dauerhaft in dem Prozessorsystem [des Fluidmanagementsystems] installierte Software" gespeichert wird, während die Tool-Software "als nicht-residente Software -s außerhalb des Prozessorsystems gespeichert" und nur bei Bedarf vorübergehend "auf das Prozessor­system übertragen" wird.

7. Ad a) Die Kammer versteht die Anmeldung dahingehend, dass die beschriebene Software in den einschlägigen Geräten im Grunde bekannt war, dass also diese Geräte zum Prioritätszeitpunkt neben "Behandlungsprogramme[n]" auch schon "Service-" und "Produktionsprogramme" auf­wie­sen (S. 2, Zn. 5-7; S. 3, 2. und 5. Abs.). Die Be­schwerdeführerin hat diese Ansicht der Kammer nicht bestritten. Ob es zu diesem Zeitpunkt auch bekannt war, die Behandlungssoftware begrifflich von der "Tool-Soft­ware" zu unterscheiden, geht zwar aus der Anmeldung nicht hervor, kann aber auch dahin stehen: Eine Unter­scheidung nämlich zwischen der medizinischen Primär­funktion des Behandlungsgeräts, der "Behandlung", und Sekundärfunktionen wie etwa Produktion und Wartung, er­gibt sich nach der Überzeugung der Kammer für den Fach­mann zwanglos. Die Kammer hält es auch für un­mittel­bar naheliegend, dass in einem modularen System wie dem gemäß D1 für jede Softwarekomponente (wenig­stens grob) festgestellt werden kann, ob sie eine Be­handlungs­funk­tion realisiert oder nicht. Damit zer­fällt die Software aus D1 unmittelbar in Behand­lungs­- und Tool-Software. Es kann somit auch offen bleiben, wel­chen technischen Beitrag diese Unter­schei­dung ggfs. zur beanspruchten Er­findung leistet.

8. Ad b) Die Kammer ist der Meinung, dass dem Unter­schieds­merkmal b) im Kern das Problem zugrunde liegt, eine kostengünstige aber praktikable Speicheraus­stattung eines Fluidmanagementsystems zu bestimmen. Der einschlägige Fachmann in diesem Zusammenhang ist ein Computerspezialist und nicht etwa ein medizinischer Experte auf dem Gebiet der Dialyse oder ein Medizin­techniker mit eingehenden Kenntnissen über Dialysege­räte oder dergleichen.

8.1 Die Kammer ist weiter der Meinung, dass bei der Kon­zep­tion und Ausführung von technischen Geräten eine Be­trachtung und Abwägung von Kosten zum fachüblichen Han­deln gehört. Das gilt insbesondere auch für die Frage, wie groß der Arbeitsspeicher in einem solchen Gerät auszulegen ist.

8.2 Es ist für den Fachmann offenkundig, dass unter­schied­liche Anforderungen an die Verfügbarkeit der ver­schie­de­nen Softwarekomponenten gestellt werden. Ins­be­sondere muss die Behandlungssoftware im Betrieb des Fluidma­nage­mentsystems im wesentlichen ständig ver­fügbar sein, während "Produktionsprogramme" nur in der Pro­duktions­phase und "Serviceprogramme" nur zu den War­tungszeit­punkten in der Betriebsphase verfügbar sein müssen.

8.3 Daraus erkennt der Fachmann nach Ansicht der Kammer un­mittelbar, dass es nach Abschluss der Produktions­phase keinen Grund mehr gibt, die Produktionsprogramme noch im Arbeitsspeicher des Geräts zu belassen, und dass der von den Produktionsprogrammen belegte Arbeits­speicher ohne Nachteile für die Gerä­te­funktion für an­de­re Pro­gramme verwendet werden kann. Wie er­wähnt, hält die Kammer solche Überlegungen für ohne Wei­­teres fach­üb­lich. Für D1 gilt das in besonderem Maße deshalb, weil in D1 sämtliche Software im nicht-flüch­tigen Speicher vorgehalten wird und nicht-flüchtiges RAM (wie etwa Flash) als vergleichsweise teuer bekannt ist (vgl. D2, Abs. 0006).

8.4 Die Kammer ist daher der Meinung, dass es für den Fach­mann naheliegen würde, die nicht für die Primär­funk­tion des Fluidmanagementsystems aus D1 notwendige Soft­ware etwa aus Kostengründen auf einen externen Speicher "aus­zulagern" und nur bei Bedarf und nur vorübergehend in günstiges, flüchtiges RAM zu laden und dort auszu­führen.

9. Gegen diese Analyse der Kammer wandte die Beschwerde­füh­rerin ein, der Erfindung liege eine andere objektive Aufgabe zugrunde, nämlich die Sicherheit der Patienten­behandlung beim Ausführen einer Behandlungssoftware zu erhöhen (vgl. Schreiben vom 11. August 2014, S. 3, 3. Abs.). Dieses Problem gehe aus der Beschreibung hervor, die schon gleich zu Beginn (S. 2, 1. Abs.) die hohen An­for­de­rungen an Zuverlässigkeit und Genauigkeit von Fluid­ma­nagementsystemen benenne und mit der Software­struk­tur und -komplexität in Beziehung setze. Die Un­ter­­scheidung und getrennte Handhabung von Behandlungs­software und Tool-Software führe dazu, dass beide nicht zum Nachteil der Patientensicherheit mitei­nan­der in Kon­flikt geraten könnten.

9.1 Die Kammer bezweifelt, dass die angegebene Stelle in der Beschreibung (S. 2, 1. Abs.) die zweifellos hohen Sicherheitsanforderungen mit der beanspruchten Erfin­dung in Beziehung setzt und weist darauf hin, dass die Beschreibung ein Sicherheitsproblem nirgendwo ausdrück­lich diskutiert. Allenfalls die offenbarte Tatsache (Satz zwischen S. 4 und 5), dass die Erfindung ein Up­date der Tool-Software möglich macht, ohne das Fluid­ma­nagementsystem nicht zu blockieren, und die so er­höh­te Verfügbarkeit des Systems kann als Sicherheits­as­pekt an­gesehen werden.

9.2 Es mag aber dahin stehen, ob die Erfindung auch unter Sicherheitsaspekten vorteilhaft ist. Die Kammer hat oben einen Weg dargestellt, auf dem der Fachmann in realistischer Weise und ohne dabei erfinderisch tätig zu werden zur Erfindung gelangt wäre, ohne sich dabei ein­em Sicherheitsproblem widmen zu müssen. Diese Dar­stellung kann nicht dadurch erfolgreich bestritten wer­den, dass auf einen weiteren und gegebenenfalls weniger offensichtlichen Vorteil der so erhaltenen Lösung ver­wiesen wird.

10. Die Anmeldung nennt eine dritte Aufgabe ausdrücklich, nämlich "die Verwaltung und das Updaten der Software eines Prozessorsystems [zu] vereinfach[en]" (S. 3, 3. Abs.). Die Kammer bestreitet nicht, dass es von Vorteil sein mag, die Tool-Software "außerhalb" des medizi­ni­schen Geräts aktualisieren zu können. Aber auch in die­ser Hinsicht gilt das eben Gesagte: Wenn der Fachmann ohne erfinderisches Zutun zur Erfindung schon als Lö­sung einer Aufgabe gelangt wäre, dann muss die Er­fin­dung als naheliegend gelten, selbst wenn sie zusätzlich auch eine andere Aufgabe lösen sollte. Wenn, wie die Kammer meint, die Erfindung schon die Aufgabe löst, eine kostengünstige und praktikable Speicher­ausstattung des Behandlungsgeräts zu bestimmen, dann muss die Erfin­dung als naheliegend gelten, selbst wenn sie auch für "die Verwaltung und das Updaten der Software" von Vorteil sein sollte.

11. Schließlich brachte die Beschwerdeführerin vor, dass der Fachmann, sollte er sich denn dafür entscheiden, die Tool-Software aus Kostengründen nicht im residenten Speicher des Behandlungsgeräts zu in­stallieren, sie auch zur Ausführung nicht im Gerät in­stallieren sondern nach Abruf ein­schlä­giger Ge­rä­te­pa­rameter außerhalb des Behandlungsgeräts aus­füh­ren wür­de, wie es etwa bei KFZ-Diagnose­geräten der Fall sei.

11.1 Die Kammer räumt ein, dass es denkbar, ausreichend und unter Umständen sogar vorteilhaft sein könnte, be­stimm­te "Tool"-Software außerhalb des Behandlungsgeräts aus­zu­führen. Gleichzeitig könnte es aber auch vorteil­haft oder sogar notwendig sein, ein bestimmtes Soft­ware­tool im medizinischen Gerät auszuführen, wenn die­ses bei­spiels­weise direkten Zugriff auf interne Geräte­kompo­nen­ten benötige. Ob der Fachmann das eine oder das an­dere für naheliegender halten würde, hängt nach An­sicht der Kammer von Details über die technische Aus­stattung des medizinischen Geräts und die Erforder­nisse der Tools ab, die weder die Ansprüche noch die Anmel­dung offenbaren, und ist daher für die vorliegende Entschei­dung nicht von Bedeutung. Im allgemeinen jedoch hält die Kammer die Ausführung der Tool-Software innerhalb oder außer­halb des medizinischen Geräts für gleicher­maßen nahe­lie­gend.

12. Die Kammer kommt somit zu dem Schluss, dass es der be­anspruchten Erfindung gegenüber D1 im Lichte seines allgemeinen Fachwissens an einer erfinderischen Tätig­keit mangelt, Artikel 56 EPÜ 1973.

1. Hilfsantrag

13. Die voranstehende Analyse des Hauptantrags geht davon aus, dass es für den Fachmann naheliegend wäre, einen Teil der Gerätesoftware aus dem internen Speicher zu entfernen, wenn er nicht mehr gebraucht wird. Konkret hält die Kammer es beispielsweise für naheliegend, nach Ab­schluss der Produktionsphase die Produktionsprogramme zu löschen. Ebenso naheliegend wäre es für den Fach­mann, den so frei werdenden Speicher für andere Soft­ware-"Tools" zu nutzen, etwa für Serviceprogramme in der Wartung. Dass der vorgehaltene Speicher in einem solchen Fall nur so groß sein muss wie die größere der nachein­ander (oder alternativ zueinander) verwendeten Soft­ware-Tools, ist nach Ansicht der Kammer ohne Wei­teres naheliegend. Der Fachmann würde daher den nicht-residenten Speicher aufgrund elementarer Kostenüber­le­gungen auf die "Größe einer Teilfunktion" wie bean­sprucht beschränken, ohne dabei erfinderisch tätig zu werden. Auch der Gegenstand von Anspruch 1 des ersten Hilfsantrags weist daher nicht die erforderliche er­fin­derische Tätigkeit auf, Artikel 56 EPÜ 1973.

2. Hilfsantrag

14. Die Analyse des Hauptantrags kommt zu dem Ergebnis, dass es für den Fachmann naheliegend wäre, die Tool-Soft­ware nicht dauerhaft im Speicher des medizinischen Geräts zu installieren, sondern sie nur zur Ausführung vorübergehend in diesen Speicher zu laden. Offenbar muss zu diesem Zweck die Tool-Software außerhalb des Geräts dauerhaft gespeichert sein.

14.1 Unter diesen Umständen ist die Kammer der Meinung, dass es nur natürlich wäre, die Software auch außerhalb des medizinischen Geräts zu aktualisieren.

14.2 In D1 ist offenbart, dass die "gesamte Aktualisierungs-Software" nicht nur auf einem externen Datenträger wie einer CD gespeichert sein kann, sondern auch auf einem externen "Datenspeichergerät" mit eigenem Prozessor wie etwa einem Laptop (Sp. 2, Zn. 65-67).

14.3 Der Fachmann würde es nach Ansicht der Kammer als nahe­lie­gend ansehen, auch die extern ge­spei­cherte Tool-Soft­ware auf dem externen Datenspei­chergerät abzule­gen und die Aktualisierung dieser Soft­ware "an Ort und Stelle" auf diesem Gerät durchzufüh­ren.

14.4 Auch der Gegenstand von Anspruch 1 des zweiten Hilfs­antrags weist daher nicht die erforderliche erfin­de­rische Tätigkeit auf, Artikel 56 EPÜ 1973.

Entscheidungsformel

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.