T 0279/21 (State-transition-controlled processing of objects/SWISS RE) 30-01-2024

1. Background of the invention

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

1.2 Traditional workflow systems comprise at their core a workflow execution engine which controls and monitors the processing of objects. It steers a sequence of activities (work tasks), interactions and signalling with execution devices or means, or in interaction with users or IT resources, as well as rules controlling the progression of processes through the various stages associated with each activity, page 2, second paragraph.

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. This is even more complex when the central workflow execution engine is controlling decen tra lised units, see bridging paragraph, pages 2 and 3.

1.4 Another problem is that it may be necessary to adapt the processing by steps which are not predictable at the beginning of the workflow and which may depend on environmental parameters or parameters of execu tion devices or other state parameters of a certain work flow state. Prior art systems use interpreters which trans late possible process steps into a computer operation code for execution, but this requires resources and time, page 4, 1st paragraph.

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. Article 56 EPC

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 con cepts 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.2 In appeal, claim 1 of the sole request corresponds to claim 1 on which the decision is based, replacing "control system" with "electronic control system", "object" with "data object", and deleting "at least partially" in combination with the feature of an encapsulated data structure. These changes might give the claim the appearance of a higher level of technicality, but apart from the fact that the Board has doubts that they are clearly defined in the description, in particular in a situation where there is no single technical embodiment explaining how the invention works, the Board judges that they do not add anything inventive and agrees with the examining division's decision on the refused claim.

2.3 The appellant disagrees with this non-technical inter preta tion. 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 interpre tation, 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.

This is exactly how the examining division approached the present case and the Board agrees. As a whole, the application is not limited to "data objects" and to "tasks" which are processed by an electronic system, as mentioned on page 4, lines 27 et seq. of the application. This passage seems to explain that a selected object is processed by exe cu ting one or more process tasks by means of a control system from one process state to the subsequent process state. However, at the same time, the application, page 6, lines 14 to 17, and page 11, lines 10 to 12, discloses that a selected object can comprise, e.g., at least one product and/or technical object and/or data and/or claim and/or account and/or job and/or contract and/or request and/or reporting object etc., and according to page 12, lines 20 to 21, tasks may be executed by a dedicated signaling to specific people to perform activities/tasks on the objects, as well as page 17, lines 3 to 9. This contradicts page 17, second paragraph, where it is said that process tasks are executed by means of runtime execution modules.

2.5 The appellant's argument that the present invention is not concerned with the modelling of workflows is not convincing, because the application, page 13, lines 7 to 9, explicitly mentions that the process flow is modelled and generated by means of the process manage ment engine, including or based upon specific pro cessing rules and technical instructions stored in the database. Moreover, page 13, second paragraph, explains that industrial, scientific, computational or business processes are "automatically operated" by means of the central control apparatus, but the work flow process is said to be composed of, among others, a sequence of process- or work tasks and interactions with human resources. The term "automatically opera ted" therefore requires careful interpretation.

2.6 Regarding the feature "operating tag", it is said on page 10, lines 16 to 19, and page 14, lines 17 to 23, that it is assigned to an object and/or process task and comprises dynamically alterable operating para meters which control the operation of the process task by means of the control system and/or by adding operational constraints to the processing of the pro cess task. An operating para meter may be a label, such as "pending", "cleared", "processing", "in operation" or "done", which describes a task state.

Besides representing a task state, operating tags may vary in their realisation; according to page 15, line 23, to page 16, line 22, an operating tag may be (i) simply a date with the states "due" and "overdue", (ii) reflect an aspect of work e.g. Pricing, Contractual, Reporting with the states "pending" and "done", (iii) refer to the supervision by a user or a group of users e.g. "Supervisor" with the states "watching" or "escalation-pending", a.s.o., (iv) a requirement to retain the audit trail of a task with states "none", "retained" or "expired", (v) a service level agreement with the states "included" or "excluded", (vi) the level of protection with the states "public" or "confidential".

At the same time, "operational tags" seem to serve another purpose. According to page 15, lines 18 et seq., they represent meta data, e.g. comprise non-hierarchical keywords or terms assigned to an object process task, with the purpose of describing the object or process task and allowing it to be found again. They aid in classification, marking ownership, noting boundaries, and indicating identity.

It is said that the purpose of an "operating tag" is to control the operation of an associated process task, which does not seem to change the underlying workflow process, but only the execution of tasks. Operating tags are said to be set by an authorised assigner or assignee of a process task which the application does not exclude to be a human user. In other words, it would seem that a user is given the ability to access and report his/her tasks along the applied dimensions "following a single consistent model", see page 16, first paragraph, in other words following a structured approach. The appellant's argument that the invention is able to dynamically change a workflow process is therefore not convincing.

2.7 The feature "encapsulated", is not technically clear. Page 14, line 30, to page 15, line 3, of the application mentions that operating tags can comprise an encapsulated data structure which is said to provide controlled access, but it does not further explain it. At the same time the encapsulated data structure is said to comprise only partly the dynamically alterable parameters, which seems to mean that other dynamically alterable parameters are stored outside of the encapsulated data structure. The Board doubts that the technical effect of controlled access, as argued by the appellant, is achieved. The meaning of "controlled access" in association with encapsulation in the technical field rather seems to be a way to limit direct access to components of an object and to require the use of object methods. This does not seem to imply that access is limited to authorised users. Further security measures would be necessary.

2.8 The features "stochastic rating module" or "stochastic rating", are not further defined in the application. The Board agrees with the examining division that a non-technical, mathematical or business interpretation may be given to these features in terms of a rule for initiating the next process task.

2.9 D1, see [0023] to [0026], discloses that workflow rules define actions to be taken on a data object at workflow stages based on data elements of an object. The actions are dynamically assigned, see [0055], based on object state, workflow state and user profile. Moreover, a data object in D1 can be used as a representation of a business object such as a contract, an offer, a tender, or an insurance claim, see [0055].

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.13 The appellant points out that claim 1 is further distinguished from D1 by the operating tags which "... comprise an encapsulated data structure, wherein controlled access to the operational tag ... for authorized assigner units or assignee units by the encapsulated data structure ... dynamically alterable operating parameters and/or the operational constraint parameters and/or the expanding or the indicating parameters of task states ... dynamically operating the state-structured process flow ... " (listed are the high-lighted portions of claim 1, see page 14 of the grounds). The encapsulated data structure in the operating tag would permit a (dynamic) change of a workflow process during its execution in a way that another subsequent workflow state is reached from a same work flow state in a way which is not defined in advance. A user is able to interact with the process flow without the risk that the system looses control of it. This provides a certain flexibility while maintaining overall control. Furthermore, unauthorised third parties or users outside their granted access rights are prevented from influencing the process flow.

None of the prior art documents D1, D2 or D3 discloses such a data structure. D1 provides only a monitoring of work flow processes which are defined by workflow rules. An "application process" is controllable by the user, see [0020] of D1, but the workflow process must be defined in advance. Two parallel workflows may be generated, [0026] and [0027], but they follow the pre defined workflow rules. Also a dynamic assignment of actions in the workflow, [0055], does not change the workflow as such. Moreover, D1 requires a particular folder-based data structure to represent the workflow.

2.14 The Board is not convinced by these arguments. Claim 1 defines a state-structured process flow of how a selected object is processed from a pro cess state to a subsequent process state, but not a (dynamic) change of the workflow process during its execution, in other words, new tasks may be generated and assigned, but the underlying work flow or process flow does not change. This is also reflected by the two-part form of claim 1.

2.15 As mentioned above, "operating tags" serve various purposes, among others, for documentation and for controlling the execution of process tasks, but, again, this does not change the underlying process flow. Moreover, operating tags stem from the business side, as they define business conditions determining whether a certain task shall be executed or not, see page 15, line 28, to page 16, line 22. For instance, they denote the aspect of work, such as pricing, contractual, reporting, or that a task is included or excluded in a service level agreement (SLA). They cannot confer technical character to the claimed subject-matter.

2.16 The use of an "encapsulated data structure" is a commonly known pro gramming concept, see page 11, second paragraph of the impugned decision, which is known to prevent direct access to internal components of an object. Table 2 of D1 illustrates the data structure of the object used in D1. Paragraphs [0024] and [0025] explain that the values and attributes of the object cannot be accessed directly, but only via actions, e.g. view, modify, data editing or data entry, processing and validation rules. This reflects the properties of an encapsulated data structure, as it is used in the application. It is rather the nature or type of a tag which seems to limit access to an object, see page 16, lines 16 and 18, where it is said that a tag may denote the level of protection with particular states "public" or "confidential".

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.

2.20 The Board therefore concludes that the subject-matter of claim 1 lacks an inventive step over D1 within the meaning of Article 56 EPC, because the skilled person would adapt the modules of D1, see [0020][0021], with additional functions to implement new workflow rules or constraints based on common general knowledge.