Workflow Rules Controlling Tasks And Tags Labelling The States Of The Tasks: Non-technical

1.1 The invention relates to a central control system for providing automated real-time interaction and state-transition-controlled processing of (data) objects.

1.2 Traditional workflow systems comprise at their core a workflow execution engine which controls and monitors the processing of objects.

1.3 In practice, workflow execution engines are rarely able to accurately or completely execute all the steps of the process by means of the workflow system alone and human intervention is required, in particular to gather all information needed to decide the next steps of further processing.

1.5 The invention is said, rather generally, to provide a system which is capable of flexibly capturing the external and/or internal factors that may affect the processing of an object within a workflow and that is more capable of being operated by externally or internally occurring boundary conditions or constraints. Furthermore it is able to react dynamically to changing environmental or internal conditions or measuring parameters that are possibly not known or predictable at the beginning of the workflow process, in particular without human inter action, page 4, 2nd paragraph.

1.6 The solution of the invention is a state-transition-controlled processing of objects wherein a selected object 71, 72, 73 is processed from one process state 121, 122 to a subse quent process state 122, 123 by executing the process tasks 131 assigned to the process state of the object, see Figure 1, by the control system. The state transition of the object in the process flow is controlled based upon the operating parameters of an assigned operating tag 132, see page 17, 2nd paragraph. These operating parameters can be changed by authorised assigner units or assignee units. The application explains that a dedicated signalling is done to associated run-time execution modules 50, 51, 52 which serves as means for executing the activated process tasks based on the transmitted control and steering signalling.

2.1 The examining division in summary argued, see reasons, point 2.1 of the impugned decision, that the claimed subject-matter related to abstract information modelling concepts at meta-language level in the context of workflows. They pointed out that the design and modelling of workflows for business pro cesses represented activities in the sphere of methods for doing business.

2.3 The appellant disagrees with this non-technical interpretation. The application does not disclose the modelling of a business process as such. The invention rather relates to the automatic execution of a process with technical means and with an electronic control system. A claim shall be interpreted in good faith and objectively by the person skilled in the art. A missing contribution of particular features, such as "object", "assigner units" and "assignee units", to the technical character shall not be a criterion for an over-broad interpreta tion of claims. The description and Figures should always be interpreted as a "whole" and an application be regarded in its entirety.

The object of the invention is to provide a technical possibility that allows a workflow to be changed in a controlled manner, that is, the electronic control system enables dynamic reaction to and adjustment of the automated workflow. The solution of the invention involves "operating tags" which represent a protected, dynamically modifiable and tagged area which the electronic control system uses (if possible) to adapt the automation of the workflow.

The appellant further argued that following G 1/19 a method that changes something which is processed, has a technical effect and is therefore technical. The invention introduces the concept of "operating tags" which repre sent a technical possibility of interaction with a process task. In contrast to D1 the invention does not need a complex folder structure for realising a workflow system.

2.4 Regarding the question of how to interpret the claimed subject-matter the Board notes that according to the established jurisprudence of the Boards of Appeal on the general principles for claim interpretation, see Case Law of the Boards of Appeal, Edition 2022, II.A-6, the wording of the claims should typically be given its broadest technically sensible meaning by a skilled reader. When an invention is at the boundary between technical and non-technical matter, also a non-technical interpretation of a claimed feature may have a sensible meaning, in particular if the description and Figures disclose embodiments which permit such an interpretation. Claims must be read with a mind willing to understand and to make technical sense of them, thereby ruling out illogical or technically meaningless interpretations. This also means that if a non-technical interpretation of a feature makes sense, then such an interpretation should not be excluded.

2.10 The examining division considered the subject-matter of claim 1 to be distinguished from D1 by the feature: "and wherein the state-structured process flow is a discrete time stochastic control process, wherein the control system comprises a stochastic rating module and the initiation of the next process task is also based on an additional rating by means of the stochastic rating module".

2.11 The examining division was of the opinion that the claimed rating is nothing more than a non-technical workflow rule according to which a next process task is initiated. Such workflow rules stem from business requirements and their implementation on the D1 system is a straight-forward modular programming based on common general knowledge.

2.12 The appellant in summary argues that the feature "discrete time stochastic control process" must be seen in combination with the system control structure and the operating tags. Such a control is not disclosed in D1 nor is it needed. D1 discloses that different workflow instances may be associated with objects, but these workflow instance are not altered.

2.17 As mentioned above, the application does not define how the "stochastic rating module" determines the "stochastic rating". The Board agrees with the examining division that this merely amounts to a mathematical rule according to which a new process task gets initiated, see second half on page 7 of the decision, which cannot contribute to the technical character of claim 1, an thus not to the presence of inventive step (Article 56 EPC).

2.18 The Board considers that the appellant did not draw the correct conclusion from the statements in G 1/19. The appellant considered that when this decision, e.g. at reasons, point 51, states that any technical effect going beyond the implementation of the process on a computer may be considered for inventive step, it means anything beyond a 1:1 mapping between the implementation and a step of the business method being implemented. In other words, any subject-matter that does not "map" to a step in the business method is technical. This was said to apply to all computer-implemented inventions, such as the present case, not just simulations. Accordingly, at least the "operating tags", which did not "map" to a step in the business method, were technical.

The Board agrees that the "implementation" of a business method implies some sort of mapping between non-technical steps of the business method and their technical realisation. Decision G 1/19 has something to say about this mapping, at least in the forward direction, at point 51, when it rephrases the requirement for technical effect as "technical effect going beyond the simulation's straightforward or unspecified implementation on a standard computer system". Thus, even a 1:1 mapping might be inventive if it is not "straight-forward" (e.g. not standard programming or routine modification of the technical means used), or "unspecified" (e.g. not simply as "means for [carrying out the step]").

But, looking for a mapping from implementation to a step of the business method in the reverse direction does not make sense as the steps of the non-technical activity do not have to be specified explicitly. They would include any steps that the business person would come up with in a non-technical workflow. The way this is handled is by considering the mapping of the implementation to the effect of the step and to examine whether the effect has any technical character, or whether it would be covered by what the business person would consider as part of the non-technical process. This is, in other words, the standard COMVIK approach where one looks at the effect of a feature in order to pose a technical problem, which might simply be the implementation of the feature, for which the above-mentioned mapping in the forward direction meant in G 1/19 applies.

Thus, looking at the feature of the "operating tags" in the present case, the effect, as mentioned above at point 2.15, is to define business conditions deter-mining whether a certain task shall be executed or not. This, of course, corresponds to a non-technical step of the workflow system, namely keeping track of the state of a process. Going forward again with the mapping in order to judge inventive step, the implementation is seen to be the use of "operating tags", which even if escaping the "unspecified" classification must surely be "straight-forward".

Furthermore, the Board cannot recognise that avoiding the folder data structure of D1, as argued by the appellant, represents a technical effect.

2.19 The present case is rather comparable to T 894/10, reasons, points 7 and 8, in which the present Board, in a different composition, held that all aspects of the idea of modelling and manipulating representations of a workflow are fundamentally non-technical, being essentially aspects of either a business method or an algorithm or both. [...] Technical considerations only come into play when implementing the representation and rules.