3.6.2 Informationsmodellierung, Programmiertätigkeit und Programmiersprachen 

Informationsmodellierung ist eine gedankliche Tätigkeit ohne technischen Charakter, die in der Regel von einem Systemanalysten in der ersten Phase der Softwareentwicklung ausgeführt wird, um eine formale Beschreibung eines realen Systems oder Prozesses zu liefern. Folglich haben Spezifikationen einer Modelliersprache, die Struktur eines Verfahrens zur Informationsmodellierung (z. B. die Verwendung eines Templates) oder die Pflege von Modellen ebenfalls keinen technischen Charakter (T 354/07). Auch Eigenschaften, die Informationsmodellen inhärent sind, wie Wiederverwendbarkeit, Plattformunabhängigkeit oder Eignung zur Dokumentation, werden nicht als technische Wirkungen betrachtet (T 1171/06).

Wird ein Informationsmodell im Rahmen einer Erfindung zielgerichtet dazu genutzt, eine spezifische technische Aufgabe zu lösen, indem eine technische Wirkung erzeugt wird, so kann es zum technischen Charakter der Erfindung beitragen (siehe auch G‑II, 3.3.2 und 3.5.1).

Merkmale, die angeben, wie das Modell tatsächlich gespeichert wird (z. B. unter Verwendung von relationaler Datenbanktechnik), können ebenfalls einen technischen Beitrag leisten.

Konzeptuelle Verfahren, die den Prozess der Softwareentwicklung beschreiben (Metamethoden), haben in der Regel keinen technischen Charakter. In einem computerimplementierten Verfahren zur Erzeugung eines Programmcodes für eine Steuerungsaufgabe beispielsweise leistet ein Merkmal, das die Umwandlung eines plattformunabhängigen Modells in ein plattformabhängiges Modell spezifiziert, von dem an die Zielplattform angepasster Programmcode abgeleitet wird, keinen technischen Beitrag, weil die Erfüllung der Steuerungsaufgabe selbst davon nicht betroffen ist.

Die Tätigkeit des Programmierens – im Sinne des Formulierens von Programmcode – ist eine gedankliche, nichttechnische Tätigkeit, soweit sie nicht im Kontext einer konkreten Anwendung oder Umgebung dazu verwendet wird, einen kausalen Beitrag zur Erzeugung einer technischen Wirkung zu leisten (G 3/08, T 1539/09).

So ist zum Beispiel das Lesen eines Datentypparameters aus einer Datei als Input für ein Computerprogramm, statt den Datentyp im Programm selbst zu definieren, eine bloße Programmieroption beim Schreiben von Code, die per se keinen technischen Charakter hat. Dasselbe gilt für die Nomenklatur von Objektnamen zur Verbesserung der Verständlichkeit und der Verwaltung des Programmcodes.

Die Definition und Bereitstellung einer Programmiersprache oder eines Programmierparadigmas wie z. B. objektorientiertes Programmieren löst per se keine technische Aufgabe, auch wenn deren spezielle Syntax und Semantik die Entwicklung eines Programms für den Programmierer erleichtern. Eine Erleichterung der gedanklichen Aufgabe des Programmierers stellt aber per se keine technische Wirkung dar.

Bei der Prüfung einer Erfindung, die eine Programmierumgebung betrifft, tragen die Merkmale, die sich auf die Programmiersprache beziehen, normalerweise nicht zum technischen Charakter bei. Beispielsweise ist in einer visuellen Programmierumgebung die Bereitstellung spezifischer grafischer Bausteine Teil der Programmiersprache und leistet keinen technischen Beitrag, wenn die einzige Wirkung darin besteht, die gedankliche Arbeit des Programmierers zu erleichtern. Die Bereitstellung besonderer Programmierkonstrukte kann es einem Programmierer erlauben, kürzere Programme zu schreiben, doch gilt dies nicht als technische Wirkung, weil eine daraus resultierende Kürzung der Programmlänge letztendlich davon abhängt, wie die Programmierkonstrukte von einem menschlichen Programmierer genutzt werden. Die automatische Verarbeitung von Maschinencode durch Aufteilung in eine Befehlskette und eine Operandenanordnungskette und der Ersatz von repetitiven Befehlen durch Makrobefehle, um optimierten Code von reduzierter Speichergröße zu erzeugen, leisten hingegen einen technischen Beitrag. In diesem Fall hängt die Wirkung nicht davon ab, wie ein menschlicher Programmierer die Makrobefehle nutzt.

Die Merkmale einer Programmierumgebung, die die grafische Nutzeroberfläche betreffen, z. B. Visualisierungen und Dateneingabemechanismen, sind so zu prüfen wie in G‑II, 3.7 und 3.7.1 beschrieben.