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. Consequently, 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, like 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, it can contribute to the technical character of the invention (see also G‑II, 3.3.2 and 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, to the extent that it is not used in the context of a concrete application or environment to contribute in a causal manner to the production of 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 has per se 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 with greater ease. Easing the intellectual effort of the programmer is per se not 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 easing the intellectual effort of the programmer. 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 of 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. In this case, 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 indicated in G‑II, 3.7 and 3.7.1.