T 0614/21 (Multipath TCP for vehicle communications/MCLAREN) 16-01-2024

1. Technical background

1.1 The opposed patent relates to a system for providing data communication with a vehicle such as a bus or train. It considers in particular the allegedly increasing need for a "passengers-carrying vehicle" to connect to the Internet and share this connection with end-user devices on-board of the vehicle.

1.2 Figure 2 of the opposed patent (reproduced below) explains how such an "end-user device" communicates with a "remote server" in accordance with the invention.

FORMULA/TABLE/GRAPHIC

In this Figure, end-user device 32 attempts to connect to remote server 160 to request data. This connection attempt is sent over wireless link 200 to mobile router 20. Mobile router 20 is on-board of the same vehicle as end-user device 32 and comprises mobile proxy 150. Mobile proxy 150 intercepts the connection attempt and "masquerades" as remote server 160. The TCP user session that originates from end-user device 32 is terminated at mobile proxy 150. As a result, end-user device 32 "believes" that it has established a connection to remote server 160 when in fact it has established a connection with mobile proxy 150. Mobile proxy 150 establishes connection 210 with wayside parent proxy 170 using the so-called "MultiPath Transport Control Protocol (MPTCP)". Mobile proxy 150 then requests the data from parent proxy 170 "on behalf of" end-user device 32. When doing so, it "identifies as itself" at the transport layer. Parent proxy 170 receives the request for data from mobile proxy 150 over MPTCP connection 210. Parent proxy 170 intercepts the request from mobile proxy 150 and "masquerades" as remote server 160. The TCP user session that originates from mobile proxy 150 is terminated at parent proxy 170. In this way, mobile proxy 150 "believes" that it has established a connection to remote server 160 when in fact it has established a connection with parent proxy 170. Parent proxy 170 in turn establishes connection 220 to remote server 160 to request the data "on behalf of" mobile proxy 150 and thus indirectly, "on behalf of" end-user device 32. The response of remote server 160 to the request for data is then cascaded back to end-user device 32 via parent proxy 170 and mobile proxy 150.

2. Main request: claim 1 - novelty

2.1 The board agrees with Reasons C2.1 of the appealed decision that document D5 discloses features (a) to (f) on the basis of the passages of D5 cited in Reasons C2.1, particularly in view of paragraphs [0048] and [0058] to [0060] together with Figure 3 of D5.

The respondent contests D5's disclosure of features (a) to (e). Most of the respondent's arguments in this respect have been adequately treated in Reasons C2.1 of the appealed decision. The board makes the following observations in that regard:

2.1.1 Regarding feature (a), the expression "car modem" mentioned in paragraph [0048] of D5 is used as an example of the general term "mobile platform". The skilled reader would immediately understand from this paragraph that WWAN client 302 of Figure 3 and paragraphs [0058] to [0060] of D5 is not necessarily static but can be used in a moving vehicle. It is highlighted in this respect that the second sentence of paragraph [0059] of D5 states that WWAN client 302 can receive its IP address dynamically. This means that the IP address is allocated to WWAN client 302 for a limited time period, after which it can be taken back and assigned to another client. Such a dynamic allocation is, for instance, particularly useful for clients that transit a given area on board of a moving vehicle.

The respondent contested that paragraph [0048] of D5 could be read in combination with the embodiment illustrated by Figure 3. In the respondent's view, this paragraph was similar to paragraph [0098] of D5, the latter describing specifically the embodiment shown in Figure 14. The respondent concluded that the skilled reader would therefore understand paragraph [0048] of D5 to relate to Figure 14 and not to Figure 3.

The board acknowledges that there are similarities in terminology between paragraphs [0048] and [0098] of D5, e.g. in view of the terms "[multiple] WWAN modems" and "car[-]modem[s]" in those paragraphs. However, this does not mean that the skilled reader would directly and unambiguously understand these paragraphs to relate to the very same embodiment. Instead, the board agrees with the appellant that paragraph [0048] is merely a part of a general disclosure in D5, which precedes, as is often the case in patent literature, the more detailed disclosure relating to Figures 1 to 21 of D5. Moreover, the skilled reader would, in the board's view, readily recognise that the statement regarding the "car modem" in paragraph [0048] is unequivocally applicable to the embodiment of Figure 3 of D5.

2.1.2 Concerning features (b) to (f), the sentence "[i]n one aspect, as discussed with reference to FIGS. 10, 11 and 12, WWAN client 302 may be operable to act as an ad hoc access point for other devices (e.g., UEs)" of paragraph [0058] of D5 discloses in a direct and unambiguous way that WWAN client 302 operates as a proxy "on behalf of" the UEs, i.e. "host devices" in the sense of features (d) and (e). To do so, WWAN client 302 will necessarily "accept" a connection with these host devices, e.g. when providing them with Internet access. Further, this "accepted" connection has to be made "when communicating with an application server 308 on the Internet/Network 306" (see the second sentence of paragraph [0059] of D5). Therefore, the requirement according to feature (d) that the transport-layer connection is "addressed to a remote server", as was highlighted by the respondent during the oral proceedings before the board when discussing the construction of the verb "to accept", is indeed disclosed in D5. Furthermore, regarding feature (e), nodes of an ad-hoc access network will typically "identify as themselves" and the board sees no reason why this would be any different for WWAN client 302. Moreover, Figure 3 of D5 clearly depicts "MultiPath TCP Tunneling Server 304" as a logically superordinate server, i.e. as a "parent server". The superordinate nature of MPTCP tunnelling server 304 is also illustrated by the fact that it manages a domain of devices to which it assigns IP addresses (see the second sentence of paragraph [0059] and the third last sentence of paragraph [0060] of D5). In addition, from the relaying by MPTCP tunnelling server 304 of packets between WWAN client 302 and application server 308 in the way as described in paragraph [0060] of D5, the skilled reader would readily understand that MPTCP tunnelling server 304 operates as a "proxy server".

In addition, the second sentence of paragraph [0058] of D5 unequivocally discloses that the communication between WWAN client 302 and MPTCP tunnelling server 304 has to take place via multiple paths using the multipath protocol. The OSI-model layer at which the connections between the host devices, WWAN client 302 and MPTCP tunnelling server 304 take place will depend on the kind of data-transfer session which the users of the host-devices would like to perform. In the case of a TCP session, such as the one mentioned in the first sentence of paragraph [0060] of D5, this is the transport layer, given that TCP is a transport-layer protocol.

2.2 Moreover, the board understands paragraphs [0059] and [0060] of D5 to disclose feature (g) in its entirety rather than only in part as considered in Reasons C2.1 of the appealed decision. This is so for the following reasons.

2.2.1 TCP sessions such as the one mentioned in the first sentence of paragraph [0060] of D5 use an

end-to-end flow control protocol. In such a protocol, application-specific features relating to, for instance, application security must reside at the end points. A TCP session therefore requires a proper definition of these end points, which is typically done via their respective network addresses, i.e. typically their IP addresses. This is also illustrated by the way in which the packets sent via the TCP session between WWAN client 302 and application server 308 are handled, as described in paragraph [0060] of D5: the end points are clearly defined by means of "ClientVPN_Public_IP" and "ApplicationServer_IP" respectively. The board therefore agrees with the opposition division and the respondent that WWAN client 302 will be identified directly by means of its IP address "ClientVPN_Public_IP".

2.2.2 However, the board cannot see how this led eventually the opposition division to conclude in the appealed decision (cf. first sentence of page 13) that D5 does not disclose "that the tunneling server identifies itself as such to the application server". The

end-to-end flow control protocol underlying the TCP session according to the first sentence of paragraph [0060] of D5 does not exclude intermediary nodes such as gateways or routers. Within the context of Figure 3 of D5, MPTCP tunnelling server 304 must necessarily act as such an intermediary node during the TCP session because it must be involved in establishing the data flow when WWAN client 302 connects to the Internet (cf. the first sentence of paragraph [0059] of D5). The board sees no reason why MPTCP tunnelling server 304 would behave differently from any other typical, intermediary node in terms of its identification during a TCP connection. While serving as a relay unit in the communication of packets between WWAN client 302 and application server 308 to provide host devices UE with Internet access (cf. point 2.1.2 above), MPTCP tunnelling server 304 will therefore include its own IP address in the communication with application server 308. This is in agreement with how, during the oral proceedings before the board, the respondent construed the expressions "on behalf of" and "whilst identifying as" according to feature (g). In other words, MPTCP tunnelling server 304 identifies "as itself" when communicating with application server 308.

2.2.3 As to feature (g), the respondent disputed that MPTCP tunneling server 304 was identified to application server 308 in the system of D5.

However, in the board's view, there can be no doubt that MPTCP tunnelling server 304 and application server 308 in Figure 3 of D5 at least communicate with each other. Given that this communication is part of the "legacy TCP or User Datagram Protocol (UDP) session" between application server 308 and WWAN client 302 as described in paragraph [0060] of D5, MPTCP tunnelling server 304 will behave as any other typical, intermediary node in such a legacy session. This is most prominently evidenced by the following teaching provided in paragraph [0060] of D5:

"[...] Packets leaving the client 302 are wrapped

into the MultiPath TCP tunnel and delivered to

the tunneling server 304. The tunneling server 304

unwraps the packets and sends the packets destined

to the IP address ApplicationServer_IP. [...]".

A skilled reader would infer from this passage that, by wrapping the data packets originating from the "client", the client's IP address is incorporated into those data packets and, by unwrapping the packets received at the "tunnelling server" and sending the respective packets to the "application server", the client's IP address is compellingly replaced with the IP address of the tunnelling server before those packets are actually forwarded to the application server, in full accordance with features (e) and (g) of present claim 1.

2.2.4 The respondent argued that MPTCP tunnelling server 304 is transparent in the "legacy TCP or User Datagram Protocol (UDP) session" between application server 308 and WWAN client 302 mentioned in point 2.2.3 above. It came to this conclusion because, in its view, Figure 15 of D5 clearly indicated "packet format 1508" to be identical to "packet format 1502".

However, the board is not convinced that the description of Figure 15 of D5 in paragraph [0099] of D5 allows to draw such a conclusion. From paragraph [0099], it is apparent that "packet format 1502" illustrates a data flow from a client to an Internet destination. Moreover, "packet format 1508" provides a format for receiving "IP packet 1502" as part of tunnelling payload 1504 at MPTCP tunnelling server 304. Packet format 1508 being identical to packet format 1502 in Figure 15 of D5 therefore only relates to the connection between the client and MPTCP tunnelling server 304. It does not concern whether application server 308 is aware of any tunnelling via MPTCP tunnelling server 304. Hence, the board cannot see how Figure 15 of D5 could provide any indication that MPTCP tunnelling server 304 does not "identify as itself" to application server 308.

2.2.5 As a result, document D5 discloses feature (g) in its entirety.

2.3 In conclusion, the subject-matter of claim 1 of the main request is not new (Article 54 EPC). Hence, the ground for opposition under Article 100(a) EPC prejudices the maintenance of the opposed patent.

3. Auxiliary requests 1 to 7: admittance

3.1 The appealed decision was not "based on" auxiliary requests 1 to 7 within the meaning of Article 12(1)(a) RPBA 2020. Indeed, the opposition division rejected the opposition. In such a case, the patent proprietor has to demonstrate that these requests were admissibly filed and maintained in the proceedings before the opposition division (cf. Article 12(4), first sentence, RPBA 2020). If this is done, the auxiliary requests form part of the appeal proceedings. In the case in hand, the respondent has not made submissions to that effect. Therefore, the auxiliary requests on file are to be regarded as an "amendment" within the meaning of Article 12(4) RPBA 2020, and may be admitted only at the discretion of the board (ibid., also the second sentence).

3.2 The respondent explained that there was no need to file any auxiliary requests during the opposition proceedings because the opposition division rejected the opposition.

The board, however, considers that a party prevailing in opposition proceedings is not relieved from its duty to timely prepare its case for the event of subsequent appeal proceedings. Indeed, each party should take into account that either the opposition division or the board of appeal may depart from the preliminary view expressed by the opposition division and adopt an opposing view. The patent proprietor should prepare the relevant "fallback positions" for that eventuality. There is however no right to present on appeal "fallback positions" that could have been presented already in the first-instance proceedings. Anything else would be contrary to the primary purpose of the appeal proceedings as laid down in Article 12(2) RPBA 2020, i.e. the judicial review of the decision under appeal.

3.3 Admittedly, the respondent argued in this respect that auxiliary requests 1 to 7 were submitted in order to respond to the appellant's argument that D5 anticipated feature (g) as set out in point 38 of the statement of grounds of appeal.

The appellant, however, convincingly drew the attention to page 13 of the appealed decision in this respect. The third paragraph of that page 13 contains the phrase referred to in item 38 of the statement setting out the grounds of appeal, namely that "the argument on the fact that the public address is allegedly not that of the WWAN client - because for O this would render the tunneling useless - seems artificial". Moreover, in the board's opinion, the argument mentioned in item 38 corresponds to the opponent's argument summarised in the second paragraph of page 13 of the appealed decision.

3.4 The board notes that the novelty analysis of claim 1 of the main request already required (cf. points 2.1.2 and 2.2.2 above) a discussion during the oral proceedings before the board on how to interpret

- the verb "to accept" in accordance with feature (d)

and

- the expressions "on behalf of" and "whilst identifying as" according to features (e) and (g).

The amendments underlying claim 1 of auxiliary requests 1 to 7 would further necessitate an interpretation of several new expressions for the first time. The board refers in particular to

- the expressions like "intercept", "masquerade" and "terminates" as per features (i), (k) and (l), or, similarly, "intercepting", "masquerading" and "terminating" as per features (j) and (m)

and to

- the term "believes" in accordance with features (l) and (m).

It is also worth noting that the appellant indicated already in its statement setting out the grounds of appeal that the term "masquerading" did not have "a well recognised meaning in the field". It raised an objection as to insufficiency of disclosure under Article 100(b) in combination with Article 83 EPC in this respect. The board therefore considers that admitting auxiliary requests 1 to 7 into the proceedings would be detrimental to procedural economy.

3.5 Hence, auxiliary requests 1 to 7 are not admitted into the proceedings (Article 12(4) RPBA 2020).