T 1967/19 (Pool-based GRE key selection/NOKIA) 12-05-2022

1. MAIN REQUEST

Claim 1 of the main request comprises the following limiting features (board's outline):

An apparatus comprising:

(a) means for selecting a key for encapsulation of multicast data at a gateway device;

(b) means for communicating a message indicative of a multicast connection for a particular service from the gateway device to base stations in a

multicast-broadcast zone, the base stations being joined to a same multicast tree in the

multicast-broadcast zone as the gateway device;

(c) means for establishing the multicast connection with the base stations via a multicast data path comprising a multicast tunnel associated with the key;

(d) the means for selecting a key for encapsulation is configured to select the key by selecting a generic routing encapsulation (GRE) key from a multicast and broadcast service (MCBCS) pool.

1.1 Claim 1 - claim interpretation

1.1.1 Feature (d) requires selecting a GRE key as the key for encapsulation of multicast data. However, the claim does not mention the encapsulation of multicast data using the GRE protocol. In the applicant's favour, the board will interpret feature (c) as implying that the multicast tunnel associated with the key actually uses the GRE protocol for encapsulation.

1.1.2 Furthermore, the selection of a GRE key from a MCBCS pool in feature (d) does not necessarily mean that the pool is pre-defined or reserved in a consistent way in advance. Hence, it also encompasses embodiments where the pool is dynamically defined as more GRE keys are being added to it.

1.2 Claim 1 - inventive step (Article 56 EPC)

1.2.1 Using the wording of claim 1, document D1 discloses (with reference to EP 2 061 266 A1, the English translation of D1 published in accordance with Article 153(4) EPC):

An apparatus (Fig. 5: SGSN) comprising:

(a) means for selecting a key ("the Tunnel End Point Identifier (TEID)") for encapsulation of multicast data at a gateway device ([0067]: "... the Tunnel End Point Identifier (TEID) may be assigned by the sending node (SGSN) ...");

(b) means for communicating a message indicative of a multicast connection for a particular service from the gateway device to base stations in a

multicast-broadcast zone ([0067]: "... (TEID) may be ... notified to all receiving nodes (NodeB+) ..."), the base stations being joined to a same multicast tree in the multicast-broadcast zone as the gateway device ([0073]: "... the NodeB+ needs to send IGMP JOIN to join the multicast group.");

(c) means for establishing the multicast connection with the base stations via a multicast data path comprising a multicast tunnel associated with the key ([0067]: "... all the receiving nodes identify the multicasting data flow using the same TEID.").

1.2.2 The board thus concurs with the examining division and the appellant that the subject-matter of claim 1 differs from D1 in feature (d).

1.2.3 The technical effects associated with feature (d) are the following:

(i) the use of GRE as encapsulation protocol results in less overhead than using GTP (8-12 bytes GRE header directly on top of IP as opposed to the 28 bytes required by GTP+UDP header used on top of IP),

(ii) the exclusive use of a subset of all the possible GRE keys ("pool") enables the identification of tunnels carrying MCBCS data in D1, irrespective of whether the underlying IP transport is multicast or unicast.

1.2.4 The objective technical problem can thus be framed as "how to improve the bandwidth-efficiency relating to the identification and use of the multicast tunnels of D1".

The subject-matter of claim 1 does not involve an inventive step starting out from D1 for the following reasons:

1.2.5 The skilled person in the field of 3GPP-based mobile networks would have immediately recognised that the use of GTP (i.e. the GPRS Tunnelling Protocol) in the multicast tunnels of D1 is a legacy from

pre-3GPP/UMTS/WCDMA standards and that its replacement by GRE, well-known from Internet standards and readily available at the application's priority date, would reduce the overhead created by the encapsulation headers, improving thereby its bandwidth efficiency.

1.2.6 D1 explicitly discloses the use of a field of the GTP header, i.e. the "TEID", to identify a multicasting data flow. The skilled person adapting this teaching to the use of GRE would have naturally selected a data field of the GRE header, i.e. the GRE key, as corresponding tunnel identifier, given that this optional field was notoriously used as tunnel differentiator in GRE. Further considering that the claim does not define whether or not the pool is

pre-defined before the allocation takes place (cf. point 1.1.2 above), the mere fact of allocating a number of GRE keys to a respective set of MCBCS flows would have already automatically created a "MCBCS pool" of GRE keys.

1.2.7 Even if the claim were to imply a pre-definition of the MCBCS pool, reserving a pool of identifiers from the available identifier space for multicast data was, generally speaking, a well-known measure in the field of packet-switched communications at the application's priority date (e.g. multicast IPv4 addresses are commonly selected in the range 224.0.0.0 through 239.255.255.255, multicast addresses in IPv6 use the prefix ff00::/8). The trade-offs involved in applying the same measure to tunnel endpoint identifiers, e.g. GRE keys, would have also been apparent to the skilled person: ease of identification typically comes at the expense of the amount of identifiers available for

non-multicast data. The choice would have been a straightforward trade-off decision in accordance with the circumstances, when adapting D1 to the use of GRE.

1.2.8 The appellant submitted that feature (d) enabled the solution to the problem of "operating a Multicast and Broadcast Service (MCBCS or MBMS) within a system which may not support conventional IP-M operations (for example where there is a unicast uplink available)". This was shown in the application with reference to one example strictly adhering to "3-way signalling" as in the current unicast setup and another with a "modified 2-way signalling" approach. The appellant submitted that the board's preliminary opinion was incorrect in rejecting this as the objective technical problem.

The board acknowledges that feature (d) is particularly useful when operating an MBMS within a system which may not support IP-M operations and has included this advantage in the technical effect identified in point 1.2.3 (ii) above. However, the subjective technical problem defined in the application considers the use of the GRE protocol as a given and the alleged contribution is limited to the selection of known GRE identifiers from an MCBCS pool. Conversely, D1 does not disclose the use of GRE keys. Thus, the objective technical problem must account for the technical contribution of all the distinguishing features, hence the reference to the technical effect identified in point 1.2.3 (i) above.

1.2.9 With respect to the board's objective technical problem and subsequent reasoning, the appellant first rejected that the skilled person would have immediately replaced the GTP used in the multicast tunnels of D1 with GRE. As argued by the board, GTP was a legacy standard-related approach and as such the skilled person would have been dissuaded from abandoning such a standard-related approach as it would possibly lead to issues when implementing the system within a suitable standard-related network. Second, the board combined two separate aspects of general knowledge, that of the replacement of the GTP with GRE and then the reservation of a pool of identifiers to tunnel endpoint identifiers, with the teachings of D1. Account being taken that the GRE keys were also used for authentication purposes, this combination of additional teachings over D1 would not have been obvious for the skilled person at the time of filing and furthermore could be seen to be an ex-post facto analysis as regards the assessment of inventive step.

This is not convincing either. First, the skilled person would have been well-aware that performing obvious modifications to a technical specification could result in a working device which does no longer conform to the specification and, as a consequence, cannot interoperate with legacy devices (see e.g. T 984/15, Reasons 2.8). Second, the skilled person choosing GRE as a straightforward alternative to GTP would have been forced to find an equivalent in GRE to the TEIDs of GTP used in D1 for the purpose of tunnel identification. In this regard, the board cannot identify any particular purpose associated with the GRE keys according to the present application beyond the well-established one, i.e. the differentiation of tunnels which extend between the same tunnel endpoints.

1.3 It follows that the main request is not allowable under Article 56 EPC.

2. FIRST AUXILIARY REQUEST

Claim 1 comprises all the limiting features of claim 1 of the main request and the following additional limitation (board's outline):

(e) the generic routing encapsulation key is selected from an MBMS pool reserved [from the] generic routing encapsulation key address space.

2.1 Claim 1 - inventive step (Article 56 EPC)

2.1.1 According to the appellant, feature (e) constitutes a clarification, referring back to the inventive-step discussion with respect to the main request.

2.1.2 However, this difference, interpreted as suggested by the appellant, has already been considered by the board in point 1.2.7 above for the assessment of inventive step as regards the subject-matter of claim 1 of the main request. Hence, the same reasons apply mutatis mutandis to the subject-matter of claim 1 of the first auxiliary request.

2.2 It follows that the first auxiliary request is not allowable under Article 56 EPC either.

3. Since there is no allowable set of claims, the appeal must be dismissed.