3.6.2 Information modelling, activity of programming and programming languages 

Information modelling is an intellectual activity devoid of technical character and typically carried out by a systems analyst in a first stage of software development to provide a formal description of a real-world system or process. It follows that specifications of a modelling language, the structure of an information modelling process (e.g. use of a template) or the maintenance of models likewise have no technical character (T 354/07). Similarly, properties inherent to information models, such as re-usability, platform-independence or convenience for documentation, are not regarded as technical effects (T 1171/06).

If an information model is purposively used in the context of an invention to solve a specific technical problem by providing a technical effect, it can contribute to the technical character of the invention (see also G‑II, 3.3.2 and G-II, 3.5.1).

Features specifying how the model is actually stored (e.g. using relational database technology) can also make a technical contribution.

Conceptual methods describing the process of software development (meta-methods) normally have no technical character. For example, in a computer-implemented method for generating program code for a control task, a feature specifying that a platform-independent model is converted to a platform-dependent model, from which program code adapted to the target platform is derived, makes no technical contribution in so far as the performance of the control task itself is not affected.

The activity of programming, in the sense of writing code, is an intellectual, non-technical activity unless it is used in the context of an actual application or environment to contribute in a causal manner to producing a technical effect (G 3/08, T 1539/09).

For example, reading a data type parameter from a file as input to a computer program, rather than defining the data type in the program itself, is merely a programming option when writing code, which per se has no technical character. The same applies to naming conventions for object names for facilitating the intelligibility and the management of program code.

Defining and providing a programming language or a programming paradigm such as object-oriented programming does not per se solve a technical problem, even if its particular syntax and semantics enable the programmer to develop a program more easily. Easing the intellectual effort of the programmer is not per se a technical effect.

When assessing an invention relating to a programming environment, the features pertaining to the programming language do not normally contribute to its technical character. For example, in a visual programming environment, the provision of specific graphical building blocks is part of the programming language and makes no technical contribution if the only effect is to ease the programmer's intellectual effort. The provision of particular programming constructs may enable a programmer to write shorter programs, but that does not qualify as a technical effect, since any resulting reduction in program length ultimately depends on how the programming constructs are used by a human programmer. In contrast, automatically processing machine code by dividing it into an instruction chain and an operand chain and replacing repeating instruction sets by macro-instructions so as to generate optimised code of reduced memory size makes a technical contribution as the effect does not depend on how a human programmer makes use of the macro-instructions.

Features of a programming environment that relate to its graphical user interface, e.g. visualisations and data input mechanisms, are to be assessed as described in G‑II, 3.7 and G-II, 3.7.1.