T 1249/22 (Development and deployment of analytical models/ACCENTURE) 13-01-2025

Reasons for the Decision

The invention

1. The application relates to the development - including the training - of an analytical model (e.g. a machine learning model) and the deployment of the trained analytical model on a "compute engine" so as to process live incoming data.

2. The application indicates as aim to allow domain experts, as well as data scientists and data engineers, to carry out these tasks quickly and easily (paragraphs [0021], [0022], [0112] of the original description).

3. To meet this aim, the application discloses in particular a graphical user interface to manage and deploy different analytical models across different run time environments that creates a layer of abstraction between the user managing the models and the target run time environments (paragraphs [0050], [0051], [0083], [0112]; figures 7-9).

However, the method of independent claim 5 of the main request is not concerned with that graphical user interface but specifies instead the steps of a process for developing and applying an analytical model to incoming data together with how this process is implemented in a computer environment.

4. The method of independent claim 5 of the main request involves essentially the following steps (with an itemisation by the board):

M1 receiving a selection (e.g. by a user) of an

analytical model

M2 training the analytical model to create a

trained analytical model

S1 storing the trained analytical model in

a "model storage database (106)"

S2 storing metadata comprising storage location

specifiers for the trained analytical model,

(later) results and an analytical model

parameter

M3 receiving a selection (e.g. by a user) of the

trained analytical model

S3 retrieving the corresponding metadata and, based

on the stored storage location specifiers, the

stored trained analytical model from the model

storage database

M4 applying the trained analytical model to process

incoming data to generate results

S4 storing the generated results in a "results

storage database (108)" as specified in the

corresponding storage location specifier

M5 monitoring the results

wherein applying the trained analytical model to incoming data to generate results and monitoring them involves:

P1 deploying the trained analytical model on a

"compute engine (118)"

P2 preparing a processing pipeline by coordinating

with an online message queue, as a data source,

to route messages including live incoming data,

by:

P3 creating a message broker topic, publishing the

source data to the topic and subscribing the

selected trained analytical model to the message

broker topic

P4 coordinating with the compute engine to implement

the selected trained analytical model to the

message broker topic

P5 coordinating with the results storage database to

store the generated results from the compute

engine

P6 writing the generated results from the compute

engine to a log file in the results storage

database as specified by the corresponding

storage location specifier

P7 monitoring the log file

and furthermore (as part of the deployment of the trained analytical model, before its execution on incoming data):

R1 determining a resource load and an execution

time for the trained analytical model using

historical data for execution of the trained

analytical model

R2 determining a resource load capability of the

compute engine

R3 determining an execution frequency for the

trained analytical model on the compute engine

based on the resource load, the execution time

for the trained analytical model and the resource

load capability of the compute engine.

Independent claim 5 also specifies that

I1 steps M1, M2, S1, S2 are performed by a "model

builder circuitry (102)"

I2 steps M3, S3, M4, S4, M5 (and thus P1-P7) are

performed by a "model deployment circuitry

(104)"

I3 steps R1-R3 are performed by a "resource

allocation circuitry (116)".

5. According to the description, the "model builder circuitry (102)", the "model deployment circuitry (104)" and the "resource allocation circuitry (116)" may be wholly implemented by the processor and the memory of a "single machine" and corresponding instructions stored in the memory (paragraphs [0023], [0028]-[0030]).

The "model storage database (106)" and the "results storage database (108)" may be implemented in the memory of the machine (paragraphs [0028], [0046]).

The "compute engine (118)" may be a "third-party cloud computing service" accessed by the machine (paragraph [0031]).

6. Step S2 is said to have the effect that "the machine 100 has a reference to where the trained analytical model is persisted and how it can be used to make predictions on incoming data and batch data" (paragraph [0047]).

Steps R1-R3 are said to address the "technical problem [...] that multiple analytical models will often run in parallel and thus compete for resources (e.g., CPU power and memory space)" (paragraph [0052]). The determined "execution frequency" may be a maximum execution frequency (paragraph [0057]). The "resource allocation circuitry" may schedule execution of the trained analytical model by the compute engine no more frequently than that maximum execution frequency (paragraph [0059]). Alternatively, it may make "recommendations as to increasing the amount of available resources in order to implement processing of an analytical model according to a desired frequency" (paragraph [0052]).

Inventive step - the reasoning of the examining division

7. The examining division found that the independent claims of the main request lacked an inventive step in view of common general knowledge evidenced by D5 (decision, point 14).

8. In the statement of grounds of appeal, the appellant argued that D5 was not evidence of common general knowledge and that each of the chapters of D5 represented a separate piece of prior art (grounds of appeal, sections 2 and 3). The examining division had combined several distinct elements from these chapters in a mosaic-like fashion without providing any reasoning as to why the skilled person would at all have identified, singled out and combined them in the alleged fashion (grounds of appeal, see in particular page 17, last two paragraphs). The objection of lack of inventive step was "not supported and substantiated by a reasoned statement" (grounds of appeal, page 26, third paragraph from the bottom).

9. The examining division's inventive step objection focuses on independent method claim 5. It starts with a reference to section G-VII, 5.4 of the Guidelines for Examination in the EPO (relating to the problem-solution approach for claims comprising technical and non-technical features) and may be outlined as follows:

- an identification of those features of claim 5

that are technical when considered in isolation by

underlining them in the text of the claim

(decision, points 14.2 and 14.3);

- arguments as to why the thereby also identified

"non-technical features" do not contribute to a

technical effect serving a technical purpose in

the context of the invention and do thus not

contribute to the technical character of the

claimed invention (decision, points 14.4 and

14.5);

- arguments as to why, "when considering only the

technical features of claim 5", these features

"comprise only normal technical considerations

of data processing in the context of

distributed computing, forming part of the

common general knowledge of the skilled person";

with several passages of chapters of book D5 cited

as evidence of common general knowledge relevant

for technical features grouped in groups "A"

to "D" (decision, point 14.6);

- a conclusion that "by using common general

knowledge and applying trivial design choices,

the skilled person would arrive at the subject-

matter of claim 5 in order to satisfy non-

technical requirements related to the training

and use of an analytical model to generate

results based on inputs, without exercising

inventive skill" (decision, point 14.7).

10. The board notes that the examining division did not select a particular piece of prior art as starting point for the assessment of inventive step (as suggested in the Guidelines, G-VII, 5.4, fourth paragraph, point (ii)).

The board does not find fault in this aspect of the examining division's argumentation.

In the case of an invention that amounts to a technical implementation of a non-technical method (provided the "non-technical method" does not contribute to the technical character of the invention), the board considers it to be a valid approach to

- identify, on the one hand, the non-technical method underlying the invention, and, on the other hand, the features of its technical implementation,

- define as "technical problem" to provide a technical implementation of that non-technical method, provided to the (technically) skilled person as a "non-technical requirement specification" which is part of the technical problem,

- assess whether the skilled person would have solved this technical problem by providing the claimed technical implementation (if so, the claim is not inventive).

Such an approach has been applied in several board of appeal decisions, for instance in T 1027/06 Rewards programs/MARITZ.

11. In this approach, the choice of the IT infrastructure on which the non-technical method is to be implemented is considered to be part of the technical solution and the assessment of inventive step includes assessing whether it would have been obvious to the skilled person to select this IT infrastructure to implement the non-technical method. This is in contrast to starting from that IT infrastructure as "closest prior art" and formulating the (objective) technical problem as to provide an implementation of the non-technical method on that IT infrastructure.

In cases where the IT infrastructure used in the invention is a computer system that is commonly used to implement methods of the same kind as the non-technical method (e.g. a generic computer for most applications or a generic client-server architecture for e-business applications), there will be no difference in result between both approaches. There could however be a difference where the choice of a specific IT infrastructure might not have been a straightforward one for the given non-technical method (as noted in T 1325/17 Location-based dating/LOCATOR, reasons 10.2).

12. Re the non-technical features and requirements

12.1 In any case, whichever approach is used, it is essential to be clear from the reasoning - at least implicitly - what the technical problem and the non-technical requirements included in it are.

The examining division's argumentation is deficient in this respect.

12.2 First, this is mainly due to the fact that the examining division identifies "technical features" of the claimed subject-matter merely by underlining parts of the text of claim 5 and implies that the remainder of the claim are its "non-technical features" (decision, points 14.2 and 14.3).

Parts of this analysis are reproduced here:

"A method (400) comprising:

receiving (402) a selection of an analytical model by model builder circuitry (102) via a communication interface (208);

training (404) the analytical model by the model builder circuitry (102) to create a trained analytical model;

storing (406) the trained analytical model by the model builder (102) circuitry in a model storage database (106);

receiving (410) by model deployment circuitry (104) via the communication interface (208) a selection of the trained analytical model;

[...]

the method (400) further comprising:

storing (408), by the model builder circuitry (102), model metadata (328) corresponding to the trained analytical model in a model metadata store (112, 242);

[...]

wherein deploying (414) the trained analytical model on a compute engine (118) to process incoming data and to generate results further comprises:

preparing a processing pipeline by coordinating with an online message queue (120), as a data source, to route messages including live incoming data,

wherein preparing the processing pipeline includes:

creating an message broker topic, publishing the source data to the topic and subscribing the selected trained analytical model to the message broker topic,

coordinating with the compute engine (118) to implement the selected trained analytical model on the live incoming data, and

coordinating with the results storage database (108) to store the generated results from the compute engine (118),

wherein the generated results from the compute engine (118) are written to a log file in the results storage database (108) specified by the storage location specifier (338), and

monitoring the log file;

the method (400) further comprising:

determining (502), by resource allocation circuitry (116) coupled to the model deployment circuitry (104), a resource load and an execution time for the trained analytical model using historical data for execution of the trained analytical model; and

determining (508) by the resource allocation circuitry (116), a resource load capability of the compute engine (118); and

determining (508) by the resource allocation circuitry (116) an execution frequency for the trained analytical model on the compute engine (118) based on the resource load, the execution time for the trained analytical model and the resource load capability of the compute engine (118)."

Such an identification by mere underlining of words (or even only parts of words, see e.g. "model metadata store") does not result in two sets of meaningful features but in two separate bags of words.

Claim 5 stripped of all the underlined parts does also not represent meaningful "non-technical requirements" that may be included in a technical problem provided to a skilled person.

In simple cases, it may be possible to somehow "reconstruct" from the two bags of words what the respective sets of (meaningful) technical and non-technical features and thus the non-technical requirements are, but this is not the case here.

Underlining words in the text of a claim to identify what is considered "technical" is normally not sufficient to clearly identify the technical and non-technical features of the claimed subject-matter.

12.3 The examining division states in point 14.4 of the decision that

"As it can be concluded from [the non-underlined parts of claim 5], the non-technical features of claim 5 are features related to an analytical model, the training of the analytical model and the creation of a trained analytical model, the analytical model parameter (being a result of the training), and the generation of results by the trained model using incoming data, given that both incoming data and 'results' are of unspecified nature and context."

While this indicates what the non-underlined parts of the claim relate to, it does not provide a clear specification of the non-technical features and thus of the "non-technical requirements".

12.4 The examining division provides in point 14.6 of the decision the following grouping of technical features:

A: "circuitry receiving data via communication

interface, processing data, and storing (file)

data in a database, using storage location

specifiers";

B: "circuitry receiving via a communication

interface a selection to deploy a processing

application based on stored data retrieved

using storage location specifiers, and

deploying the processing application on a

compute engine to process data and generate

results";

C: "a processing pipeline prepared by creating a

message broker topic used for publishing source

data as live incoming data and subscribing to

the message broker topic in order to retrieve

the live incoming data";

D: "circuitry for determining a resource load and

execution time of the processing using

his to ri cal data for execution, determining a

resource load capability of the processing

engine, and determining an execution frequency

for the processing based on the resource load

and the execution time of the processing and

the resource load capability of the compute

engine".

Such a presentation could in principle clarify what the technical features of the claimed subject-matter are. In the present case, however, it is unclear whether it is meant to contain all the technical features, or to be only a summary of them: for instance, group C appears to include far fewer features related to the "processing pipeline" than those that were underlined in point 14.3 of the decision (see point 12.2 above).

In any case, even if the presentation was meant to cover all the technical features, it is not clear what (all) the non-technical features and the non-technical requirements are.

12.5 The board notes that in points 14.26 and 14.27 of the decision, the examining division indicates (in a section replying to arguments of the appellants):

"The examining division considers that combining different features forming part of the common general knowledge of a field is part of the routine work of the skilled person to address various technical requirements in this context.

In the identified technical features for example, 'A' and 'B' address a requirement for application deployment for data processing, 'C' addressed the requirement of data exchange while 'D' addresses the requirement of scheduling."

It is not clear whether the three "requirements" mentioned in the second paragraph correspond to the "non-technical requirements" mentioned in point 14.7 of the decision ("the skilled person would arrive at the subject-matter of claim 5 in order to satisfy non-technical requirements related to the training and use of an analytical model to generate results based on inputs, without exercising inventive skill"). First, these three requirements are introduced as "technical requirements" in the first paragraph. Secondly, at least the "requirement of scheduling" appears to refer to a scheduling of the execution of the trained model on the compute engine on the basis of the "resource allocation" features (see point 6 above), which have been underlined and thus considered technical for the most part by the examining division (see point 12.2 above). It is not clear which aspect of scheduling - considered technical by the examining division - could have been included in the "non-technical requirements" mentioned in point 14.7 of the decision.

12.6 Hence, the board cannot derive from the decision, what precisely the examining division considered to be the non-technical features of the method of claim 5 and thus the "non-technical requirements" referred to in point 14.7 of the decision.

The board is therefore not in a position to review whether the technical problem including the "non-technical requirements" has been correctly defined.

Already for this reason, the board considers the decision not to be sufficiently "reasoned" within the meaning of Rule 111(2) EPC.

13. Re the technical features

13.1 The examining division specifies the technical features "A" to "D" stripped of all the alleged non-technical aspects (e.g. decision, point 14.6: "storing (file) data in a database, using storage location specifiers", without indicating that the storage location specifiers are inter alia for the trained analytical model) and appears then to only assess their obviousness in isolation of the rest of the claim (decision, point 14.6: "When considering only the technical features of claim 5, [...]").

This is however not sufficient to show that the skilled person, confronted with the technical problem including the non-technical requirements, would have arrived at the claimed technical implementation of the non-technical method.

In this exercise, it is normally not possible to perform a meaningful obviousness analysis by completely disregarding the non-technical aspects of the claim, as they are normally the raison d' tre for the claimed combination of technical features relating to their implementation. This is taken account of by including these non-technical aspects in the technical problem as non-technical requirements (in accordance with T 641/00 Two identities/COMVIK, headnote II). This, in turn, ensures that an inventive step will not be found because the non-technical aspects are non-obvious, as required by the principle expressed in T 641/00, headnote I, that only features contributing to the technical character of a claimed invention may support the presence of an inventive step.

In T 688/05 Ticket auctioning system/TICKETMASTER, headnote and reasons 4.5, similar considerations were expressed by saying that features making no technical contribution "may well form the only logical link between technical features resulting from their implementation" and that "they must therefore be taken into consideration for the examination as to inventive step while at the same time not being permitted to contribute to it." This is, for instance, what is done in T 1027/06 (cited above), reasons 10.

13.2 In some cases, it is possible to treat groups of technical features separately from each other, but this requires a proper definition of the respective partial technical problems solved by them and an explanation of why this approach is justified in the case at hand.

It may also be possible to argue that a skilled person confronted with the general technical problem of providing a technical implementation of a given non-technical method, after having selected a particular IT infrastructure in a first step towards a solution, would necessarily have been confronted with several separate sub-problems arising when having to implement the non-technical method on that IT infrastructure (see e.g. T 1158/02 Vehicle web access/ICO SERVICES, reasons 3.9, for similar considerations).

But none of this has been argued by the examining division.

13.3 The examining division also does not explain why the skilled person would have chosen grid computing (the topic of book D5) as the IT infrastructure for the implementation.

It is not clear to the board whether the examining division considered the technical problem to include the requirement that the non-technical method is to be implemented on such kind of IT infrastructure (and, if so, why such a definition of the technical problem would be justified) or whether the examining division considered it to be an obvious choice for developing and deploying analytical models.

13.4 The examining division's argumentation also lacks motivation - starting from the technical problem including the non-technical requirements - for applying common general knowledge or prior art relating to "the known paradigm of message-based grid computing"

(invoked in respect of group C) and to "the known principle of using historical data of resource information through monitoring resources in order to determine the scheduling (i.e. execution frequency) of applications" (invoked in respect of group D).

13.5 Furthermore, in particular in respect of groups C and D, the examining division's remains very general without giving sufficient consideration to the exact wording of the respective claim features. The verbatim quotations of passages from D5 does not fill this gap in the reasoning as they do not readily reflect the claim features. Also, as already noted above, the summary of the technical features falling into group C in point 14.6 of the decision does not comprise all the related features underlined in point 14.3.

13.6 Hence, the board considers that also for these reasons the decision is not sufficiently reasoned within the meaning of Rule 111(2) EPC.

14. Re D5 as evidence of alleged common general knowledge

14.1 D5 is a book titled "Grid Computing: Making the Global Infrastructure a Reality" that comprises a collection of 43 individual papers on this topic, all from different groups of authors, which are referred to as "chapters". In the initial chapter, the editors of the book state:

"This book, Grid Computing: Making the Global Infrastructure a Reality, [1] brings together many of the major projects that are driving and shaping an emerging global Grid. In the chapters of this book you will find the perspectives of a pioneering group of Grid developers, researchers and application scientists whose vision forms the present and provides a view into the future of Grid computing."

14.2 The board agrees with the appellant that in the present case a priori each of the "chapters" represent a separate piece of prior art, as they appear to be self-contained papers which do not build on each other, unlike chapters of a textbook. Definitions given in one of these papers do not necessarily apply to the others. D5 rather resembles a conference proceedings volume including a collection of separate papers related to a common topic, as also argued by the appellant. The mere fact that the papers are published in the same book, which has a single ISBN (as noted by the examining division), does not imply that the whole content of such a book forms a single piece of prior art.

14.3 As to whether D5, or its individual chapters, is generally suitable as evidence for common general knowledge, the board notes the following.

An obviousness argument based on common general knowledge normally involves an allegation that some teaching was common general knowledge and that the skilled person would have relied on it to solve the technical problem and would thereby have arrived at a number of features. The allegation that this teaching was common general knowledge may be supported by specific evidence.

The deciding body will judge whether the cited evidence establishes that the teaching in question was common general knowledge by applying the principle of free evaluation of evidence on a case-by-case basis, as is generally the case for evaluation of evidence in proceedings before the EPO (see G 2/21, reasons 27 et seq.). This means that while it may be relevant whether the cited evidence is a "book" or a "textbook", this fact cannot be on its own decisive, as there cannot be firm rules according which certain type of evidence are, or are not, convincing (G 2/21, reasons 34).

Not everything that is written in a book or even a textbook was necessarily common general knowledge at the time of its publication. It is true that information often appears in a textbook because it was common general knowledge when the book was drafted. However, this does not mean that any information contained in a textbook must have been common general knowledge before the textbook was written, nor even that it must have become common general knowledge with the publication of the textbook. For instance, a textbook may comprise a section in which the author presents a particular software that has been developed in their research group. The details of this software disclosed in the book will not necessarily have been "common general knowledge" beforehand nor will they become common general knowledge merely due to the publication of the textbook.

On the other hand, a statement in the background section of a scientific paper explaining that something was a common measure to achieve a particular effect may, depending on circumstances, be considered to establish that this measure was common general knowledge, even though the cited evidence is not a textbook. This may also be case if that same measure is used for the same purpose in several papers by different authors.

14.4 The examining division refers in point 14.23 of the decision to section G-VII, 3.1 of the Guidelines for Examination in the EPO, in which it is stated:

"Information does not become common general knowledge because it has been published in a particular textbook, reference work, etc.; on the contrary, it appears in books of this kind because it is already common general knowledge (see T 766/91). This means that the information in such a publication must have already become part of common general knowledge some time before the date of publication" (emphasis added).

The board notes that the considerations expressed in point 14.3 above are consistent with those made in the board of appeal decision cited in this section of the Guidelines, namely T 766/91 Decorative laminates/BOEING, which only describe what is "normally" accepted and what is "usually" the case (see reasons 8.2). The board also notes, in accordance with Article 20(2) RPBA, that the Guidelines have lost this nuance when saying "must" in the passage cited above.

14.5 Hence, as regards the examining division's reliance on chapters of D5 as evidence for alleged common general knowledge, there may at worst only be an error of judgement, not an issue of insufficient reasoning.

14.6 However, the board considers the examining division's reasoning to be insufficient within the meaning of Rule 111(2) EPC as regards what the alleged common general knowledge is that is being relied upon.

For instance, the examining division refers merely to the "known paradigm of message-based grid computing" in respect of group C without indicating which features of this paradigm are considered to be also common general knowledge, even though the examining division appears to rely on more than the knowledge of the existence of that paradigm when considering that all the features relating to the processing pipeline "form part of the common general knowledge of the skilled person" (decision, point 14.6).

15. The objections of lack of inventive step against the other independent claims of the main request are only substantiated by reference to the one against independent claim 5 (decision, point 14.8) and hence are insufficiently reasoned for the same reasons.

Conclusions

16. That the decision is not sufficiently reasoned within the meaning of Rule 111(2) EPC is a substantial procedural violation with the meaning of Rule 103(1)(a) EPC and a fundamental deficiency within that of Article 11 RPBA.

17. The board decides therefore to remit the case to the examining division for further prosecution, Article 111(1), second sentence, EPC and Article 11 RPBA, and that the appeal fee is to be reimbursed, Rule 103(a)(1) EPC.