T 1124/22 (Gebäudeinformationssystem/KAULQUAPPE) of 21.10.2024

Sachverhalt und Anträge

I. Die Beschwerde richtet sich gegen die Entscheidung der Prüfungsabteilung, mit der die europäische Patentanmeldung Nr. 17179560.2 mangels erfinderischer Tätigkeit zurückgewiesen wurde.

II. Die Prüfungsabteilung kam zum Schluss, dass der Gegenstand von Anspruch 1 des Hauptantrags und des ersten bis vierten Hilfsantrags nicht erfinderisch war gegenüber einem Rechner mit Datenbank. Als Beispiel dafür wurde unter anderem auf die Druckschrift D2 (US 5 604 892 A) verwiesen.

Die Prüfungsabteilung war insbesondere der Auffassung, dass die in Anspruch 1 des Hauptantrags definierten Deskriptoren ein abstraktes Datenmodell darstellten. Dieses zu programmieren, wäre für den Fachmann offensichtlich.

III. Die Beschwerdeführerin beantragte, die angefochtene Entscheidung aufzuheben und ein Patent zu erteilen auf Grundlage des Patentbegehrens gemäß des der Entscheidung zugrunde liegenden Hauptantrags oder ersten bis vierten Hilfsantrags. Alle Anträge wurden mit der Beschwerdebegründung erneut eingereicht.

Hilfsweise beantragte sie die Zurückverweisung an die Prüfungsabteilung zur weiteren Prüfung und weiter hilfsweise eine mündliche Verhandlung.

IV. Der unabhängige Anspruch 1 gemäß Hauptantrag lautet (Merkmalsgliederung in Anlehnung an Punkt 3 der Entscheidung):

Digitales Gebäudeinformationssystem zur speicherplatzschonenden und redundanzarmen Erfassung von Eigenschaften einer Vielzahl von Objekten eines Gebäudes, wobei die Objekte verschiedenen Elementklassen (E) zugeordnet sind, und wobei das Gebäudeinformationssystem eine Datenbank (40) umfasst, die folgende Deskriptoren enthält:

A. mindestens einen Instanzdeskriptor (511; 521) für mindestens eine Elementklasse (E), wobei jeder Instanzdeskriptor einer Instanz (I) der betreffenden Elementklasse (E) zugeordnet ist und Werte für eine Mehrzahl von Instanzattributen umfasst, darunter einen eindeutigen Instanzidentifikator und einen Typidentifikator für einen zugeordneten Typ (T),

B. wobei die Instanzattribute Eigenschaften der Objekte des Gebäudes beschreiben, die einem der Objekte individuell zugeordnet sind;

C. mindestens einen Typdeskriptor (512; 522) für jede Elementklasse (E), wobei jeder Typdeskriptor einem Typ (T) der betreffenden Elementklasse (E) zugeordnet ist und Werte für eine Mehrzahl von Typattributen umfasst, darunter einen eindeutigen Typidentifikator, wobei die Typattribute Eigenschaften der Objekte der Gebäude beschreiben, die mehreren Objekten der betreffenden Elementklasse (E) gemein sind; und

D. mindestens einen Ausnahmedeskriptor (513; 523) für mindestens eine Elementklasse (E), wobei jeder Ausnahmedeskriptor einer Instanz (I) der betreffenden Elementklasse (E) zugeordnet ist und angibt, dass bei der zugeordneten Instanz (I) mindestens eines der Typattribute (517) durch einen Ausnahmewert übersteuert ist.

V. Anspruch 1 des ersten Hilfsantrags hat denselben Wortlaut wie Anspruch 1 des Hauptantrags und fügt am Ende das folgende Merkmal hinzu:

und einen Elementdeskriptor (41; 42) für mindestens eine Elementklasse (E), wobei der Elementdeskriptor mindestens einen eindeutigen Elementidentifikator (411; 421) und Informationen (412; 422) zum Aufbau der zugehörigen Instanzdeskriptoren (511; 521) und Typdeskriptoren (512; 522) umfasst.

VI. Anspruch 1 des zweiten Hilfsantrags fügt am Ende vom Anspruch 1 des ersten Hilfsantrags folgende Merkmale hinzu:

sowie ein Erfassungsmodul (81) und/oder ein Ausgabemodul (82), wobei das Erfassungsmodul dazu ausgebildet ist, folgendes Verfahren auszuführen:

Empfangen (801) eines Objektdatensatzes für ein Objekt eines Gebäudes, wobei der Objektdatensatz eine Instanz (I) einer Elementklasse (E) beschreibt und ein oder mehrere Attributwerte, darunter einen Instanzidentifikator, enthält;

Überprüfen, ob der Objektdatensatz mindestens einen Attributwert enthält, der zu einem Typattribut gehört;

falls der Objektdatensatz mindestens einen Attributwert enthält, der zu einem Typattribut gehört, Auslesen (803) eines zur Instanz (I) zugehörigen Typdeskriptors aus der Datenbank (40) und Überprüfen (804), ob Attributwerte des Objektdatensatzes von Typattributwerten des ausgelesenen Typdeskriptors abweichen;

falls eine Abweichung mindestens eines Attributwerts des Objektdatensatzes von einem Typattributwert des ausgelesenen Typdeskriptors festgestellt wird:

(i) Überprüfen (806), ob ein entsprechender Ausnahmedeskriptor in der Datenbank existiert; und

(ii) falls kein entsprechender Ausnahmedeskriptor existiert, Erstellen (808) eines entsprechenden Ausnahmedeskriptors,

wobei das Ausgabemodul (82) dazu ausgebildet ist, folgendes Verfahren auszuführen:

Empfangen (901) eines Instanzidentifikators;

Auslesen (902) mindestens eines Teils der Instanzattribute, die dem Instanzidentifikator zugeordnet sind, aus der Datenbank (40);

Auslesen (903) des Typidentifikators, der dem Instanzidentifikator zugeordnet ist, aus der Datenbank;

Auslesen (904) mindestens eines Teils der Typattribute, die dem Typidentifikator zugeordnet sind, aus der Datenbank (40);

Auslesen (905) des Ausnahmedeskriptors, der dem Instanzidentifikator zugeordnet ist, aus der Datenbank (40);

Überprüfen (906), ob der Ausnahmedeskriptor leer ist;

falls der Ausnahmedeskriptor nicht leer ist und sich auf eines der ausgelesenen Typattribute bezieht, Übersteuern (907) mindestens eines der ausgelesenen Typattribute entsprechend dem Ausnahmedeskriptor;

Erstellen (909) eines Objektdatensatzes, der mindestens einen Teil der ausgelesenen Instanzattribute und der ausgelesenen Typattribute umfasst; und

Ausgeben (810) des Objektdatensatzes.

VII. Anspruch 1 des dritten Hilfsantrags fügt am Ende vom Anspruch 1 des ersten Hilfsantrags folgende Merkmale hinzu:

wobei sich die Elementklassen (E), für die die Datenbank Informationen enthält, auf mindestens eine der folgenden Objektarten beziehen:

Geschoss;

Raum;

Nutzungseinheit;

tragende Wand;

nichttragende Wand;

Bodenaufbau;

Abhangdecke;

Halterung;

Stütze;

Tragwerk;

Fundation;

Tür;

Fenster;

Fassade;

Treppe;

Rampe;

Ausstattung;

Raumausstattung;

Sanitärausstattung;

Geschossdecke;

Platzreservation;

Betonelement;

Beleuchtung;

Leichtbauwand;

Wandoberfläche;

Sanitärapparat;

Verkleidung;

Küche;

Aussparung;

Schottung.

VIII. Anspruch 1 des vierten Hilfsantrags ist eine Kombination von Anspruch 1 des zweiten und dritten Hilfsantrags.

IX. In der der Ladung zur mündlichen Verhandlung beigefügten Mitteilung gemäß Artikel 15(1) VOBK legte die Kammer ihre vorläufige Meinung dar. Sie neigte dazu, den von der Beschwerdeführerin geltend gemachten Effekt (verlustfreie Kompression von Daten und Optimierung des Speicherplatzbedarfs) als Folge einer rein abstrakten Datenmodellierung anzusehen (siehe Punkt 10 der Mitteilung gemäß Artikel 15(1) VOBK). Zudem stellte diese Datenmodellierung keine funktionale Datenstruktur dar (siehe z.B. T 1806/20 - Rain-sensitive parcels/IVECO, Nr. 3.8 der Entscheidungsgründe).

Die Kammer war ferner der Auffassung, dass der "Ausnahmedeskriptor" (letztes Merkmal von Anspruch 1 des Hauptantrags) möglicherweise nicht in allen Fällen geeignet war, eine weitere, d.h. über die durch den "Instanzdeskriptor" und "Typdeskriptor" definierte (und dem Fachmann bekannte) Normalisierung hinausgehende Redundanzverminderung zu erzielen (siehe Punkt 11).

Die Kammer wies darauf hin, dass auch die Hilfsanträge keine weiteren Merkmale zu enthalten schienen, die einen erfinderischen Schritt begründen konnten.

X. Mit Schreiben vom 4. Oktober 2024 nahm die Beschwerdeführerin zur Mitteilung gemäß Artikel 15(1) VOBK Stellung.

Sie argumentierte, dass Anspruch 1 des Hauptantrags kein Datenmodell, sondern eine Datenstruktur definiere, welche eine technische Lösung darstelle. Dabei sei es irrelevant, dass das dieser Datenstruktur zugrunde liegende Datenmodell an sich nicht-technisch sei. Anders als in T 42/09 - Logical hierarchical data model/BOEING, Nr. 2.5.8 der Entscheidungsgründe, werde die beanspruchte Datenstruktur gezielt zur Lösung einer technischen Aufgabe, nämlich zur verlustfreien Datenkompression, verwendet. Zudem erziele die erfindungsgemäße Verwendung des Ausnahmedeskriptors in allen praxisrelevanten Situationen den genannten technischen Effekt.

Die Beschwerdeführerin argumentierte ferner, dass der Ausnahmedeskriptor vom üblichen Vorgehen der Normalisierung einer relationalen Datenbank abweiche und deshalb dem Fachmann nicht nahegelegt sei.

XI. Am 21. Oktober 2024 fand eine mündliche Verhandlung in Form einer Videokonferenz statt.

Die Beschwerdeführerin bestätigte ihre schriftlich gestellten Anträge.

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

Entscheidungsgründe

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.

Entscheidungsformel

Aus diesen Gründen wird entschieden:

Die Beschwerde wird zurückgewiesen.