T 1102/10 (Automatische Konsistenzkontrolle/SWISSCOM) of 30.10.2014

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, mit schriftlichen Gründen datiert vom 15. Januar 2010, die Europäische Patentanmeldung Nr. 03405850.3 mangels erfinderischer Tätigkeit gegen­über dem Dokument D3=US 2002/188937 A1 zurückzuweisen.

II. Gegen diese Entscheidung legte die Anmelderin am 11. März 2010 Beschwerde ein und entrichtete die fälli­ge Beschwerdegebühr. Die Beschwerdebegründung ging am 11. Mai 2010 ein. Die Beschwerdeführerin beantragte da­rin, die Entscheidung der Prüfungsabteilung vollum­fäng­lich auf­zu­heben und ein Pa­tent zu erteilen auf Basis geänder­ter Ansprüche 1-18, die mit der Beschwer­de­be­grün­dung vorge­legt wur­den, ­offenbar in Verbindung mit den fol­genden Anmel­dungs­un­ter­lagen:

Zeichnungen, Blatt

1/4-4/4 ursprüngliche Fassung

Beschreibung, Seiten

1, 3-19 ursprüngliche Fassung

2, 2a, 2b eingegangen am 10. Oktober 2005

III. Mit einer Ladung zur mündlichen Verhandlung teilte die Kammer der Beschwerdeführerin ihre vorläufige Meinung mit, nach der der beanspruchte Gegenstand im Lichte von D3 nicht auf einer erfinderische Tätigkeit beruhe.

IV. In Erwiderung auf die Ladung, mit Schreiben vom 30. Sep­­­tem­ber 2014, legte die Beschwerdeführerin einen weiteren Anspruchssatz 1-18 als Hilfsantrag vor.

Anspruch 1 des Hauptantrags lautet wie folgt:

"Verfahren zum Ermöglichen von verteilten programmierten Applikationen, welche aus kooperierenden Applikationsteilen (21, 51, N1) bestehen, die auf mehreren verschiedenen durch Kommunikationskanäle verbundenen elektronischen Vorrichtungseinheiten (1, 2, 5, N) installierbar sind, umfassend:

eine automatische Konsistenzkontrolle der verschiedenen kooperierenden Applikationsteile (21, 51, N1) einer der verteilten programmierten Applikationen, deren Applikationsteile 21, 51, N1) auf mehreren verschiedenen durch Kommunikationskanäle verbundenen elektronischen Vorrichtungseinheiten (1, 2, 5, N) installiert sind, wobei einer der Vorrichtungseinheiten (1) als mobiles, für die Kommunikation über ein Mobilfunknetz eingerichtetes Kommunikationsendgerät ausgestaltet ist, durch:

- Bereitstellen von Eigenschaftsdatensätzen, die jeweils Angaben über Eigenschaften eines der an der verteilten programmierten Applikation beteiligten Applikationsteile (21, 51, N1) umfassen, jeweils durch ein Eigenschaftsdatenerzeugungsmodul (22, 52, N2), das dem betreffenden einen der an der verteilten programmierten Applikation beteiligten Applikationsteile (21, 51, N1) zugeordnet auf einer der Vorrichtungseinheiten (2, 5, N) installiert ist,

- Übermitteln der bereitgestellten Eigenschaftsdatensätze von den Eigenschaftsdatenerzeugungsmodulen (22, 52, N2) an mindestens ein Eigenschaftsdatenaggregationsmodul (13, 53, N3) zum Aggregieren der Eigenschaftsdatensätze,

- Fällen eines Entscheids über die Konsistenz der an der verteilten programmierten Applikation beteiligten Applikationsteile (21, 51, N1) basierend auf den in den Eigenschaftsdatensätzen enthaltenen Eigenschaften der an der verteilten programmierten Applikation beteiligten Applikationsteile (21, 51, N1) durch ein Konsistenzkontrollmodul (16, N6), wobei der Entscheid abhängig ist von der Kompatibilität der an der verteilten programmierten Applikation beteiligten Applikationsteile (21, 51, N1),

- Freigeben einer Ausführung der verteilten programmierten Applikation durch ein im Kommunikationsendgerät angeordnetes Konsistenzsteuermodul (17) bei einem positiven Entscheid über die Konsistenz der an der verteilten programmierten Applikation beteiligten Applikationsteile (21, 51, N1), und

- Übermitteln einer Installationsanfrage für eines oder mehrere Applikationsteile (21, 51, N1) zum Erreichen einer Konsistenz der an der verteilten programmierten Applikation beteiligten Applikationsteile (21, 51, N1) durch das Konsistenzsteuermodul (17) über das Mobilfunknetz an eine Applikationsanbietereinheit (4) bei einem negativen Entscheid über die Konsistenz der an der verteilten programmierten Applikation beteiligten Applikationsteile (21, 51, N1)."

Anspruch 1 des Hilfsantrags unterscheidet sich von Anspruch 1 des Hauptantrags dadurch, dass zwischen "installierbar sind" und "umfassend" am Ende des ersten Absatzes das folgende Merkmal eingefügt wurde:

"..., wobei unterschiedliche Applikationsteile dynamisch zu einer verteilten programmierten Applikation zusammengeschaltet werden können, ..."

Beide Anträge enthalten je einen zweiten unabhängigen Anspruch 10, der auf ein System zum Ermöglichen von ver­teilten programmierten Applikationen gerichtet ist und im Wortlaut dem jeweiligen unabhängigen Verfah­rens­antrag 1 weitgehend entspricht.

V. ­Mit Schreiben vom 15. Okto­ber 2014 teilte die Beschwer­de­­führerin der Kammer mit, dass zur anberaumten mündli­chen Verhandlung weder der Anmelder noch dessen Vertre­ter anwesend sein würden.

VI. Die mündliche Verhandlung fand am 30. Oktober 2014 in Abwesenheit der Beschwerdeführerin statt. Am Ende der Verhandlung verkündete der Vorsitzende die Entscheidung der Kammer.

Entscheidungsgründe

Mündliche Verhandlung in Abwesenheit der Beschwerdeführerin

1. Die ordnungsgemäß geladene Beschwerdeführerin war in der mündlichen Verhandlung nicht anwesend. Gemäß Arti­kel 15(3) VOBK wurde das schriftliche Vorbringen der Beschwerdeführerin berücksichtigt. Am Ende der münd­li­chen Verhandlung verkündete die Kammer ihre Ent­schei­dung, da die Sache entscheidungsreif war (Artikel 15(5,6) VOBK) und die Abwesenheit der Beschwerde­füh­rerin kein Grund war, die Entscheidung aufzuschieben (Artikel 15(3) VOBK).

Die Erfindung

2. Die Anmeldung bezieht sich im allgemeinen auf verteilte Programmierung. Die Hardwareplattform kann laut der An­meldung "flexibel und dynamisch" aus unterschied­lichen elektronische "Vorrichtungseinheiten" aufgebaut werden, beispielsweise PCs, Laptops, PDAs oder Mobilfunkgeräte, die mittels geeigneter "Kommunikationskanäle" verknüpft werden (S. 1, Zn. 12-22 und 27-29; S. 2, Zn. 6-12). Anspruchsgemäß ist wenigstens einer der Vorrichtungs­ein­heiten ein "mobiles, für die Kommunikation über ein Mo­bil­funknetz eingerichtetes Kommunikationsendgerät", also typischerweise ein Mobiltelefon. Auf die­ser Platt­form können "Applikationsteile" auf unter­schied­liche Weise auf die Vorrichtungseinheiten auf­ge­teilt und "fle­xibel und dynamisch zu einer Pro­gramm­appli­­ka­tion zusammengeschaltet werden" (S. 2, Zn. 6-12).

2.1 In diesem Kontext bezieht sich die Anmeldung insbe­son­dere auf die au­to­matische Konsis­tenzkontrolle der Appli­kationsteile einer solchen verteilten programmier­ten Applikation (ursprüngliche Anmeldung, S. 1, Zn. 4-10; S. 2, Zn. 19-21; Anspruch 1).

2.2 Diese Konsistenzkontrolle erfolgt in einer Reihe "de­fi­nierter Funktionsschritte", die jeweils von dedizier­ten "funktionalen Modulen" ausgeführt werden (vgl. Ta­belle 1 auf S. 9): Zunächst werden Datensätze bereit­ge­stellt, die "Eigenschaften" der "Applikations­teile" um­fassen, und diese Datensätze werden dann "aggre­giert". Aus den aggre­gierten Datensätzen werden "Konsistenz­da­ten" er­zeugt, auf deren Basis ein "Entscheid über die Konsis­­tenz der Applikationsteile" erfolgt. Falls dieser Ent­scheid positiv ist, wird die verteilte Applikation frei­­­gegeben. Falls nicht, ergeht eine "Installa­tions­anfrage für einen oder mehrere Applikationsteile", die nötig sind, um die angestrebte Konsistenz herzustellen.

2.3 Eine von diesen ist als "mobiles, für die Kommuni­ka­tion über ein Mobilfunknetz eingerichtetes Kommunika­tions­end­gerät ausgestaltet" und sowohl der Entscheid über die Freigabe einer Applikation, als auch ggfs. die Über­­­mittlung der Installationsanfrage erfolgt durch ein auf diesem Kommunikationsgerät installierten Modul, das so­genannte "Konsistenzsteuermodul". Darüber hinaus legt sich die Anmeldung auf keine weiteren Eigenschaften der "Vor­rich­tungseinheiten" fest, und auch nicht darauf, auf welcher Einheit welches Modul der Konsistenz­kon­trolle ausge­führt wird. Die Flexibilität in dieser Hin­sicht ist beabsichtigt (vgl. S. 3, Zn. 20-30).

Anspruchsauslegung

3. Die Kammer weist zunächst darauf hin, dass einige der für den beanspruchten Ge­genstand zentralen Begriffe sehr unspezifisch sind.

3.1 Die Ansprüche beziehen sich auf eine "verteilte, pro­gram­mierte Applikation", deren "verschiedene kooperie­rende Applikationsteile" auf unterschiedlichen Vor­rich­tungseinheiten "installiert" sind, aber die darüber hi­naus undefiniert bleibt. Die "Eigenschaftsda­ten­sätze" um­fassen "Eigenschaften" der Applikationsteile, von denen nur feststeht, dass sie für die "Konsistenz­kon­trolle" von Bedeutung sind. Das "Aggregieren" dient offenbar dazu, ­die Eigenschafts­daten­sätze der Konsis­tenz­kontrolle gleich­zei­tig ver­fügbar zu machen, ist da­rüber hinaus aber nicht de­finiert. Auch von der Kon­sis­tenzkon­trolle ist nur festgelegt, dass sie über eine unspezi­fische "Kon­sis­tenz der ... beteiligten Applika­tions­teile" ent­schei­­det. Wie das geschieht und in welcher Weise nach einem negativen Entscheid über die Kon­sistenz bestimmt wird, welche Applikationsteile neu installiert werden müssen, ist weder beansprucht noch beschrieben.

3.2 Wenngleich dieser Umstand an sich nicht zu einem Klar­heits­einwand führt, so meint die Kammer doch, dass die­se Begriffe weit ausgelegt werden müssen.

4. Anspruchsgemäß ist die Erfindung geeignet

(a) "zum Er­mög­lichen von verteilten programmierten Applikationen".

Die Beschwerdeführerin betont, dass der Gegenstand der Erfindung dementsprechend auf mehrere, unterschiedliche und "fle­xibel und dynamisch zusammengeschaltet[e]" Appli­­­katio­nen gerichtet ist; im Hilfsantrag kommt das durch das Merkmal zum Ausdruck, demgemäß

(b) "unterschiedliche Applikationsteile dynamisch zu einer verteilten programmierten Applikation zu­sammen­geschaltet werden können".

Die Beschwerdeführerin räumt jedoch ein (Schreiben vom 30. September 2014, Punkt 3), dass anspruchs­gemäß nur für eine dieser Applika­tionen die Konsistenz­kontrolle durchgeführt wird.

4.1 Als Basis für die Merkmale (a) und (b), die beide im Be­schwerdeverfahren in die Ansprüche aufgenommen wur­den, gibt die ­Beschwerdeführerin Seite 1, Zeilen 12-18; Seite 2, Zeilen 8-11; Seite 3, Zeilen 21-27; S. 4, Zei­len 20-22 und Seite 7, Zeilen 20-24 in der ur­sprüng­lichen Anmeldung an (Beschwerde­be­gründung, An­hang A, sowie Schreiben vom 30. September 2014, Punkt 3).

4.2 Seite 1, Zei­len 21-27, spricht von einer zunehmend mo­du­­la­ren Bau­weise und vermehrter Kommunikationsfä­hig­keit elektro­nischer Vorrichtungen und der sich daraus erge­benden heterogenen Hardwareplattformen. Seite 2, Zeilen 8-12 offenbart die Möglichkeit "Applikations­teile ... flexibel und dynamisch" zusammenzuschalten, ohne diesen Vorgang jedoch genauer auszuführen. Seite 3, Zeilen 21-27, offenbart die Möglichkeit, die "Funk­tions­module der Konsistenzkontrolle" auf unter­schied­liche Vorrich­tungseinheiten aufzuteilen, "so dass sich unterschied­liche Archi­tek­turen" der Konsistenzkontrolle "realisie­ren lassen". Seite 4, Zeilen 20-22, bezieht sich auf die "Applika­tions­teile, die aktuell an [einer] verteil­ten Programm­applikation beteiligt sind". Seite 7, Zeile 20-24, ist für das genannte Merkmal nicht von Bedeu­tung.

4.3 Aus diesen Stellen der Beschreibung geht hervor, dass die Erstellung einer verteilten Applikation "flexibel" und ihre Änderung "dynamisch" möglich sein solle. Auf diese Weise werden unterschiedliche Applikationen zu unterschiedlichen Zeitpunkten (dynamisch) "ermöglicht", beispiels­weise nacheinander (Merkmal (a)). Dass unter­schiedliche Applikationen gleichzeitig ermöglicht wür­den, geht nach Ansicht der Kammer weder aus den ge­nann­ten Stellen noch aus dem Anspruchswortlaut hervor.

4.4 Hinsichtlich Merkmal (b) merkt die Kammer zunächst an, dass es das Verfahren zur Konsistenzkontrolle nicht be­schränkt, dass Applikationsteile dynamisch zusammen­geschaltet werden können: Zum einen ist die Möglichkeit der dynamischen Zusammenschaltung kein Schritt des beanspruchten Verfahrens, und zum anderen geht aus dem Anspruch nicht hervor, dass die Konsistenzkontrolle in irgendeiner Weise speziell für dynamisch zusammenge­schal­te­te Applikationen angepasst wäre: Die Bereit­stellung der einschlägigen Eigenschaftsdatensätze, auf die sich die Konsistenzkontrolle stützt, muss in der­selben Weise erfolgen, ob nun die Applikation "dyna­misch" oder anderweitig zusammengeschaltet worden ist.

5. Die Beschwerdeführerin argumentiert weiter, dass D3 nur die "Kompatibilität von sämtlichen Systemkomponenten" im Rahmen einer "einzigen Gesamtkonfiguration" über­prü­fen bzw. herstellen könne (Beschwerdebegründung, Punkte 15 und 19), während die beanspruchte Erfindung eine Kon­sis­tenz­­­­kon­trolle für mehrere programmierte Appli­ka­tion er­mög­li­che, der ent­spre­chend eine Applikation frei­ge­schal­­tet werden könne, eine andere aber nicht (Be­schwer­­­debe­grün­dung 18, 21, 22 und 27).

5.1 ­Die Kammer räumt ein, dass aus der Konsis­tenz einer ers­ten Applikation im allgemeinen nicht auf die Konsis­tenz einer zweiten Applikation geschlossen werden kann, da und soweit beide aus unterschiedlichen Appli­kationsteilen bestehen können (Schrei­ben vom 30. Sep­tember 2014, Punkt 24).

5.2 Die Kammer ist aber auch der Ansicht, wie eben ausge­führt, dass der Anspruch nicht die gleich­zei­tige Exis­tenz mehrerer verteilter Applika­tio­nen impli­ziert. Wenn also nach erfolgreicher Konsistenzkontrolle eine Appli­ka­tion freigegeben wird, so stellt sich das Problem der Freigabe einer wei­teren Applikation anspruchsgemäß nicht.

Stand der Technik

6. Obgleich die Entscheidung fünf Dokumente benennt, von denen einige im Verlauf der Prüfung diskutiert wurden, stützt sich die Entscheidung ausschließlich auf das Do­ku­ment D3.

7. D3 offenbart ein Verfahren zur Überprüfung und Her­stellung von Konsistenz zwischen Audio- und Video-Ge­rä­ten in einem Heimnetzwerk. Insbesondere wird ein Netz­werk betrachtet, dass auf dem HAVi-Standard beruht (HAVi = "Home Audio Video interoperability"). Dieser Stan­­dard verlangt, dass jedes Gerät eine Selbstbe­schrei­­bung ("Self Describing Data") bereitstellt und in einem Konfigurations-ROM ("configROM") den anderen Ge­rä­ten zugänglich macht (vgl. Abs. 3-5). Wenn eine Sys­temkomponente eines der vernetzten Geräten aktu­ali­siert ("updated") wird, wird untersucht, ob eine Aktuali­sie­rung anderer Geräte ebenfalls notwendig geworden ist. Das zu­letzt aktualisierte Gerät übernimmt dabei typi­scher­weise die Rolle des "network update managers" (s. z. B. Abs. 31). Dieser sammelt die System- und "Kom­pa­ti­­bi­li­täts­­informationen" aus den Konfigurations-ROMs der ver­netz­ten Geräte (z. B. Abs. 32), bestimmt für je­des Ge­rät eine optimale Kombination zu installie­ren­der Kompo­nen­ten und steuert das Laden der als not­wendig be­stimmten Aktuali­sie­rungs­­mo­du­le (z. B. Abs. 33-35).

Erfinderische Tätigkeit

8. Die Kammer ist der Ansicht, dass die Gesamtheit der Systemkomponenten in einem bestehenden HAVi-Netzwerk eine "verteilte programmierte Applikation" ist, "welche aus kooperierenden Applikationsteilen ... besteh[t]" und die auf vernetzten "Vorrichtungseinheiten ... in­stallierbar sind", wie es insbesondere Anspruch 1 des Hauptantrags verlangt. Da sich die Komponenten eines solchen Netzwerks ändern können - wenn etwa ein weite­rer Fernseher oder eine Spielekonsole einem bestehenden Netzwerk hinzugefügt wird - ist die Kammer auch der Mei­nung, dass die "Applikationsteile dynamisch zu ei­ner ... Applikation zusammengeschaltet werden kön­nen", wie es insbesondere Anspruch 1 des Hilfsantrags ver­langt.

9. In der angegriffenen Entscheidung stellte die Prüfungs­ab­teilung drei Unterschiede des zu diesem Zeitpunkt be­­­anspruchten Gegenstandes ge­genüber D3 fest, nämlich im Wesentlichen dass

1) eine der Vorrichtungseinheiten als ein mobiles Kommunikationsgerät ausgestaltet ist, dass

3) die Installationsanfrage über dieses Gerät erfolgt, und dass

2) die Freigabe zur Ausführung einer Applikation bei einem positiven Entscheid über die Konsistenz ihrer Teile erfolgt.

Die Nummerierung entspricht der in der Entscheidung ge­brauchten. Die Ent­scheidung kam zu dem Ergebnis, dass die ge­nann­ten Unterschiede für den Fachmann im Lichte des ein­schlä­gi­gen allgemeinen Fachwissens naheliegend seien und somit keine erfin­de­rische Tätigkeit begründen könnten: Insbe­sondere (hinsichtlich 1 und 3) seien Mobilfunkge­rä­te als vernetzte Komponenten bekannt und die Verwen­dung ei­nes Mobilfunknetzes als alternative Kommunikations­verbindung naheliegend und (hinsichtlich 2) eine expli­zite Freigabe für den Fachmann eine "Selbst­­verständ­lich­keit" (Gründe 2.4, S. 5, letzte 2 Ab­sätze - S. 7, Z. 1).

9.1 Die Beschwerdeführerin bestreitet diese Analyse nur in­so­fern, als sie vorträgt, die Prüfungsabteilung habe (i) nicht alle Un­ter­schei­­dungsmerkmale festgestellt und (ii) diese nicht auf mögliche Synergieeffekte unter­sucht (Schrei­ben vom 30. Sep­tember 2014, Punkt 33). Die Beschwerdefüh­re­rin bestreitet jedoch nicht die Ent­schei­­dungsgründe dafür, dass diese Merk­ma­le an sich aus dem allge­mei­nen Fachwissen nahe­liegend wären.

9.2 Was Einwand (i) angeht, so trägt die Beschwerdeführerin vor (Schreiben vom 30. September 2014, Punkte 3, 22, 23, 29 und 38), die Erfin­dung sei von D3 zusätz­lich dadurch un­terschieden, dass sie die Konsis­tenz­kon­trolle für "eine von mehreren unterschiedlichen ver­teil­ten Appli­ka­tionen" durchführe. Die Kammer kann sich, wie oben erläutert (insbes. Punkt 8), der Meinung nicht an­schließen, dass dieser zusätz­liche Unterschied besteht.

9.3 Was Einwand (ii) angeht, so behauptet die Beschwerde­führerin zwar, die Prüfungsabteilung habe die Merkmale 1-3 nicht auf einen möglichen Synergieeffekt untersucht (Punkt 31), stellt aber ihrerseits nicht fest, worin ein solcher bestehen könnte. Insbesondere führt die Beschwerdeführerin nicht aus, warum die Verwendung ei­nes mobilen Geräts in einem Netzwerk gemäß den Merkma­len 1) und 3) mit der beanspruchten Konsistenzkontrolle oder der anschließenden Freigabe einer Applikation in einer nicht-trivialen funktionalen Wechselwirkung ste­hen solle. Die Beschwerdeführerin erläutert auch nicht, in welcher Weise die Merkmale 1-3 mit dem behaupteten (und von der Kammer bestrittenen) weiteren Unterschied interagieren würden, demgemäß die über­prüf­te Applika­tion nur eine von mehreren, ggfs. dynamisch zusammenge­schalteten, Applikationen sei.

9.4 Die Beschwerdeführerin trägt vor, die Erfindung löse die Aufgabe, "auf Vorrichtungseinheiten installierte Applikationsteile bedarfsgerecht nachzuführen", woraus sich ein geringerer Netzwerkverkehr ergebe als in D3, in der ein Softwareupdate nur für die Gesamtkonfigu­ration durchgeführt werde (Schreiben vom 30. Septem­ber 2014, Punkte 40 und 41).

9.5 Die Kammer ist hingegen der Meinung, dass auch das Software­update gemäß D3 die Applikationsteile innerhalb des HAVi insofern "bedarfsgerecht" nachführt, als zwar die Gesamtkonfiguration überprüft wird, aber nur die "notwendigen" Updates tatsächlich geladen werden (vgl. Abs. 34). Auch eine geringere Netzwerkauslastung der Erfindung gegenüber D3 kann die Kammer nicht fest­stellen, da in D3 nur die relevanten - nämlich in der obigen Auslegung zu einem gegebenen Zeitpunkt ver­netzten Komponenten (vgl. Punkt 8) - auf Konsistenz überprüft werden.

9.6 Die Argumente der Beschwerdeführerin können die Kammer somit nicht überzeugen. Vielmehr bleibt sie bei ihrer im Ladungszusatz ausgedrückten Meinung, dass die Unter­schiede 1-3 wie in der Entscheidung aus­ge­führt und oben zusammengefasst (Punkt 9), für den Fachmann auf­grund seines allgemeinen Fachwissens nahe­gelegen hätten.

9.7 Anspruch 1 sowohl des Haupt- als auch des Hilfsantrags weisen somit nicht den erforderlichen erfinderischen Schritt auf, Artikel 56 EPÜ 1973.

Entscheidungsformel

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.