T 1805/07 (Softwareverifikation/BOSCH) of 15.6.2011

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, verkündet in der mündlichen Verhand lung am 19. Juni 2007 und zugestellt mit Schreiben vom 2. Juli 2007, mit der die Patentanmeldung mit der Num mer 02 760 105.3 zurückgewiesen wurde. Der Gegenstand von Anspruch 1 des einzigen Antrags wurde als nicht erfinderisch erachtet über die Kombination der Dokumente:

D1 K. Oertel: "Code per Klick - Von der Idee zum fertigen Produkt mit ASCET-SD 3.0", Elektronik Industrie, April 1999, Seiten 95-96, XP2262103.

D2 D. Hoffman: "A Taxonomy of Test Oracles", Internet-Artikel, 16. Januar 1998, Seiten 1-4, XP2262104, gefunden im Internet: <URL:http:/fsoftwarequalitymethods.com/SQM/Abstracts/ATaxonomyabstract.PDF> [gefunden am 19. November 2003].

II. Beschwerde wurde am 16. August 2007 eingelegt. Die Gebühr wurde am selben Tag entrichtet. Die Begründung ist am 25. September 2007 eingegangen. Anbei wurde der Anspruchssatz des aktuellen Hauptantrags eingereicht.

III. In einer Ladung zur mündlichen Verhandlung teilte die Kammer dem Beschwerdeführer ihre vorläufige Meinung mit, wonach die Entscheidung zu bestätigen sei. Zu dem in Anspruch 1 des Hauptantrags hinzugefügten Merkmal der Bestimmung der Softwarecodeabdeckung wurde folgendes Dokument aus dem Prüfungsverfahren angeführt:

D3 B. Milne: "Entry-level system integrates microprocessor development tools", Electronic Design, Penton Publishing, Cleveland, OH, USA, Bd. 36, Nr. 2, 21. Januar 1988, Seiten 43-44, 46, 48, XP112094.

IV. In einem Schreiben, eingegangen am 16. Mai 2011, wurden neue Anspruchssätze der drei Hilfsanträge ohne Argumente eingereicht.

V. In einem Schreiben, eingegangen am 8. Juni 2011, wurde eine Argumentationslinie für den Hauptantrag mitgeteilt.

VI. Am 15. Juni 2011 fand die mündliche Verhandlung statt, in welcher der Beschwerdeführer das folgende Dokument einführte:

D5 Robert Bosch GmbH: "DS Software Life Cycle Model"; Papierausdruck von Vortragsfolien; 17. Januar 2005; Seiten 11 und 12.

Dieses Dokument solle laut Beschwerdeführer nur das Hintergrundwissen erläu tern; es stelle keinen Stand der Technik dar.

VII. Der Beschwerdeführer beantragt, die angefochtene Ent scheidung aufzuheben und ein Patent zu erteilen auf der Basis des Hauptantrags (Ansprüche 1-9) oder alternativ auf Basis der Hilfsanträge 1-3 (jeweils mit Anspruch 1 und weiteren Ansprüchen aus dem Hauptantrag angepasst übernommen), als Beschreibung Seite 1 eingegangen am 25. Mai 2006, und Seiten 2-15 wie veröffentlicht, und als Zeichnung die Blätter 1-3 wie veröffentlicht.

VIII. Anspruch 1 des Hauptantrags lautet wie folgt (Kursiv schrift hinzugefügt zum Markieren der Unterschiede zum erstinstanzlich zurückgewiesenen Antrag): "Verfahren zur Verifikation von Softwarefunktionen für eine Steuereinheit, mit Verwendung eines Simulations modells zur Abbildung der Softwarefunktionen und der Steuereinheit, dadurch gekennzeichnet, dass aus dem identischen Simulationsmodell zum einen für eine erste Experimentalsteuereinheit und zum zweiten für eine zwei te Seriensteuereinheit der Softwarecode für die Soft ware funktionen automatisch generiert wird, wobei die Experimentalsteuereinheit einen Zugriff auf das Verhalten der Softwarefunktion ermöglicht, wobei identische Eingangsgrößen für die Softwarefunktionen auf beiden Steuergeräten zum Einsatz kommen und die sich daraus ergebenden Ausgangsgrößen beider Steuereinheiten zeit synchron erfasst werden, wobei durch Vergleich der Aus gangs größen beider Steuereinheiten die Software funktionen verifiziert werden, und dass zusätzlich bei der Verifikation die durchlaufenen Pfade im Softwarecode und/oder in den Softwarefunktionen zur Bestimmung der Softwarecodeabdeckung auf der Experimentalsteuereinheit erfasst werden."

IX. Anspruch 1 des Hilfsantrags 1 lautet wie folgt (Kursiv schrift hinzugefügt zum Markieren der Unterschiede zum Hauptantrag): "Verfahren zur Verifikation von Softwarefunktionen für eine Steuereinheit, mit Verwendung eines Simulations modells zur Abbildung der Softwarefunktionen und der Steuereinheit, wobei aus dem identischen Simulations modell zum einen für eine erste Experimental steuer einheit und zum zweiten für eine zweite Seriensteuer einheit Softwarecode für die Softwarefunktionen auto matisch generiert wird, dadurch gekennzeichnet, dass der Softwarecode für die Softwarefunktionen jeweils für Experimentalsteuereinheit oder Seriensteuereinheit mit unterschiedlichen Erzeugungsmitteln generiert wird, wobei die Experimentalsteuereinheit einen Zugriff auf das Verhalten der Softwarefunktion ermöglicht, wobei identische Eingangsgrößen für die Softwarefunktionen auf beiden Steuergeräten zum Einsatz kommen und die sich daraus ergebenden Ausgangsgrößen beider Steuereinheiten zeitsynchron erfasst werden, wobei durch Vergleich der Ausgangsgrößen beider Steuereinheiten die Software funktionen verifiziert werden, und dass zusätzlich bei der Verifikation die durchlaufenen Pfade im Softwarecode und/oder in den Softwarefunktionen zur Bestimmung der Softwarecodeabdeckung auf der Experimentalsteuereinheit erfasst werden."

X. Anspruch 1 des Hilfsantrags 2 lautet wie folgt (Kursiv schrift hinzugefügt zum Markieren der Unterschiede zum Hilfsantrag 1): "Verfahren zur Verifikation von Softwarefunktionen für eine Steuereinheit, mit Verwendung eines Simulations modells zur Abbildung der Softwarefunktionen und der Steuereinheit, wobei aus einem identischen Simulations modell zum einen für eine erste Experimentalsteuer einheit und zum zweiten für eine zweite Seriensteuer einheit Softwarecode für die Softwarefunktionen automa tisch generiert wird, wobei die Experimentalsteuer einheit einen Zugriff auf das Verhalten der Software funktion ermöglicht, dadurch gekennzeichnet, dass der Softwarecode für die Softwarefunktionen jeweils für Experimentalsteuereinheit oder Seriensteuereinheit mit unterschiedlichen Erzeugungsmitteln generiert wird, wobei der Softwarecode in hardwareabhängigen Software code und hardwareunabhängigen Softwarecode unterteilt ist, wobei identische Eingangsgrößen für die Software funktionen auf beiden Steuergeräten zum Einsatz kommen und die sich daraus ergebenden Ausgangsgrößen beider Steuer einheiten zeitsynchron erfasst werden, wobei durch Vergleich der Ausgangsgrößen beider Steuereinheiten die Softwarefunktionen verifiziert werden, und dass zusätz lich bei der Verifikation die durchlaufenen Pfade im Softwarecode und/oder in den Softwarefunktionen zur Bestimmung der Softwarecodeabdeckung auf der Experi mental steuereinheit erfasst werden."

XI. Anspruch 1 des Hilfsantrags 3 lautet wie folgt (Kursiv schrift hinzugefügt zum Markieren der Unterschiede zum Hilfsantrag 2): "Verfahren zur Verifikation von Softwarefunktionen für eine Steuereinheit, mit Verwendung eines Simulations modells zur Abbildung von Softwarefunktionen und der Steuereinheit, dadurch gekennzeichnet, dass aus dem Simulationsmodell mit unterschiedlichen Erzeugungs mitteln hardwareabhängige Software für eine Experi mental steuer einheit und eine Seriensteuereinheit generiert wird, wobei die Experimentalsteuereinheit einen Zugriff auf das Verhalten der Softwarefunktion ermög licht, wobei hierdurch eine Softwarecodeabdeckung auf der Experimentalsteuereinheit ermittelt werden kann, wobei zur Verifikation des Zeitverhaltens der Serien steuereinheit während eines Funktionstests identische Eingangsgrößen für die Steuereinheiten verwendet werden und die Ausganggrößen der Steuereinheiten zeitsynchron erfasst und verglichen werden."

XII. Am Ende der mündlichen Verhandlung verkündete der Vorsitzende die Entscheidung der Kammer.

Entscheidungsgründe

1. Zulässigkeit der Beschwerde Die Beschwerde ist zulässig, siehe obige Abschnitte I und II.

2. Zulässigkeit der Anträge und ursprüngliche Offenbarung

2.1 Anspruch 1 des Hilfsantrags 1 bzw. 2 enthält zusätzlich zu Anspruch 1 des Hauptantrags die Merkmale des abhängi gen Anspruchs 3 bzw. der Ansprüche 3 und 6 des Haupt antrags. Sie stellen zudem nach Ansicht der Kammer einen ernsthaften Versuch dar, die erhobenen Einwände zu beheben. Daher werden die Hilfsanträge 1 und 2 zum Verfahren zugelassen.

2.2 Hilfsantrag 3 unterscheidet sich von den vorhergehenden Anträgen durch eine sehr starke Umformulierung des kennzeichnenden Teils. Dabei wurden unter anderem die Adjektive "identisch" (vor "Simulationsmodell" in Zeile 3 von Anspruch 1 des Hauptantrags) und "automatisch" (vor "generiert" in Zeile 6) gelöscht. Außerdem wurde der Ausdruck "zur Verifikation des Zeitverhaltens" hinzugefügt.

2.2.1 Die im Schreiben vom 16. Mai 2011 angegebenen Beschrei bungs passagen enthalten nichts, das als Basis für diese Änderungen infrage käme. Auch in der mündlichen Verhand lung wurde keine Basis angegeben, insbesondere nicht für eine Offenbarung der Verifikation des Zeitverhaltens. Selbst in der von der Kammer angeführten Passage auf Seite 10, Absatz 3, Zeilen 3-8 wird nur eine Spezifi kation und Simulation des Zeitverhaltens offenbart, nicht eine Verifikation. Nach Auffassung der Kammer stellt die Simulation des Zeitverhaltens eine Voraus setzung des zeitsynchronen Ausgabevergleichs dar. Das Zeitverhalten selbst ist aber nicht Gegenstand der Verifikation. Der Beschwerdeführer charakterisierte überdies in der mündlichen Verhandlung die sehr starke Umformulierung des Hilfsantrags 3 als Klarstellung, die bzgl. der erfinderischen Tätigkeit nichts hinzufügen möchte.

2.2.2 Im Lichte dieser Erwägungen übt die Kammer ihr Ermessen aus, Hilfsantrag 3 gemäß Artikel 13(1) der Verfahrens ordnung der Beschwer dekammern (VOBK) nicht zum Verfahren zuzulassen.

3. Erfinderische Tätigkeit von Anspruch 1

3.1 Hauptantrag

3.1.1 Dokument D1 wird wie im gesamten bisherigen Verfahren als nächstliegender Stand der Technik angesehen. Das darin beschriebene Entwicklungs system ASCET-SD der Fa. ETAS wird auch in der Beschreibung mehrmals erwähnt.

3.1.2 Der erstinstanzlich zurückgewiesene Anspruch 1 unter schei det sich - zusammengefasst ausgedrückt - von D1 durch einen "synchronen Ausgabevergleich": d.h. iden tische Eingangsgrößen werden beiden Steuergeräten einge geben, und die sich daraus ergebenden Ausgaben werden syn chron erfasst und verglichen. Dies wurde vom Beschwerdeführer nicht bestritten.

3.1.3 In der angefochtenen Entscheidung wird der synchrone Ausgabenvergleich aus D2 herausgelesen und mit dem Ver fah ren aus D1 kombiniert. Die Experimental steuereinheit des Anspruchs wird mit dem Test-Orakel aus D2 identi fi ziert.

In der Beschwerdebegründung wird auf Seite 2, letzter Satz eingeräumt, dass in D2, Seite 3 beschrieben wird, dass "reales System und Oracle parallel betrieben werden können".

3.1.4 Im Schreiben vom 8. Juni 2011, Seite 4 und in der mündlichen Verhandlung argumentiert der Beschwerde führer, dass die Integration des Test-Orakels aus D2 in das Verfahren aus D1 einen unterschiedlichen Algo rith mus für die Ermittlung der erwarteten Ausgabe auf der Experimental steuer einheit erfordern würde, d.h. einen anderen als den in der Serien steuer einheit benutzten. Die Aussagekraft der Tests sei gemäß D2 umso größer, je weniger das Test-Orakel mit der zu testenden Funktion gemeinsam hätte. Deshalb würde der Fachmann einen ande ren Algorithmus wählen. Außerdem spreche D2 von der "function under test (FUT)" (siehe D2, Seite 2, Abschnitt 1). Dies zeige, dass es in D2 um einen Funktions-Test gehe, im Gegensatz zum System-Test der Anmeldung. Siehe dazu auch das während der mündlichen Verhandlung eingereichte Dokument D5. Darin werde der Funktions-Test "Unit Test" genannt und wurde von hand mit "FUT" markiert, während der System-Test mit "SUT" ("system under test") gekennzeichnet wurde. Ein weiterer Unterschied von D2 zum Anspruch sei, dass ein Orakel eine Spezifikation der Testfälle erfordere, die alle erwarteten Ausgangsgrößen in Abhängigkeit der Eingangsgrößen abdeckten. (Schreiben vom 8. Juni 2011, Seite 4, Absatz 2).

3.1.5 Diese Interpretation von D2 ist jedoch eine verengte Dar stellung. Zum einen offenbart D2 in der Aufzählung auf Seite 1 die unterschiedlichsten Arten von Test-Orakel. So wird als Punkt 6 folgende Methode aufgeführt, um erwartete Ergebnisse zu erzeugen:

"• Same version of software on a different hardware platform"

Das ist also ein mögliches Test-Orakel (zu dessen Definition siehe Seite 1, Abschnitt 2 "Background:", Zeilen 1 und 4). Dieses Test-Orakel ist offensichtlich so zu verstehen, dass der gleiche Programmtext (mit identischer Versionsnummer) genommen wird und aus ihm für eine andere Hardware-Plattform aus führ barer Code als konkretes Test-Orakel erzeugt wird. Dies bedeutet, dass nicht nur kein unterschiedlicher Algorithmus als Test-Orakel genommen werden muss, sondern sogar vorgeschlagen wird, diese Implementierung des Algorithmus, also den gleichen Programmtext dafür zu nehmen. Ebenso verlangt es der Anspruch ab Zeile 3:

"dass aus dem identischen Simulationsmodell zum einen für eine erste Experimentalsteuereinheit und zum zweiten für eine zweite Seriensteuereinheit der Softwarecode ... automatisch generiert wird"

3.1.6 Es ist außerdem klar, dass für diese Variante die Testfälle keineswegs spe zi fiziert werden müssen.

3.1.7 Zum andern spricht D2 in der Tat von einer "function under test", aber D2 thematisiert gar nicht den Moment im Software-Lebenszyklus, zu welchem getestet wird. So sagt D2 nicht, ob das Orakel für einen "Unit Test", "Integration Test" oder "System Test" verwendet wird, sondern erläutert nur, was gegeneinander getestet werden kann.

3.1.8 Daher würde es ein Fachmann als offensichtlich ansehen, das Merkmal des synchronen Ausgabenvergleichs aus D2 in das Verfahren von D1 zu integrieren, um die in der angefochtenen Entscheidung angegebene technische Aufgabe zu lösen, nämlich (siehe Abschnitt II, 1c)):

"Wie kann die Korrektheit der Software eines Seriensteuergeräts getestet werden, wenn ein funktionierendes Referenzsystem vorliegt."

3.1.9 Der aktuelle Anspruch 1 enthält gegenüber dem erstin stanz lich zurückgewiesenen zwei zusätzliche Merkmale:

• die Ermöglichung des Zugriffs auf das Verhalten der Softwarefunktion durch die Experimentalsteuereinheit und

• die Erfassung der Codeabdeckung der durchlaufenen Pfade im Softwarecode und/oder in den Software funktionen (aus dem ursprünglichen Anspruch 4).

3.1.10 Auch diese beiden Merkmale vermögen indessen nicht, die erfinderische Tätigkeit herzustellen. Zum einen ist der Zugriff auf das Software-Verhalten durch die Experi mentalsteuereinheit ebenfalls in D1 offenbart, und zwar auf Seite 95, linke Spalte, Zeile 14 (Kursivschrift hinzugefügt): "... das sogenannte zielsystem-identische Prototyping eingeführt. Dabei kann die gesamte Arith me tik und das Zeitverhalten auf dem Entwick lungs system spezifiziert, simuliert und mit großer Genauig keit aus ge geben werden.", und Zeile 25: "Mit ASCET-SD lässt sich das Verhalten von Software realistisch untersuchen. Das bedeutet, dass das Echtzeitverhalten des Produkts nicht simuliert, sondern ausgeführt wird. Das Verhalten ist somit zielsystem-identisch und das Zeitverhalten der Applikation verifizierbar.".

3.1.11 Zum andern findet sich das zweite neu hinzugefügte Merkmal, also die Erfassung der Codeabdeckung, zwar weder in D1 noch in D2, aber - wie im Internationalen Vorläufigen Prüfungsbericht, Abschnitt 2.3 zum ursprünglichen Anspruch 4 gesagt - in Dokument D3. Darüberhinaus wird es als eine jedem Fachmann geläufige Methode angesehen, um ausreichendes Testen sicherzustellen. Die Anmeldung selbst bezeichnet die Codeabdeckungs analyse als "etablierte Testtechnologie" (Seite 2, Zeilen 6 und 7).

3.1.12 Die Erfassung der Codeabdeckung ist darüber hinaus inhaltlich unabhängig vom synchronen Ausgabevergleich der beiden Einheiten. Seine Integration in Anspruch 1 eröffnet eine zweite technische Teilaufgabe, nämlich:

"die Zuverlässigkeit der Verifikation erhöhen".

3.1.13 Die Argumentation im Schreiben vom 6. Juni 2011, Seite 5, Abschnitt "2. Zweite technische Teilaufgabe", dass keine zweite technische Teilaufgabe vorläge, da es denkbar sei, dass die Seriensteuereinheit über den Trigger (301) aus Figur 3 die Codeabdeckungsanalyse in der Experimental steuereinheit starte, hat die Kammer nicht überzeugt. Diese Annahme ist spekulativ und durch nichts in der Beschreibung gestützt. Außerdem würde eine solche Erklärung des Steuersignalflusses nichts daran ändern, dass die Codeabdeckungserfassung die Zuverlässigkeit der Verifikation zu erhöhen ermöglicht (zweite technische Teilaufgabe), aber nicht die Korrektheit der Software eines Seriensteuergeräts testet, wenn ein funktio nieren des Referenzsystem vorliegt (erste technische Teil aufgabe). Es liegt also eine zweite Teilaufgabe vor.

3.1.14 Zur Lösung dieser zweiten Teilaufgabe würde der Fachmann es als offensichtlich ansehen, die Erfassung der Codeabdeckung aus D3 in das Verfahren aus D1 einzubauen.

3.1.15 Es wird in der Beschwerdebegründung argumentiert (Seite 2, Absätze 1-2), dass die Seriensteuereinheit nicht genügend Ressourcen habe, die durchlaufenen Pfade mitzuprotokollieren. Daher erfasse die Erfindung die Pfade auf der Experimental steuereinheit. Wenn diese eine ausreichende Codeabdeckung während der Verifikation aufweise, könne daraus geschlossen werden, dass auch die synchron getestete Seriensteuereinheit eine solche aufweise.

3.2 Allerdings stellt die Beschreibung die nicht bean spruch te Option, dass die Codeabdeckungsanalyse auf der Serien steuer einheit ablaufen könne, gleichrangig neben die beanspruchte Option (Seite 12, Absatz 2, Zeile 4). In Absatz 4, Zeile 1 wird dies wiederholt und ab Zeile 3 wird ausgeführt, dass die nicht beanspruchte Option vorteilhaft sei, da dann die Codeabdeckungs analyse auch die HW-abhängige Plattform software umfasse.

3.3 Die Kammer stimmt zu, dass es ein übliches Bestreben ist, die Kosten - und damit auch die Ressourcen - der Serien steuereinheit auf ein Minimum zu reduzieren. Es kann also durchaus sein, dass die Ressourcen einer geplanten Seriensteuereinheit nicht ausreichen, die Code ab deckungs erfassung auszuführen. In so einem Fall, in welchem man zusätzlich eine Experimentalsteuereinheit zur Hand hat, die nicht ebenso ressourcebeschränkt ist, betrachtet es die Kammer als offensichtlich für einen Fachmann, die Code ab deckungs erfassung von der bevor zugten Plattform, der Seriensteuereinheit, zur zweiten Möglichkeit, der Experimentalsteuereinheit, zu übertragen.

3.3.1 Daher ist der Gegenstand von Anspruch 1 des Hauptantrags nicht erfinderisch im Sinne von Artikel 56 EPÜ.

3.4 Hilfsantrag 1

3.4.1 Anspruch 1 von Hilfsantrag 1 enthält gegenüber Anspruch 1 des Hauptantrags zusätzlich das Merkmal aus Anspruch 3 des Hauptantrags (identisch mit dem ursprüng lichen Anspruch 3), nämlich dass der Softwarecode für die Softwarefunktionen jeweils für Experimental steuer einheit oder Seriensteuereinheit mit unterschiedlichen Erzeu gungs mitteln generiert wird.

3.4.2 Dieses Merkmal ist jedoch unvermeidlich, da sowohl im beanspruchten Verfahren als auch in demjenigen von D1 zwei unterschiedliche Hardware-Plattformen (eine für die Experimentalsteuereinheit und eine für die Seriensteuer einheit) benutzt werden. Das bedeutet, dass zwei Code erzeu gungs mittel notwendig sind (für jede Plattform ein eigenes).

3.4.3 Daher ist der Gegenstand von Anspruch 1 des Hilfs an trags 1 nicht erfinderisch im Sinne von Artikel 56 EPÜ.

3.5 Hilfsantrag 2

3.5.1 Anspruch 1 von Hilfsantrag 2 enthält gegenüber Anspruch 1 des Hilfsantrags 1 zusätzlich einen Teil des Merkmals aus Anspruch 6 des Hauptantrags (identisch mit dem ursprüng lichen Anspruch 7), nämlich dass der Softwarecode in hardwareabhängigen Software code und hardwareunabhängigen Softwarecode unterteilt ist. Es fehlt die Formulierung aus Anspruch 6, dass nur der hardwareunabhängige Softwarecode Softwarefunktionen zur Steuerung von Betriebsabläufen bei einem Fahrzeug dient. Dies hätte jedoch nicht in Anspruch 1 des Hilfsantrags 1 gepasst, da dort nicht von einem Fahrzeug die Rede ist.

3.5.2 Ein Fachmann weiß, dass es normalerweise in jedem Computer hardwareabhängige und hardwareunabhängige Software gibt. Treiber sind beispielsweise hardware abhängig, während Programme in der Programmiersprache Java hardwareunabhängig sind. Somit ist es offen sichtlich den Softwarecode in hardwareabhängigen und hardwareunabhängigen zu unterteilen.

3.5.3 Daher ist der Gegenstand von Anspruch 1 des Hilfs an trags 2 nicht erfinderisch im Sinne von Artikel 56 EPÜ.

ENTSCHEIDUNGSFORMEL

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.