T 1378/16 (Internet connection through a NAT or firewall/NOKIA) of 8.5.2020

European Case Law Identifier: ECLI:EP:BA:2020:T137816.20200508
Date of decision: 08 May 2020
Case number: T 1378/16
Application number: 06765540.7
IPC class: H04L29/06
H04L29/12
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 366 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: System, terminal, method and computer program product or establishing a transport-level connection with a server located behind a network address translator and/or firewall
Applicant name: Nokia Technologies Oy
Opponent name: -
Board: 3.5.03
Headnote: -
Relevant legal provisions:
European Patent Convention Art 56 (2007)
European Patent Convention Art 116 (2007)
Keywords: Oral proceedings before the board
Oral proceedings - converted into a videoconference with the appellant's consent
Inventive step - (no)
Catchwords:

Oral proceedings held by videoconference before the Boards of Appeal (see Reasons, point 1).

Cited decisions:
T 1266/07
T 0195/14
T 2068/14
T 0932/16
Citing decisions:
T 1879/16

Summary of Facts and Submissions

I. This appeal is against the decision of the Examining Division refusing the present European patent application for added subject-matter (Article 123(2) EPC) and lack of inventive step (Article 56 EPC), having regard to the disclosure of

D5: WO 2004/012413 A1.

II. Oral proceedings were held by videoconference on 8 May 2020. The oral proceedings initially scheduled as an in-person hearing were - with the appellant's consent - converted into videoconference-based oral proceedings.

The appellant's final requests were that the decision under appeal be set aside and that a patent be granted on the basis of the claims of a main request or, in the alternative, of one of first to fourth auxiliary requests, all requests as filed with the statement of grounds of appeal.

At the end of the oral proceedings, the board's decision was announced.

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

"A system comprising:

an originating node (82) located in a public network and configured to send a communication request to a terminating node (84), wherein the communication request is a non-IP-based communication request message (130), and

a terminating node (84) for communicating with the originating node (82) via an IP connection, the terminating node being located in a private network and comprising: a processor configured to respond to receiving the communication request from the originating node by initiating IP-based communication with the originating node."

IV. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that, at the end of the second paragraph, "and" has been deleted and, at the end of the claim, the following wording has been added:

"wherein each of the originating node and the terminating node comprises a middleware layer, and

wherein the originating node configured [sic] to send the communication request from the middleware layer of the originating node to the middleware layer of the terminating node, and

wherein the terminating node is configured to receive the communication request at the middleware layer of the terminating node".

V. Claim 1 of the second auxiliary request differs from claim 1 of the main request in that, at the end of the second paragraph, "and" has been deleted and, at the end of the claim, the following wording has been added:

"wherein each of the originating node and the terminating node comprises a middleware layer, each middleware layer of the originating node and the terminating node further comprising a non-IP communication device; and

wherein the non-IP communication device (110) of the originating node is configured to transmit the non-IP-based communication request message to the non-IP communication device (128) of the terminating node".

VI. Claim 1 of the third auxiliary request differs from claim 1 of the main request in that, at the end of the claim, the following wording has been added:

"wherein the originating node comprises a client application (98), a middleware (102), a middleware application program interface API (100), and a non-IP communication device (110),

wherein the terminating node comprises a server application (114), a middleware (118), a middleware API (116), and a non-IP communication device (128),

wherein the middleware (102) of the originating node is configured to direct the non-IP communication device (110) of the originating node to transmit the non-IP-based communication request message to the non-IP based communication device (128) of the terminating node".

VII. Claim 1 of the fourth auxiliary request differs from claim 1 of the main request in that, at the end of the claim, the following wording has been added:

"wherein the terminating node further comprises an application layer, a middleware layer, and a system layer;

wherein the originating node comprises an application layer, a middleware layer, and a system layer;

wherein the terminating node is further configured to create a virtual server socket between the application layer at the terminating node and the middleware layer at the terminating node;

wherein the originating node is further configured to create a virtual client socket between the application layer at the originating node and the middleware layer at the originating node;

wherein the originating node is configured to send the communication request from the middleware layer at the originating node to the middleware layer at the terminating node;

wherein the terminating node is further configured to create a client socket between the middleware layer at the terminating node and the system layer at the terminating node;

wherein the originating node is further configured to create a server socket between the middleware layer at the originating node and the system layer at the originating node;

wherein the terminating node is further configured to receive the communication request at the middleware layer of the terminating node, the communication request defining an internet protocol address and a port number of the server socket at the originating node".

Reasons for the Decision

1. Procedural aspects: oral proceedings held by videoconference

1.1 Oral proceedings that took place on 8 May 2020 were the first held by videoconference in the history of the Boards of the Appeal of the EPO. Unlike some national legal systems, the EPC does not stipulate explicitly the form(s) in which oral proceedings under Article 116 EPC shall take place. For these reasons, the Board considers it appropriate to address briefly the legal basis for oral proceedings within the meaning of Article 116 EPC.

1.2 In the past, the Boards have rejected requests that the oral proceedings be held by videoconference (ViCo), mainly on the grounds that there was no "general framework" to this effect. In particular, there were no provisions made for suitable ViCo rooms and for the public to attend such ViCo-based hearings (see e.g. T 1266/07, Reasons, point 1; T 2068/14, Reasons, point 1.2.2).

At the same time, the Boards held that Article 116 EPC did not mandate that oral proceedings take place with the physical presence of the parties. As pointed out in T 2068/14, "while a video conference does not allow such direct communication as the face-to-face meeting involved in conventional oral proceedings, it nevertheless contains the essence of oral proceedings, namely that the board and the parties/representatives can communicate with each other simultaneously" (see point 1.2.3 of the Reasons). Hence, several Boards considered that it was in their discretion to decide whether nor not to select this form for the parties' oral submissions (T 2068/14, Reasons, point 1.2.2; T 195/14, Reasons, point 1; T 932/16, Reasons, point 1.1).

1.3 The present board agrees with this interpretation of the legal framework. Hence, oral proceedings held by videoconference are not excluded by the EPC and fulfil the requirements for holding oral proceedings within the meaning of Article 116 EPC. The EPC only requires that the public character of the proceedings be ensured (Article 116(4) EPC). The form in which the parties present orally their arguments - with or without physical presence - is not predetermined by Article 116 EPC.

1.4 Against this background, in the present case, the board considered it appropriate and expedient to convert the scheduled in-person oral proceedings into oral proceedings held by videoconference (cf. point II above). Indeed, and in contrast to the circumstances under which the decisions mentioned above were issued, the Boards of Appeal have now at their disposal suitable rooms at their premises for ViCo-based hearings.

Furthermore, appropriate provisions have been made for the public to attend such hearings. By means of a communication published on the website of the Boards of Appeal on 6 May 2020, it was indicated that "[o]ral proceedings will be conducted by VICO only in agreement with the parties concerned" and that "[a]ny member of the public wishing to attend oral proceedings conducted by VICO may do so in a dedicated room located at the premises of the Boards of Appeal in Haar".

1.5 The appellant agreed to oral proceedings being held without its physical presence. During those oral proceedings held on 8 May 2020, the public attended them by means of an additional connection to the board's videoconference system set up from a dedicated room at the premises of the Boards of Appeal.

2. Background of the invention

The present application relates essentially to a system for and a method of establishing an IP connection between two nodes wherein an originating node sends a non-IP-based message to a terminating node which in response initiates the IP connection with the originating node (page 4, lines 12 to 16 of the present application as filed). By means of this procedure, an Internet connection can be established also in situations in which the originating node cannot send an unsolicited IP message to the terminating node, in particular because of a firewall or a network address translator (NAT) between the two nodes (page 4, lines 16 to 19 as filed).

3. Main request - Article 56 EPC

3.1 Prior-art document D5 discloses in the section "Summary of the present invention" a method of initiating an Internet connection between an originating node ("server device") and a terminating node ("client device"), wherein the server causes a non-IP-based message to be sent to the client and the client initiates in response thereto an Internet connection (page 6, line 30 to page 7, line 6). The indication "thus bypassing the firewall or NAT router" for the step of sending the non-IP-based message to the client implies that the terminating node ("client 20") is located in a private network (see also Fig. 3).

With respect to the network in which the originating node ("server 6") is located, D5 gives no explicit details. It is merely derivable that "server 6" is connected to an "Internet backbone" (see e.g. Figs. 2 and 3). However, it is not directly and unambiguously disclosed in D5 that the server is indeed located in a public network. The board further considers that causing a message to be sent is equivalent to sending a message and that D5 also discloses a system for carrying out the method (see e.g. claim 11).

3.2 The system of claim 1 of the main request thus differs from the system of D5 solely in that the originating node is located in a public network (contrary to the finding in the decision under appeal, Reasons, point 14.1).

3.3 The examining division concluded in its reasoned decision that the difference between claim 1 and the disclosure of D5 was that "the originating node does not send the message via an authorization center, instead, it is the source of the non-IP message itself" (see point 14.1 of the Reasons).

In that regard, the board notes that the authorisation portal does not constitute an essential feature of the system of D5 and that D5 also discloses sending the respective communication request without the use of such an authorisation portal.

3.4 The system of D5 addresses the same problem as the present application, namely the problem of initiating an Internet connection through a NAT or a firewall (page 4, line 26 to page 5, line 10 and page 14, lines 17 to 21). In order to reach the terminating node behind a NAT or a firewall, D5 proposes using a non-IP-based message. However, in order to allow, in response thereto, the terminating node to establish an Internet communication with the originating node within the possibilities provided by the system of claim 1, the originating node is required to be located in a public network.

3.5 It is therefore obvious for a person skilled in the field of telecommunication networks to apply the system of D5 to situations where the originating node is located in a public network.

3.6 Furthermore, even when starting out, as the Examining Division did, from the embodiment of D5 described on page 17, line 12 to page 18, line 18 relying on an authorisation portal to convey the message from the originating to the terminating node, it is obvious to omit that authorisation portal or to incorporate it, as e.g. a sub-unit, into the originating node for the sake of simplification.

3.7 The appellant argued that the authorisation portal was an important feature of the system of D5 and that the skilled person would not have been prompted to omit it.

The board however notes that D5 mentions in its section "Background to the present invention" as a problem that the originating node does not know the IP address of the terminating node if the latter is behind a firewall or a NAT. This problem is solved by the use of a non-IP-based message regardless of whether or not an authorisation portal is used. This is in line with the fact that, in the section "Summary of the present invention" of D5, the embodiments according to the first four aspects do not include an authorisation portal (see page 6, line 30 to page 8, line 2). A problem related to security, which could require an authorisation portal for its solution, is not mentioned in that background section.

3.8 The appellant further argued that, in the system of claim 1, the originating node sent the non-IP-based message directly to the terminating node contrary to D5. In that regard, it is apparent to the board that claim 1 does not include the feature of a direct transmission of the non-IP-based message to the terminating node in the sense that it would exclude that the originating node comprises another sub-unit and, further, that the admittedly "indirect" transmission via the authorisation portal is only included in the embodiments according to the fifth aspect (see page 8, line 4 to page 10, line 6). Hence, D5 comprises several embodiments in which the server device sends the non-IP-based communication message to the client device without the use of any "authorisation portal".

3.9 It was further argued that the method and the system of D5 were about "trust" and how to provide control to the client. The solution of D5 allowed to use a single authorisation portal to control the access rights of many originating nodes to initiate communication with the terminating node.

The board holds that D5 first and foremost focuses on the initiation of an Internet connection through a NAT or firewall for which the authorisation portal is not necessary (see page 3, line 17 to page 6, line 26). Hence, the authorisation portal is not inextricably linked to the other features of the embodiment.

3.10 In view of the above, the board concludes that the system of claim 1 of the main request lacks an inventive step. The main request is therefore not allowable under Article 56 EPC.

4. First auxiliary request - Article 56 EPC

4.1 Claim 1 of the first auxiliary request essentially further adds a middleware layer to the originating node and the terminating node, wherein the nodes are configured to transmit the non-IP-based communication request message from the middleware layer of the originating node to the middleware layer of the terminating node.

The term "middleware layer" may be construed broadly to any means arranged within a stack of layers. The board considers that it is an obvious implementation measure to allocate the transmission of the communication request message to a specific layer. The board notes in this respect that it is common general knowledge to handle communication schemes at an intermediate layer (see, for example, the layers of the well-established OSI model).

4.2 The appellant argued that the skilled person would not omit the essential authorisation portal and instead provide a middleware layer. The board reiterates that the authorisation portal is not an essential feature of the system of D5 (see point 3.3 above) and adds that the middleware layer relates to the implementation of the system without touching upon security or control issues which may be addressed by the authorisation portal.

4.3 In view of the above, the system of claim 1 of the first auxiliary request likewise lacks an inventive step. The first auxiliary request is therefore not allowable under Article 56 EPC either.

5. Second auxiliary request - Article 56 EPC

5.1 Claim 1 of the second auxiliary request essentially further adds that the middleware layers of the originating and terminating nodes comprise non-IP communication devices.

5.2 However, it is implicit that the two nodes each include a non-IP communication device in order to be able to actually send or receive the non-IP communication request message.

5.3 Thus, the system of claim 1 of the second auxiliary request lacks an inventive step either. In conclusion, the second auxiliary request is likewise not allowable under Article 56 EPC.

6. Third auxiliary request - Article 56 EPC

6.1 Claim 1 of the third auxiliary request essentially further adds that the originating and terminating nodes comprise a "middleware application program interface API" together with a "client application" and a "server application" respectively.

6.2 Document D5 defines a client, i.e. the receiving or terminating node, as a host that accesses services of a server which implies that it includes a client application making use of the server services (see page 1, lines 25 to 28). The board further considers that a client application will almost necessarily need some sort of interface to the middleware in order to be able to exchange the necessary information.

6.3 Hence, the system of claim 1 of the third auxiliary request lacks an inventive step. The third auxiliary request is therefore not allowable under Article 56 EPC either.

7. Fourth auxiliary request - Article 56 EPC

7.1 Claim 1 of the fourth auxiliary request essentially further adds that the originating and terminating nodes also comprise an "application layer", a "system layer", a "virtual server/client socket" between the application layer and the middleware layer and that a "server/client socket" may be created between the middleware and the system layer at both nodes. In addition, the non-IP-based communication request is supposed to define an IP address and a port number of the server socket at the originating node.

7.2 The board considers that these features are mere implementation details related to the internal layer structure and the transmission of the necessary information between the different layers in the respective nodes.

7.3 The appellant argued at the oral proceedings before the board that the client or server socket in the terminating or originating node established a client/server relationship in the system of claim 1 which is opposite to the one in D5.

The board however notes that claim 1 refers to a virtual server socket and a client socket in the terminating node and accordingly a server socket and a virtual client socket in the originating node and therefore concludes that a clear attribution of a client or server role to the respective nodes is not possible. The server and client attributes rather refer to which node actually provides content to the other node. Even if a server or a client role could clearly be attributed to the nodes it would be irrelevant for the method of establishing an Internet communication between the nodes and would be merely an implementation detail which could not contribute to an inventive step.

7.4 In sum, the system of claim 1 of the fourth auxiliary request lacks an inventive step, too. The fourth auxiliary request is therefore not allowable under Article 56 EPC either.

8. As there is no allowable claim request, it follows that the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation