T 0702/08 (Process monitoring/SAP) of 9.1.2013

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division to refuse European patent application No. 03029396.3, entitled "Process management monitoring", for lack of inventive step (Article 56 EPC 1973).

II. The examining division considered twelve requests and found the claimed monitoring methods to be obvious over a task management system according to D1,

D1: US-A-6 101 481,

which provided central rules for defining the status of process objects. The alternative approach of providing rules object by object, within each process object, was said to reflect the skilled person's obvious desire to specify different rules for different process objects. A technical problem existed only in relation to the implementation of that requirement.

III. The appellant requests that the decision under appeal be set aside and a patent be granted on the basis of claims 1 to 17 filed with letter dated 30 November 2012 (received on 3 December 2012) in response to the Board's summons to oral proceedings.

IV. Claim 1 reads:

"1. A computer-implemented method for providing process monitoring functionality, with the steps of

defining a process object (300) with multiple task objects (302, 304, 306, 308) linked to the process object (300),

defining for each of the task objects (302, 304, 306, 308) at least one activity status, wherein each of the task objects (302, 304, 306, 308) comprises different statuses, wherein the activity status relevant for a process object status is extracted,

executing rules on the activity statuses of said task objects (302, 304, 306, 208) to determine said process object status of the process object (300),

characterised in that

said rules are provided within said process object (300), said rules defining a process flow for determining the process object status of the process object (300) based on the individual activity statuses of the task objects (302, 304, 306, 308), wherein the process flow is characterized by pre-requisites of sub-task statuses and/or activity statuses which have to be matched to reach a certain process object status and/or activity status, respectively and wherein the rules define interdependence of the statuses of the respective tasks and sub-tasks."

V. The appellant has argued essentially as follows:

The use of business objects allowed real world objects to be described. As rules were provided within the process object, the rules depended on the individual process object. The rules allowed a project leader to obtain a quick overview of the statuses of process and task objects. The efficiency of task management was improved and processes were prevented from incorrect changes. Increasing the ease of maintenance, allowing cross-environment process monitoring and preventing incorrect changes in processes were technical problems. Thus, the claimed method went beyond a mere implementation of different rules.

With respect to D1, a technical problem to be solved was how to improve the control of a product development process. The development process was said to be significantly improved as lock-ups during the product design could be avoided, and users obtained an overview of the progress and interaction of numerous tasks.

The claimed method comprised technical aspects in that it provided functionality for monitoring workflow processes, notably a product development process. The accomplishment of mile stones in a complex process (having a plurality of (sub-)tasks with complex interrelationships) could be monitored even by unskilled users having no detailed knowledge of the process. Object-oriented, rule-based program and data structures (as exemplified by Figure 3 of the application) were technical means chosen by the inventors to turn a simple user interface into a tool for monitoring heterogeneous processes and for controlling those processes safely with the help of predetermined rules. In object-oriented programming, rules provided "within" an object represented an additional distinction achieving object-specific effects.

VI. Oral proceedings before the Board took place on 9 January 2013.

Reasons for the decision

1. The application

The application was published as

A1: EP-A1-1 544 763 (22 June 2005).

Rules use the activity status of a task to determine the status of a process comprising that task. The application deals inter alia with "trial management software" (A1, paragraph 0004) to optimise a "product development process" (paragraphs 0001/0002). A "business process" may be designed, using various "business objects", and tested as a "trial process" (paragraph 0009) or "trial business object" (paragraph 0061) or "trial business process object" (paragraph 0073, Figure 3). Rules defining inter-dependencies of (sub-)tasks allow the simulation of a process flow (paragraphs 0007 and 0064). Paragraph 0013 summarises aims and features of the monitoring method.

2. Construction of claim 1

2.1 The Board considers the term "object" in claim 1 to have a broad meaning encompassing the general concept of a "goal" or "objective" at an administrative management level.

The description does not unambiguously correlate its various (business and process) "objects" with object-oriented programming; the latter term is actually not used in the application. Even Figure 3, referenced by the appellant as an implicit example of object-oriented programming, shows a "data structure" (A1, column 6, line 33) rather than any program module or programming technique.

2.2 "Statuses" and "rules" also constitute mental concepts rather than technical features. Apart from the computer-implementation mentioned in the first line of the claim, claim 1 mostly consists of steps for "defining" a process flow and vocabulary for describing its inter-related process elements rather than a description of technical tasks and features thereof.

2.3 Although the claim seeks to define objects, processes, (sub-)tasks and rules in several (partially redundant) ways, the claim refers to them in such general terms that they may be embodied in any technical or non-technical form (including a shopping list).

2.4 Regarding the technical aspects asserted by the appellant (object-oriented programming; complexity of process; user interface; product development), the Board notes that claim 1 is not limited to any such aspect. Even if the process flow mentioned in the claim were to be specified as a (generic) product development process, the process constituents would still be abstract non-technical concepts in an information model.

3. Article 56 EPC 1973 - Inventive step

3.1 Only steps contributing to the technical character of a method enter into the examination for inventive step (T 641/00-Two identities/COMVIK, Headnote 1, OJ EPO 2003, 352).

Claim 1 covers the concept of monitoring a generic process flow achieving any technical or non-technical effect.

Therefore, the Board does not take the underlying process concept or model into account under Article 56 EPC 1973.

3.2 At the same time, a computer-implementation (including a graphical user interface, for example) represents a notorious technical means for automating and supporting a monitoring function. The Board judges that the monitoring functionality outlined by claim 1 does not imply any inventive step at the implementation level.

3.3 Therefore, claim 1 does not meet the requirements of Article 56 EPC 1973.

ORDER

For these reasons it is decided that:

The appeal is dismissed.