T 1713/07 (Logical routing system/OPENDESIGN) of 18.5.2010

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division dispatched 9 May 2007, refusing European patent application No. 02720981.6 for lack of inventive step (Article 56 EPC 1973) over prior art document:

D1: EP 0817444 A2.

II. The notice of appeal was received on 19 July 2007. The appeal fee was paid on the same day. With the statement setting out the grounds of appeal received on 19 September 2007, the appellant requested that the appealed decision be set aside and that a patent be granted on the basis of claims 1 to 27 as filed with letter dated 7 July 2006 (main request) or claims 1 to 7 as submitted with the statement setting out the grounds of appeal (auxiliary request 1). A further auxiliary request for oral proceedings was made.

III. A summons to oral proceedings to be held on 18 May 2010 was issued on 5 March 2010. In an annex accompanying the summons the board expressed the preliminary opinion that the subject-matter of independent claim 1 of the main request appeared to lack novelty (Article 54(2) EPC 1973) over the disclosure of D1, and claim 1 of the auxiliary request, apart from infringing the requirements of Article 84 EPC 1973 and of Article 123(2) EPC, was considered to be obvious (Article 56 EPC 1973) in the light of the disclosure of D1 when combined with the skilled person's common general knowledge. The board gave its reasons for the objections and why the appellant's arguments were not convincing.

IV. With a letter dated 16 April 2010 the appellant filed three sets of amended claims 1 and 16 according to a new main request and auxiliary requests 2 and 3. However, no arguments supporting an inventive step of these claims were presented.

V. Oral proceedings were held on 18 May 2010 in the course of which the appellant's representative withdrew auxiliary requests 1 and 3 and presented arguments in favour of an inventive step of the main request and the remaining auxiliary request 2.

VI. Independent claim 1 of the main request reads as follows:

"1. A method in a client node for sending a message to a remote application node that corresponds to a logical destination identifier, the logical destination identifier identifying an application running at that application node and being known to a client application running at the client node, the method comprising:

registering by said remote running application a mapping between its logical destination identifier and a physical identifier of the application node at which the remote application is currently executing;

sending the message, by the client application running at the client node, the sending including passing the message and the logical destination identifier to a send logical message function provided by the logical routing layer of the client node;

resolving, by the send logical message function of the logical routing layer, the registered physical identifier of the application node corresponding to said logical destination identifier, said resolving being done independently from the client application;

sending the message to said application node by invoking a send message function of the physical routing layer of the client node, said physical routing layer mapping the resolved physical identifier to a network address of the application node,

wherein the physical layer of the client node provides said mapping between physical identifiers and network addresses independently from that logical routing layer."

A further independent claim 16 is directed to a corresponding logical routing system.

VII. Independent claim 1 of the remaining auxiliary request comprises the following additional features:

"performing a log on by a user to a selected remote application node,

in response to the log on, registering the user with the logical routing system using as logical identifier the user´s name,

wherein when another user wants to send a message to said user, using said user´s name to identify the user to the logical routing system,

transmitting the message to said user in the same way messages to remote application nodes are transmitted by sending the message to said remote application node to which the user has logged on,

displaying the message to the user by a program running at the remote application node to which said user is logged on."

A further independent claim 16 is directed to a corresponding logical routing system.

VIII. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of claims 1 to 27 filed with letter dated 7 July 2006 with amended versions of claims 1 and 16 filed with letter dated 16 April 2010 (main request) or on the basis of claims 1 to 27 filed with letter dated 7 July 2006 with amended versions of claims 1 and 16 filed with letter dated 16 April 2010 and titled "New auxiliary claim set 2" (auxiliary request).

IX. After deliberation the board announced its decision.

Reasons for the Decision

1. Admissibility of the appeal

The appeal is admissible.

Main request

2. Inventive step (Article 56 EPC 1973)

The appellant's central argument was that the invention suggested a new approach in the design of applications by relieving the application program from the task to resolve the logical identifier to the registered physical identifier and by relieving the logical routing layer from resolving the registered physical identifier to the actual network address. In contrast to the claimed invention, D1 as closest prior art did not suggest a separation between the application layer, the logical layer and the physical layer. In particular, the word "it" in column 4, lines 25, 29 and 33 of D1 clearly suggested that the application (to which the word "it" referred) was involved in the process of name resolution.

2.1 The board agrees with the analysis of the teaching of D1 (in particular column 4, lines 10 to 44) in section II of the appealed decision. The "host_handle" as defined in column 4, line 26, of D1 has the function of identifying a server host which can provide the required service, and therefore can be regarded as a physical address of this server, i.e. a "physical identifier" as this term is used in the present application. The board considers a "host_handle" to be only a different name for the same technical feature of being a physical identifier, since it has the same function (this was also the view of the examining division, given in the second paragraph of page 4 of the decision). Hence, the board considers the feature of a physical identifier in claim 1 to be disclosed by "host_handle" in D1.

In the board's judgement, D1, column 4, line 10 onwards, therefore discloses functions which satisfy the following features of claim 1, since the same functions are provided by them for the same purpose:

- the client application (see line 15: service_handle = name_service_lookup("movie") with "movie" as the logical identifier),

- the send logical message function of the logical routing layer (see line 26: host_handle = name_hostname_lookup (service_handle) with the "host_handle" being a physical address) and

- the send message function of the physical routing layer (see line 35 to 36: host_IP_address = nome[sic]_hostaddress_lookup (host_handle) with "host_IP_address" being the network address).

2.2 According to the disclosure of D1, the client application (referred to as "it" by the appellant in section 2 above) makes a "procedure call to the name resolver" (column 4, line 13). In lines 41 to 43 of column 4 it is disclosed as an alternative solution for an implementation that "the caller simply specifies the name ..., and the name lookup returns to the caller the IP address of a host" (emphasis added). From this disclosure the skilled person would understand that the client application only initiates the call and the handling of the name resolving takes place independently from the client application. In particular, the resolving of the physical identifier to the network address explicitly happens independently from the client application, because the IP address is returned to the calling application.

According to the well known OSI layered model a higher layer never provides a service to a lower layer. If an application "calls" a resolver (as is the case in D1) for a resolving activity, then the board considers that this resolver is no more part of the application itself than are the services provided in the present application. As a consequence, all the resolving activities in D1 are interpreted as not being part of the application, but instead only being initiated by the application.

2.3 The central idea behind having different layers (as in the well known OSI model) is the principle of modules for increasing flexibility. This was undoubtedly common general knowledge before the effective priority date of the present application and D1 itself addresses an implementation of the name resolver by the use of multiple functions and program modules (see column 5, line 30 and lines 52 to 56). The skilled reader of D1 when trying to solve the objective problem of how to relieve the application, would therefore consider the use of a modular structure for the communication software and use such a modular structure to relieve the client application of the handling of resolving the logical identifier to the registered physical identifier, and of the handling of resolving the physical identifier to the network address. This is not regarded as a surprising and unexpected effect which involves an inventive activity when starting from D1 as closest prior art, knowing about the domain name service DNS standard (see column 1 of D1 and the paragraph bridging pages 1 and 2 of the present application) and about the OSI model standard, in particular in the light of the advantages disclosed in column 2, line 40 onwards of D1.

2.4 The board agrees with the argument of the appellant that there is a difference between the disclosure of D1 and the teaching of claim 1 in that according to D1 the client receives the IP address from the name resolver and the client has to use this address for sending a message to the identified application server, whereas according to claim 1 the message is directly passed on to the identified remote application without returning the IP address to the client program. The alleged effect is that with the claimed method a programmer does not have to care for the handling of the received IP address.

However, this difference is considered to be a mere design alternative within the knowledge of the skilled person in the field who would consider only involving the name resolver once as an obvious alternative to involving it in every message in order to improve efficiency (in particular in the light of D1, column 4, lines 39 to 46).

2.5 Furthermore, D1 discloses a step of registering with a name resolution lookup table in which logical identifiers and physical identifiers are mapped (see column 2, lines 20 to 31). It is not explicitly disclosed that this registering is performed by the remote running application. However, the board judges that it was state of the art to register a mapping either via a network manager or via the application itself (e.g. the domain name service DNS) according to the corresponding feature of claim 1 (in agreement with the reasoning by the examining division in the paragraph bridging pages 5 and 6 of the decision). The present patent application itself indicates that both application nodes and client nodes can register when needed (see in particular page 4, last paragraph, and page 15, last line). Selecting one of the possibilities ("registering by said remote running application") without any surprising and unexpected effect does not involve an inventive step.

Therefore, the board considers it to be obvious to implement the name resolver in D1 using a separate logical routing layer and physical routing layer according to claim 1 in the light of the skilled person's common general knowledge. Thus, the subject-matter of claim 1 lacks an inventive step (Article 56 EPC 1973).

Auxiliary request

Admissibility of the request

3. Claim 1 of this request introduces aspects from the description of the present application at a late stage of the appeal proceedings which have not been claimed before. Despite meeting the time limit of one month before the appointed date of the oral proceedings as set in the summons for oral proceedings before the board of appeal, this is in conflict with the requirements of Article 12(2) RPBA. According to Articles 12(4) and 13(1) RPBA the board therefore has a discretion not to admit such amendments. According to Article 13(3) RPBA amendments sought to be made after oral proceedings have been arranged (as is the case here) shall not be admitted if they raise issues which the board cannot reasonably be expected to deal with without adjournment of the oral proceedings. No arguments supporting the patentability of the amended claims were made by the appellant before the oral proceedings. However, since the board could deal with the amended claims introduced with this request without the need to adjourn the oral proceedings, the request was admitted into the proceedings according to Article 13(1) RPBA.

4. Requirements of Articles 84 EPC 1973 and 123(2) EPC

Claim 1 has been amended, inter alia, by adding the feature of a "logical routing system". It is not clear what the appellant intended to be comprised by such a system which is not defined in the claim, in particular because it is not clear whether such a logical routing system comprises nodes of a network or only software components such as the layers defined in the other features of claim 1. However, the board considers that D1 certainly discloses a form of "logical routing system", so that the precise intention of the appellant is not decisive for the question of inventive step. In addition, the board has doubts that the passage on page 10, second paragraph, cited by the appellant as a antecedent basis supports the wording of the added feature "transmitting the message to said user in the same way messages to remote application nodes are transmitted...", whereas the cited passage in the description discloses transmitting in the same way it transmits messages to client programs.

5. However, the afore mentioned doubts of the board not withstanding, the added features of the subject-matter of claim 1 of this request are anyway considered not to involve an inventive step for the following reasons.

5.1 In the board's view the added features amount to nothing more than a use of the method for an exchange of messages between clients in the sense of instant messaging. The appellant argued that, considering that the messages were text messages, the added features achieved the effect of exchanging messages in an alternative way to email systems. However, the board takes the view, as it did in the oral proceedings, in reaction to the argument of the appellant presented for the first time during oral proceedings, that the idea of teleconferencing by the transfer of text messages from terminal to terminal was well known before the priority date of the present application and therefore is considered to be common general knowledge of the skilled person. The board offered to introduce a citation from a standard textbook in the field of computer networks and published long before the priority date of the present application. The appellant did not in fact insist on the introduction of this document, accepting this as common general knowledge. Knowing about this well known possibility of teleconferencing, which in the case of text messages is simply instant messaging, the skilled person when locking for a solution of the problem of exchanging text information between different client programs would consider using the method of sending information disclosed in D1 (as discussed with regard to claim 1 of the main request) for this purpose without the need of inventive skills, because in D1 too information is sent in both directions between client programs and application programs. Implementing text messaging according to claim 1 of this request using the method of exchanging information disclosed in D1 is considered within the ordinary skills of a programmer.

It is further considered common place to log on a user to a computer network in order to participate in an exchange of information between different nodes of such a network. Using a user's name as the identifier is the most natural way for identifying such a user to the system.

Thus, the subject-matter of claim 1 of this request at least lacks an inventive step (Article 56 EPC 1973).

6. Therefore, neither of the two requests is allowable.

ORDER

For these reasons it is decided that:

The appeal is dismissed.