T 1124/22 (Gebäudeinformationssystem/KAULQUAPPE) 21-10-2024

1. Hintergrund der Anmeldung

1.1 Die Erfindung betrifft ein digitales Gebäudeinformationssystem. Bekannte Systeme ermöglichen es nicht, eine Vielzahl von oft gleichen Gebäudeinformationen möglichst redundanzarm und speicherplatzschonend in einem digitalen Modell abzubilden (siehe Paragraph [0015] und [0016] der A1-Veröffentlichung).

1.2 Diese Aufgabe wird durch ein Datenmodell mit den Merkmalen A bis D (siehe Punkt IV), welches in einer Datenbank des Gebäudeinformationssystems gespeichert ist, gelöst. Abbildungen 4 und 5 zeigen dieses Datenmodell, wobei die Instanzdeskriptoren, Typdeskriptoren und Ausnahmedeskriptoren jeweils Zeilen einer zugehörigen Instanz-, Typ- und Ausnahmetabelle darstellen (siehe Paragraph [0086]).

Die verschiedenen Elemente des Gebäudes, z.B eine Tür, werden so modelliert, dass Attribute, deren Werte für eine Vielzahl von Instanzen eines Elements identisch sind, zu einem Typ zusammengefasst werden. Die Elemente und Typen werden mittels einer Fremdschlüsselbeziehung miteinander verknüpft (siehe Paragraph [0068]).

1.3 Die Kernidee der Erfindung besteht darin, etwaige Ausnahmen einer Instanz hinsichtlich eines Typattributes in eine separate Ausnahmetabelle auszulagern. So z.B. wenn eine Tür statt der vom Typ vorgegebenen Breite von 130 cm eine Breite von 160 cm aufweist.

Mit dieser zusätzlichen Ausnahmetabelle sollen weitere Redundanzen vermieden und der Speicherplatzbedarf minimiert werden - siehe Paragraph [0081].

2. Hauptantrag, erfinderische Tätigkeit (Artikel 56 EPÜ)

2.1 Anspruch 1 definiert ein Gebäudeinformationssystem mit einer Datenbank und ist somit eine Erfindung im Sinne des Artikels 52(1) EPÜ.

Die Datenbank enthält eine Reihe von Deskriptoren (Merkmale A bis D), welche ein Datenmodell definieren (siehe Punkte 1.2 und 1.3).

2.2 Das zentrale Argument der Beschwerdeführerin ist, dass dieses Datenmodell eine (technische) Datenstruktur darstelle, welche zur Lösung eines technischen Problems beitrage und daher bei der Beurteilung der erfinderischen Tätigkeit zu berücksichtigen sei.

2.3 Die Kammer teilt diese Auffassung nicht.

Sie sieht im beanspruchten Datenmodell das Ergebnis einer rein gedanklichen Tätigkeit, welche unabhängig von und zeitlich vor der technischen Implementierung in einer (relationalen) Datenbank stattfindet. Der von der Beschwerdeführerin geltend gemachte Effekt der Datenkompression ist eine inhärente Eigenschaft des Datenmodells und kann deshalb im Sinne der T 42/09 und des dieser zugrunde liegenden COMVIK-Ansatzes (T 641/00 - Zwei Kennungen/COMVIK) nicht zur erfinderischen Tätigkeit beitragen.

Da der Anspruch keine technischen Details bezüglich der Implementierung des Datenmodells in einem Computersystem definiert, kann hierin auch kein erfinderischer Schritt begründet sein.

Die Kammer kommt deshalb zum Schluss, dass Anspruch 1 nicht erfinderisch ist gegenüber einem bekannten Computersystem mit einer (normalisierten) Datenbank.

2.4 Die Beschwerdeführerin argumentiert, dass Anspruch 1 eine Datenstruktur definiere, welche eine verlustfreie Datenkompression ermögliche. Dies werde insbesondere durch die Verwendung des Ausnahmedeskriptors erzielt, der eine effiziente Beschreibung und Speicherung von Ausnahmen ermögliche. Die Ausnahmen müssten nämlich nicht in der Instanz- oder Typtabelle oder, wie im Stand der Technik, in Kommentaren gehalten werden, was zu einem Aufblähen dieser Tabellen führe. Die beanspruchte Datenstruktur bedürfe keines kognitiven Schrittes oder menschlichen Zutuns und umgehe nicht die technische Aufgabe der Datenkompression, z.B. durch Weglassen bestimmter Daten, sondern löse sie.

Die Beschwerdeführerin argumentierte ferner, dass weder der COMVIK-Ansatz noch etwa G 1/19 (siehe Nrn. 33 und 39 der Begründung) technische Mittel zur Lösung der technischen Aufgabe vorschreiben. G 1/19 erwähne etwa einen Zwischenschritt zur Beurteilung, ob ein Merkmal zum technischen Charakter der Erfindung beiträgt. Merkmale A bis D erzielten den Effekt einer Datenkompression und trügen deshalb zum technischen Charakter bei, auch wenn das zugrunde liegende Datenmodell als solches nicht-technisch sei.

Für den Fachmann stelle sich das Problem, Gebäudedaten so in einer Datenbank zu implementieren, dass eine Kompression erreicht wird. Insbesondere bei der Wahl von Merkmal D kämen technische Überlegungen ins Spiel, nämlich wie häufig Ausnahmen auftreten, welche Eigenschaften die Daten haben und dergleichen. Man könne deshalb im Sinne der T 42/09 (siehe Nr. 2.4 der Entscheidungsgründe) im vorliegenden Fall von einem gezielten Einsatz des Datenmodells zur Lösung eines technischen Problems sprechen.

2.5 Die Kammer ist von diesen Argumenten nicht überzeugt.

Zum einen definiert der Anspruch keine Datenstrukturen in einem datenbankspezifischen Kontext oder im Zusammenhang einer technologischen Umsetzung. So definiert der Anspruch etwa keine Datentypen, Indizes, Speicherzuweisungen oder technische Details der zugrundeliegenden Datenbank. Ein technischer Beitrag in der Implementierung des Datenmodells oder einer dafür angepassten Datenstruktur ist deshalb nicht ersichtlich.

Zum andern beschreibt das Datenmodell lediglich in abstrakter Weise Objekte eines Gebäudes und deren Verknüpfungen miteinander, etwa dass die Tür mit der "TürID 4065-2" einen "Typ ST12EI0" hat, wobei jedoch die Breite nicht wie vom Typ vorgegeben 130 cm, sondern 160 cm beträgt (siehe Abbildung 5). Eine solche Beschreibung mag zwar durchaus komplex sein, da eine Vielzahl von Überlegungen zur Gebäudemodellierung berücksichtigt werden müssen. Überlegungen, etwa für welche Objekte bzw. Objektattribute Typen erstellt werden, wie diese miteinander verknüpft sind, welche Normen es im Gebäudewesen gibt oder das Beschreiben von Ausnahmen, sind jedoch eher organisatorischer, rein abstrakter Natur und das Resultat einer gedanklichen Tätigkeit (siehe auch G 1/19, Nr. 106 der Begründung).

2.6 Wie bereits dargelegt, besteht das beanspruchte Datenmodell unabhängig von Überlegungen zur technischen Umsetzung. Solche kommen erst ins Spiel, wenn der technische Fachmann, ein Datenbankprogrammierer, bei der Implementierung Überlegungen zu Datenstrukturen, Speicherarchitektur, Zugriffseffizienz, Sicherheit und dergleichen anstellt. Das Datenmodell wird also nicht in Hinblick auf die technische Umsetzung erstellt oder entsprechend angepasst. Auch basiert es nicht auf anderen technischen Überlegungen außerhalb der Computerimplementierung, die etwa bei der Erfassung von Eingangsdaten oder der weiteren Verwendung in einem technischen Gerät auftreten könnten. Man kann deshalb im vorliegenden Fall nicht von einem gezielten Einsatz des Datenmodells zur Lösung eines konkreten technischen Problems sprechen.

2.7 Ähnlich wie die Ausführungsgeschwindigkeit (und davon abgeleitete Effekte) eines abstrakten Algorithmus, etwa von Bubblesort oder Quicksort, eine inhärente Eigenschaft des Algorithmus ist, ist deshalb auch die erzielte Datenkompression eine inhärente Eigenschaft des zugrunde liegenden abstrakten Datenmodells.

Die Abstraktheit des beanspruchten Datenmodells kommt auch darin zum Ausdruck, dass es - wie in Abbildungen 4 und 5 - mittels einer Zeichnung auf Papier dargestellt werden kann. Diese deckt alle möglichen Implementierungen ab, die unterschiedliche Mengen an Speicher benötigen (z.B abhängig von den verwendeten Datenstrukturen oder der zugrundeliegenden Datenbank). Auch deshalb eignet sich eine bloße, dem Modell inhärente, Datenkompression nicht als Kriterium zur Unterscheidung zwischen technischen und nicht-technischen Merkmalen.

2.8 Wie bereits dargelegt, ist die zusätzliche Erwähnung eines nicht näher bezeichneten Gebäudeinformationssystems mit einer Datenbank, welche das Datenmodell enthält, nicht ausreichend, um in der technischen Umsetzung einen erfinderischen Schritt begründen zu können.

Deshalb beruht der Gegenstand von Anspruch 1 nicht auf einer erfinderischen Tätigkeit gegenüber einem bekannten Rechner mit (normalisierter) Datenbank, Artikel 52(1) und 56 EPÜ.

2.9 Die Kammer folgt damit der ratio decidendi der Entscheidung T 42/09, siehe insbesondere Nrn. 2.4 und 2.5.8 der Entscheidungsgründe.

Die Beschwerdeführerin argumentierte, dass die Sachlage dort eine andere sei als im vorliegenden Fall, da etwa Daten ausgelagert oder weggelassen und somit das Problem (im Sinne der T 258/03 - Auction method/HITACHI) umgangen werde.

Unabhängig von etwaigen Unterschieden in der Sachlage, ist die Argumentationskette in der T 42/09 jedoch auf den vorliegenden Fall anwendbar. Der wesentliche Punkt in beiden Fällen ist nämlich, dass das beanspruchte Datenmodell rein abstrakter Natur ist, keinen Bezug auf eine konkrete technische Umsetzung nimmt und nicht gezielt zur Lösung eines technischen Problems verwendet wird.

2.10 Selbst wenn man annähme, dass die Merkmale A bis D zum technischen Charakter beitragen, erzielen diese Merkmale zum einen keine Datenkompression über den gesamten Bereich des Anspruchs und somit nicht in allen Fällen eine Reduktion des Speicherplatzbedarfs. Zum anderen kommt die Kammer zum Schluss, dass sie auch keine erfinderische Tätigkeit begründen.

2.11 Gibt es nämlich in einem Gebäude sehr viele Ausnahmen, z.B. weil gesetzlich vorgeschrieben ist, dass ein Großteil der Türen eine Breite von 160 cm haben muss, hat das viele Einträge in der Ausnahmetabelle zur Folge. In einem solchen Fall könnte es, wie von der Beschwerdeführerin bestätigt, speicherplatzsparender sein, einen neuen Typ mit Breite 160 cm einzuführen. Weder der Anspruch noch die Beschreibung liefern Kriterien dafür, in welchen Situationen es sinnvoller ist, einen neuen Typ zu definieren anstatt eine Ausnahmetabelle (die an sich schon zusätzlichen Speicherplatz benötigt) zu erstellen.

2.12 Das Argument der Beschwerdeführerin, dass in allen praxisrelevanten Situationen eine Datenkompression stattfinde und dass das Wort "Ausnahme" beinhalte, dass diese in den Gebäudedaten nur selten vorkommen, vermag die Kammer nicht zu überzeugen.

Es gibt in der Beschreibung, z.B. im von der Beschwerdeführerin zitierten Paragraphen [0068], kein einziges konkretes Beispiel, in welchen Situationen ein (neuer) Typ definiert wird. Es heißt dort lediglich, dass "deren Werte für eine Vielzahl von Instanzen eines Elements derselben Elementklasse identisch sind", ohne näher darauf einzugehen, was "Vielzahl", etwa im Verhältnis zur Anzahl der Ausnahmen, bedeutet.

Der Fachmann müsste also durch Testen bzw. durch Versuch und Irrtum entsprechende Kriterien entwickeln, in welchen Situationen ein neuer Typ und in welchen eine Ausnahmetabelle eingeführt werden muss, um den Bedarf an Speicherplatz zu reduzieren. Dies stellt allerdings einen unzumutbaren Aufwand dar.

2.13 Ferner kann das Auslagern von Ausnahmen in eine eigene Tabelle zwar unter bestimmten Umständen den Speicherbedarf reduzieren, dies wird jedoch durch einen erhöhten Rechenaufwand erkauft. Zur Überprüfung von Ausnahmen muss nämlich für jedes Objekt die gesamte Ausnahmetabelle gelesen werden.

Ein solcher Trade-off zwischen Speicherplatzbedarf und Performance ist dem Fachmann im Bereich der Datenbankprogrammierung geläufig. Er würde den Umständen entsprechend ein gewünschtes Verhältnis wählen, indem er z.B. die Datenbank mehr oder weniger normalisiert, ohne hierbei erfinderisch tätig zu werden. Zudem ist das Normalisieren eines Datenmodells durch Verwenden von Fremdschlüsselbeziehungen zur Vermeidung von Redundanzen ein fachübliches Vorgehen beim Design von Datenbanken.

3. Erster bis vierter Hilfsantrag, erfinderische Tätigkeit (Artikel 56 EPÜ)

3.1 Anspruch 1 des ersten Hilfsantrags fügt einen Elementdeskriptor hinzu, welcher Informationen zur Struktur der Instanztabelle und der Typtabelle bereitstellt.

Der Elementdeskriptor scheint, wie von der Prüfungsabteilung festgestellt, lediglich eine Meta-Modellierung oder Teil des Datenbankschemas darzustellen (siehe Paragraph [0085]).

3.2 Die Kammer kann nicht erkennen, welchen technischen Effekt dieses zusätzliche Merkmal erzielt. Dass das Datenbankschema, insbesondere das Festlegen von Instanz- und Typattributen, eine Auswirkung auf die Datenkompression hat, ist unbestreitbar. Dieses hängt jedoch von der Modellierung der zugrundeliegenden physischen Objekte ab, welche zeitlich vor der Implementierungsphase stattfindet und an sich keine technische Tätigkeit darstellt.

3.3 Anspruch 1 des zweiten Hilfsantrags fügt ein Erfassungsmodul und/oder Ausgabemodul hinzu.

Das Erfassungsmodul überprüft insbesondere, ob ein empfangener Objektdatensatz Typattribute enthält und ob diese von einem zugehörigen Typdeskriptor abweichen. Wenn ja, wird ein neuer Ausnahmedeskriptor erstellt, falls ein solcher noch nicht existiert. Das Ausgabemodul liest, basierend auf einen Instanzidentifikator, einen zugehörigen Objektdatensatz aus.

3.4 Die Kammer bemerkt, dass das Erfassungsmodul lediglich Ausnahmen und keine neue Typen erstellt. Dies trägt, wie weiter oben dargelegt, in bestimmten Situationen nicht zur Datenkompression bei.

Ungeachtet dessen ist die Kammer der Auffassung, dass es sich hierbei lediglich um offensichtliche und für das Gebäudeinformationssystem notwendige Softwaremodule zur Ein-und Ausgabe der Gebäudedaten handelt.

3.5 Anspruch 1 des dritten Hilfsantrags fügt eine Liste von zu modellierenden Objekten hinzu.

Die zu modellierenden physischen Objekte an sich tragen nicht zum technischen Charakter des beanspruchten Gegenstandes bei (siehe auch G 1/19, Nrn. 106 und 110 der Begründung).

Die Tatsache, dass diese Objekte vielen baulichen Normen unterliegen und somit die Beschreibung ihrer Eigenschaften eine hohe Redundanz mit sich bringt, mag zwar bei der Datenmodellierung eine Rolle spielen. Dies ist jedoch kein technischer Vorgang und spielt somit bei der Beurteilung der erfinderischen Tätigkeit keine Rolle (siehe Punkt 2.5).

3.6 Anspruch 1 des vierten Hilfsantrags ist eine Kombination von Anspruch 1 des zweiten und dritten Hilfsantrags. Obige Argumente treffen deshalb auch für diesen Antrag zu.

3.7 Zusammenfassend kommt die Kammer zum Schluss, dass keiner der Hilfsanträge den Erfordernissen des Artikels 56 EPÜ genügt.