This decision deals with the patentability of meta-methods used for software creation.
[2] The lack of inventive step already results from actual claim 1, which concerns a method for creating software programs by means of an electronic data processing system. As a rule, such a method comprises both technical and non-technical features. However, as long as such non-technical features and aspects of the invention do not have a direct interaction with technical features, in view of a technical effect, they cannot establish an inventive step (see T 154/04 [14 et sequ.]).
[3] As far as information modelling as a stage of software development is concerned, the Board has already stated that it is as such an intellectual activity (gedankliche Tätigkeit) and, therefore, in analogy to the objects and activities mentioned in A 52(2)(a) and (c), not an invention within the meaning of A 52(1) (see T 49/99 [5-7]). The Board (differently composed) has come to a very similar conclusion in the more ancient decision T 204/93 for the transposition of generic program specifications into a concrete software program.
[4] Software development and software creation comprise several stages, starting with the analysis of needs (Anforderungsanalyse), encompassing various design phases and ending in the software implementation. During all these phases it is essentially (dem Wesen nach) an intellectual activity, which may be compared to an engineer’s construction activity even though this work may be supported by programming tools and even though the object of the construction is a technical system.
The design and programming in particular of complex systems require [the person carrying out this work] to act like an engineer and to apply technical expertise but the achievement aimed at and obtained in each of these stages does not consist in providing a technical solution to a technical problem, but a specification of needs, a model for data, processes and/or functions, or a program code.
This assessment is all the more true for meta-methods which on an even more abstract level concern the process of software creation itself, e.g. by providing instructions (Handlungsanleitung) to the software developer on how to structure and organise the development process or which modelling methods are to be used.
As a rule, such conceptual methods and meta-methods of software creation do not possess technical features relevant for patentability and, therefore, cannot establish inventive step, unless in a particular case (im Einzelfall) it can be shown that there is a direct causal connection with a technical effect that is relevant for the solution of a technical problem.
[5] As the production of software is object of the claimed invention, the assessment of inventive step requires a careful distinction between the technical and the non-technical aspects of the invention.
The present invention mentions that the invention aims at creating an improved method (and device) for porting (Portierung) software to a target platform, by means of an electronic data processing system […]. [The invention] is said to make it possible to port technical solutions that have already been conceived (erdacht) to a new target platform with as little need for modification as possible.
This problem is said to be solved by the invention by means of a new method for porting software to a target platform, by means of an electronic data processing system comprising the following steps:
“1. Establishing of a first function chart (Funktionsplan) for a problem to be dealt with by a software program, the first function chart being independent of the platform.
2. Establishing a second function chart by means of the first function chart, the second function chart being adapted to specific requirements of the target platform.
3. Creating the software program for the target platform by means of the second function chart.”
[6] The expression “function chart” is used with very different meanings in the common technical usage (Sprachgebrauch), both for graphic representations of processes, programs, etc., as for designating particular graphical programming languages or programs that have been graphically encoded on the basis of such languages. The ambiguity of the expression requires an interpretation on the basis of the present application.
In paragraph 0011 of the A1-document the “first function chart” is described as “a graphical representation of a technical solution that is clear (übersichtlich) for the expert”. The first functional charts could be established by means of graphic editors wherein the functional blocks (Funktionsbausteine) would be placed in a working area (Arbeitsbereich), parameterised, and connected (verschalten). […] They could, for instance, be materialised as hardcopies on paper or as an electronically readable data file (Datei). The second function chart represented the software program in graphical form, which could be executed on the target platform […]. This required the transposition of the pieces of information contained in the second function chart into software code […].
[7] Therefore, the function charts within the meaning of the present application are nothing but graphical representations of a model of the control system (Steuerungs- und Regelungssystem) to be established, on different levels of abstraction, without there being an interaction with the system or the control procedures (Steuerungsprozesse) as it could be the case, for example, for a graphical user interface for a device control (Anlagensteuerung). The first function chart shows the functions and processes that are control-related (steuerungsrelevant), e.g. from the point of view of a system analyst, whereas the second function chart shows the model from the point of view of the programmer who has to take into account details of the implementation.
An influence on the portibility (Portierbarkeit) of software, as claimed in the application, exists only to the extent that the software developer can re-use the pieces of information contained in the function chart that is independent of the platform. However, it is a common feature of all information models that they are applicable in an area the extent of which depends on the level of abstraction on which the model is based, such that that it is possible to concretely express the model in this area in view of different hardware requirements.
The claimed concept which consists in establishing two function charts is a meta-method for structuring the modelling process. As no technical effect causally connected with the application of this method is apparent, this concept cannot be taken into consideration in the assessment of inventive step.
[8] The claimed method also comprises aspects the technical nature of which is indisputable. The software programs are created “by means of an electronic data processing system” and the elements (connection, interface, etc) of the first function chart are transposed into elements of the second function chart “by means of a rule base (Regelbasis) deposited in the electronic data processing system”.
[9] The Board and the appellant agree that document D1 is the closest prior art and a suitable starting point for the assessment of inventive step.
This document already discloses a method for creating a software program by means of an electronic data processing system (“on IBM AT and compatibles”). In this method, a first function chart (“block diagram”) is established in a first step by means of a graphic programming tool (“The Realizer by Actum Solutions … a fully graphics oriented program”). This first function chart is platform independent. The platform independence results from the indication that the block diagram drawn with the programming tool consists of standardized symbols (“standardized industrial control symbols”). Then the programming tool creates an “intermediate software” […] from the block diagram. This software is platform dependent because the programming tool relies on particular micro-controllers and controllers programmable from memory (speicherprogrammierbare Steuerungen) which are specific to certain manufacturers (“86HC05, Siemens PLCs, …”).
Finally the software program for the target platform is created with the intermediate software (“a postprocessor is started to refine the intermediate software for a specific hardware environment”).
[10] The only differences between the method of the present claim 1 and the method known from document D1 are that the intermediate software, or the model on which the intermediate software is based, respectively, is represented graphically as (second) function chart and that the automatic transposition of the elements of the first function chart into the corresponding elements of the second function chart is carried out by means of a rule base deposited in the electronic data processing system.
The graphic representation in the form of a second function chart only concerns the organisation and structuring of the development process, i.e. when which information model is visualised during the development process, without there being any direct causal connection with obtaining a technical effect. Structuring the development process in such a way may facilitate the intellectual work carried out by the software developer, but it does not make any technical contribution to the state of the art and, therefore, cannot be taken into account in the assessment of inventive step.
Finally, the method step according to which the elements of the first function chart are transposed into corresponding elements of the second function chart “by means of a rule base deposited in the electronic data processing system” cannot provide a basis for acknowledging inventive step. As is well known, a rule base is an integral part of “intelligent” knowledge-based methods, which have found various applications also in programming tools for developing software and which are generally known to the person skilled in the field of software development. This is also expressed in document D1 which refers to “intelligent” allotment of resources by the programming tools. The feature of obtaining such (artificial) intelligence by means of a knowledge-based method is obvious with respect to the general technical knowledge.
Therefore, the subject-matter of claim 1 lacks inventive step and cannot be patented. Thus even the method claim in the version as it stands cannot be granted. As there is no version of the claims that can be granted, the appeal has to be dismissed.
To read the whole decision (in German), click here.
NB: This decision is being reported parallely on Laurent Teyssèdre's blog.
NB: This decision is being reported parallely on Laurent Teyssèdre's blog.
0 comments:
Post a Comment