T 2497/12 (Java RMI integration/MATHWORKS) of 28.6.2018

Summary of Facts and Submissions

I. The appeal is directed against the decision of the examining division, dated 18 July 2012, to refuse application No. 06740903.7 for lack of inventive step over the following document:

D1 |"Java Remote Method Invocation Specification - JDK 1.2"; October 1998; pages 1-124; XP 2967375.|

Objections regarding added subject-matter were also raised against the auxiliary request (Article 123(2) EPC).

II. A notice of appeal was received on 26 September 2012. The appeal fee was paid on the same day. A statement of grounds of appeal was received on 21 November 2012. An amended sole claim set was filed (now the main request). Oral proceedings were conditionally requested.

III. In a communication dated 6 December 2017, the rapporteur raised an objection of lack of inventive step.

IV. In a letter dated 16 February 2018, the appellant submitted arguments and filed claim sets according to a first and a second auxiliary request.

V. In its summons to oral proceedings, the board gave further reasons why the claims still lacked an inventive step.

VI. In a letter dated 25 May 2018, the appellant submitted further arguments.

VII. Oral proceedings were held on 28 June 2018. At their conclusion, the board announced its decision.

VIII. The appellant requests that the decision be set aside and that a patent be granted based on the main request, filed on 21 November 2012, or on one of the first or the second auxiliary requests, filed on 16 February 2018. The other application documents are the same as in the appealed decision.

IX. Claim 1 of the main request reads as follows:

"1. In a network including RMI (Remote Method Invocation) services, a method comprising:

providing a configuration file processed by an RMI activation system daemon, the configuration file identifying at least one non-Java application;

altering the non-Java application such that the non-Java application:

starts a Java Virtual Machine (JVM) inside the identified non-Java application using Java Native Interface (JNI),

disables automatic reading from standard input (STDIN) as direct input, and

locates classes required by the non-Java application on a classpath of the JVM;

configuring the non-Java application to accept incoming RMI calls via a Java Native Interface (JNI) so that the non-Java application communicates with Java applications using the RMI services, the non-Java application being managed by the RMI activation system daemon; and

registering the non-Java application with the RMI activation system daemon as part of a startup sequence for the non-Java application."

X. Claim 1 of the first auxiliary request reads as follows:

"1. A system in a network providing RMI (Remote Method Invocation) services, the system comprising:

an RMI activation system daemon;

a configuration file processed by the RMI activation system daemon, the configuration file identifying at least one non-Java application, the identified non-Java application being managed by the RMI activation system daemon, the RMI activation system daemon accepting a registration from the non-Java application as part of a startup sequence for the non-Java application;

a Java Virtual Machine (JVM), the JVM executing inside the identified non-Java application, the non-Java application configured: to disable reading from standard input (STDIN) as direct input, to locate classes required by the non-Java application on a classpath of the JVM, and

to accept RMI calls via a JNI (Java Native Interface) so that the non-Java application communicates with Java applications using the RMI services."

XI. In view of the appellant's statement that claim 1 of the second auxiliary request set out the same features as claim 1 of the first auxiliary request and that the same arguments held as for the first auxiliary request and in view of the fact that no additional arguments concerning the second auxiliary request were given during oral proceedings, the claim text of the second auxiliary request is immaterial to this decision.

Reasons for the Decision

1. Summary of the invention

The application relates to registering a non-Java application program with the known (Java) RMI activation system daemon (original description page 1, second paragraph). RMI (Remote Method Invocation) is a set of software protocols, developed by Sun Microsystems, to enable Java objects to invoke over a network a method (i.e. a program) of a remote Java object to be executed on the remote computer (page 1, third paragraph). The RMI activation system daemon is a known program which is started by a system administrator (page 8, second paragraph; figure 4: 128) to register remote objects whose methods are to be invoked using RMI. Once the non-Java application program has been registered with the RMI activation system, it can be invoked by a method of a remote Java object using the RMI/JNI methodology (JNI = Java Native Interface; see page 8, lines 13-14, 20-21).

2. Inventiveness

2.1 During the oral proceedings, the appellant chose to only discuss the first auxiliary request, since claim 1 of all requests set out essentially the same features.

2.2 The board agrees. The subject-matter of the claims of all requests is not materially different. All steps of method claim 1 of the main request are reflected in means set out in system claim 1 according to the first and second auxiliary requests. In particular, the steps of altering the non-Java application such that the latter starts a Java Virtual Machine (JVM), disables reading from standard input and locates classes are reflected in an altered non-Java application which is configured to perform these three steps.

2.3 While the main request relates to instructions for a human programmer to perform the steps of altering the given non-Java application, the auxiliary requests focus on the product of this alteration, i.e. the altered (or "configured") non-Java application program, claimed as a system which also contains an RMI activation system daemon and its configuration file.

2.4 Therefore, this decision only deals with the first auxiliary request. The arguments apply equally to the main request and the second auxiliary request.

2.5 The subject-matter of claim 1 of the first auxiliary request differs from the usual RMI (see for example D1) in that the application program to be called via RMI is not written in the Java programming language, and therefore has to be altered to fit into the Java RMI software framework.

2.6 The alterations, which a human programmer has to perform in the given non-Java application, comprise including a reference to the concerned non-Java application in the configuration file for the RMI activation system daemon (second feature of claim 1; see also description page 7, last line to page 8, line 2), inserting a start command for the Java Virtual Machine (JVM) program into the non-Java application (third feature of claim 1; page 7, lines 20-23), disabling reading from standard input (STDIN) in the non-Java application (also third feature; page 7, lines 25-29), locating the classes required by the non-Java application on the classpath of the JVM (still third feature; page 7, lines 29-32), adapting the non-Java application such that it accepts RMI calls via a Java Native Interface (JNI; page 8, lines 20-21), and finally programming the service constructor method so that it registers the non-Java application with the RMI activation system daemon when the service of the non-Java application is started (last part of the second feature; page 8, lines 13-15).

2.7 The technical effect of this altered non-Java application together with the RMI software is that the application can be called by another program over a network.

2.8 However, it is the well-known effect and the purpose of the RMI software to allow a program to be called by another program over a network. The board cannot identify in the present case a technical effect which goes beyond the usual effects of using the Java remote method invocation (RMI).

2.9 In the letter of reply (page 6, last paragraph), the appellant alleges a technical effect of enabling an efficient communication between Java and non-Java applications. During the oral proceedings, the appellant formulated the technical effect slightly differently, namely to enable interoperability of non-Java programs with Java programs.

2.10 However, in the claimed invention, the terms "communi­cation" and "interoperability" only relate to Java RMI. Thus, the alleged technical effect reads: enabling ("altering") a non-Java applications to be called by a Java application using the Java RMI software and its protocol set. An increase in the efficiency of the RMI methodology was neither alleged by the appellant, nor identi­fied by the board.

2.11 It follows that there is no technical effect emerging from the communication or interoperating of the two programs (the non-Java application and the RMI software) which goes beyond the effects achieved by either of these two programs.

2.12 However, in order that program features (which stem from the field of "programs for computer" excluded as such from patentability under Article 52(2) and (3) EPC) contribute to an inventive step, such a technical effect would be necessary. Merely adapting one program to work together with another program is not enough. This is a matter of programming, which itself is a mental act (also as such excluded from patentability under Article 52(2) and (3) EPC) unless it serves to achieve in a causal way a technical effect in the context of a concrete application or environment (see, for example, T 1539/09, section 4.2, second sentence and T 423/11, sections 3.6 and 3.9). The combination of the two programs should produce a technical effect going beyond the sum of effects of the two programs, in order to qualify the adapting program features as contributing to an inventive step.

2.13 In the letter of reply, dated 16 February 2018 (page 7, first paragraph), the appellant also alleges a technical effect of overcoming the limitations of a conventional homogeneous RMI environment.

2.14 However, this effect also lacks technical character, since these limitations have been programmed on purpose into the Java RMI software by human programmers. Therefore, the limitations themselves lack technical character.

2.15 Furthermore, the reason why the application program to be coupled with the Java RMI software is not written in Java is not a technical one. It is the wish to reuse existing legacy programs, e.g. for commercial or organisational reasons. Thus, the motivation to adapt the non-Java programs instead of writing a Java program which realises the same functionality as the non-Java program is not a technical one and cannot form the basis of a technical effect.

2.16 Therefore, the claimed subject-matter is considered not to be inventive. As stated above, this also holds for the other requests.

Order

For these reasons it is decided that:

The appeal is dismissed.