T 1924/19 (Common PDP context/3G LICENSING) of 31.3.2022

Summary of Facts and Submissions

I. This appeal concerns the decision of the opposition division revoking the opposed patent as granted for lack of novelty (Article 54(3) EPC) with respect to independent claim 17.

II. In its decision, the opposition division cited inter alia the following prior-art documents:

D1:| WO 2005/060204 A1; |

D11:| "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2 (Release 6)", 3GPP TS 23.060 V6.2.0 (2003-09). |

III. The appellant (proprietor) requested as a main request that the appealed decision be set aside and that the opposition be rejected or, in the alternative, that the patent be maintained on the basis of the claims of one of eleven auxiliary requests.

The respondent (opponent) requested that the appeal be dismissed.

IV. At the end of the oral proceedings held on 31 March 2022, the board's decision was announced.

V. Claim 17 as granted (i.e. claim 17 of the main request) reads as follows:

"A mobile user equipment for sending and receiving internet packets to and from a packet radio network, the mobile user equipment comprising

means for activating a packet data protocol context for controlling the communication of the internet packets to and from the packet radio network from and to the mobile user equipment via a packet communications bearer,

means for controlling the communication of the internet packets via said packet communication bearer, said packet data protocol context activating said packet communications bearer across the packet radio network,

means for setting up a radio access bearer for communicating the internet packets via a radio access interface to and from a radio network part of the packet radio network, characterized in that

the means for activating a packet data protocol context comprise means for sending to a serving support node of the packet radio network a common packet data protocol activation request message requesting a common packet data protocol context for communicating packets according to a non-specific internet protocol version, the common packet data protocol context being established in association with a common packet communications bearer to communicate internet protocol packets according to an internet protocol version specified by the mobile user equipment for one or more communications sessions, wherein the packet data protocol activation request message includes an end user address information element, the end user information element including a packet data protocol type number field having a value set to a predetermined value to indicate a request for the common packet data protocol context, and an address field representing an address in accordance with the internet protocol version specified by the mobile user equipment for communicating the internet packets using the common packet data protocol context."

Reasons for the Decision

1. Technical background of the patent

1.1 The context of the patent relates to the GPRS/UMTS standard. According to paragraph [0002] of the patent, each mobile user equipment (UE) needs to set up at least one GPRS/UMTS communication session represented by a packet data protocol (PDP) context to send and receive data. There are three different types of PDP context, depending on the type of internet protocol (IP) connectivity which the mobile user has established:

- Point-to-point protocol (PPP) type

- Internet protocol version 4 (IPv4) type

- Internet protocol version 6 (IPv6) type.

1.2 A UE with a dual IPv4 and IPv6 stack may need to send both IPv4 and IPv6 packets contemporaneously. According to paragraph [0007] of the patent, the existing

IP-type-specific PDP context may require that the mobile UE set up at least two PDP contexts, one of IPv4 type and the other of IPv6 type. This can cause inefficient use of communications resources in the packet network.

2. MAIN REQUEST

Independent claim 17 as granted comprises the following limiting features:

1 A mobile user equipment (UE) for sending and receiving internet packets to and from a packet radio network, the mobile UE comprising

2 means for activating a PDP context for controlling the communication of the internet packets to and from the packet radio network from and to the mobile UE via a packet communications bearer,

3 means for controlling the communication of the internet packets via said packet communication bearer, said PDP context activating said packet communications bearer across the packet radio network,

4 means for setting up a radio access bearer for communicating the internet packets via a radio access interface to and from a radio network part of the packet radio network,

5 the means for activating a PDP context comprise means for sending to a serving support node of the packet radio network a common PDP activation request message requesting a common PDP context for communicating packets according to a non-specific IP version,

6 the common PDP context being established in association with a common packet communications bearer to communicate IP packets according to an IP version specified by the mobile UE for one or more communications sessions,

6a wherein the PDP activation request message includes an end user address information element,

6b the end user address information element including a PDP type number field having a value set to a predetermined value to indicate a request for the common PDP context,

6c and an address field representing an address in accordance with the IP version specified by the mobile UE for communicating the internet packets using the common PDP context.

2.1 Claim 17 - Claim interpretation

2.1.1 In point II.2.3.1 of the appealed decision, the opposition division considered that feature 6c, read in light of Figures 10 and 11 together with paragraph [0026] of the patent, also encompassed an "address field" for two addresses, namely, an IPv6 address including an IPv4 address.

2.1.2 The appellant contended that it was evident from the wording of feature 6c that the PDP activation request included only one address (either an IPv4 address or an IPv6 address). The wording of feature 6c did not only require the inclusion of an address field representing an address in the PDP activation message, but also that the address be "in accordance with the IP version specified by the mobile UE for communicating the internet packets using the common PDP context".

2.1.3 The board agrees with the opposition division and the respondent that the wording of claim 17 does not exclude the possibility of the mobile UE specifying more than one IP version (e.g. IPv4 and IPv6) for one or more communication sessions (see e.g. paragraph [0016] of the patent: "... the UE 2 may wish to use one or both of an IPv4 address and in IPv6 address establishing a communication session in accordance with an IPv4 and an IPv6 respectively ..."). Consequently, the "address field" of feature 6c is to be interpreted as representing at least an address in accordance with at least one of the IP version specified by the mobile UE, rather than only an address in accordance with only one IP version specified by the mobile UE.

2.2 Claim 17 - Novelty (Articles 100(a) and 54(3) EPC)

2.2.1 The opposition division found that the subject-matter of claim 17 was not new (Article 54(3) EPC) in view of document D1.

From the indications made in point II.2.3.1 of the appealed decision and by the respondent in point 2.1 of his reply to the statement of grounds of appeal, the board understands that the opposition division used the following feature mappings:

Claim 17 |D1 |

PDP activation request message (features 5 and 6a)|"Activate PDP Context Request 402" (Fig. 4) |

includes an | |

end user address information element (features 6a, 6b)|"PDP address format" (Fig. 5, [0032]) |

including a| |

PDP type number field having a value set set to a predetermined value (feature 6b)|"information field 51" (Fig. 5), completely new PDP type, for instance "v4v6" ([0037], line 3) |

and an | |

address field representing an address in accordance with the IP version specified by the mobile UE (feature 6c)|prefix in accordance with the IPv6 definitions, suffix including at least an IPv4 address (Fig. 5, [0026], [0032])|

The board concurs with the appellant that D1 does not disclose all the features of claim 17, for the reasons set out below.

2.2.2 Paragraph [0005] of D1 also addresses the problem (cf. point 1.2 above) that, for the dual-stack solution, "it will still be necessary to activate separate PDP contexts for IPv4 traffic and IPv6 traffic". D1 therefore proposes an arrangement that has the advantage that at least two different address types, e.g. IPv4- and IPv6-type data, can be conveyed by the same transmission context (cf. paragraph [0008] of D1; Fig. 5 and paragraph [0019] of the patent: "... a common PDP is established for communicating either IPv4 internet protocol packets or IPv6 packets or both IPv4 and IPv6 packets to and from the UE 2 ..."). Further, the MS comprises means for activating a PDP context comprising means for sending an "Activate PDP Context Request 402" which may indicate whether a PDP context supporting IPv4 and IPv6 traffic is to be activated (cf. Fig. 4 and paragraph [0027] of D1). Thus, the board agrees with the opposition division insofar that D1 discloses features 1 to 6, 6a and, on the basis of the interpretation indicated in point 2.1.3 above, also feature 6c.

2.2.3 However, D1 fails to disclose feature 6b.

Using the feature mapping of the appealed decision, the combination of Fig. 5 and paragraph [0037], lines 1-6, fails to disclose that the new PDP type "v4v6" is necessarily part of "information field 51" of Fig. 5, as required by "the end user information element including a PDP type number field" (emphasis added) according to feature 6b, since:

- First, according to paragraph [0033] of D1, "... the first 32 bits of the suffix constitute an information field 51, in which it is possible to convey, from the gateway node GGSN to the mobile station MS, data necessary for connection setup ..." (emphasis added). There is no indication in D1 as to which information "information field 51" of Fig. 5 should contain when included in the "Activate PDP Context Request 402" message sent in the opposite (i.e. uplink) direction, i.e. from the MS to the GGSN.

- Second, in D1, the "Activate PDP Context Request 402" message in which "information field 51" of the "PDP Address" field should be included already comprises a "PDP Type" field for this purpose (cf. the reference to D11 in paragraph [0030] of D1 as well as D11, page 127, last paragraph:

"1) The MS sends an Activate PDP Context

Request (NSAPI, TI, PDP Type, PDP Address,

Access Point Name, QoS Requested, PDP

Configuration Options) message to the

SGSN ...".

Therefore, there is no reason to infer from the teaching of D1 that "information field 51" should indeed be used when introducing the new PDP type "v4v6" suggested in paragraph [0037], since there are other known possibilities available for this purpose. In conclusion, although D1 discloses both an "end user information element" and a "PDP type number field" within the "PDP activation request message", there is no implicit or explicit teaching of an "end user information element including a packet data protocol type number field" (emphasis added) as required by feature 6b.

The arguments put forward by the respondent in this respect are not persuasive:

2.2.4 First, the respondent argued that the embodiment described in Fig. 5 was not limited to the downlink direction (GGSN to UE). The downlink direction was used as an example but was clearly not limiting, because the very same information was also suggested to be used between GGSN and MS, which comprised the transfer from the UE to GGSN, i.e. in the uplink direction, too. The respondent referred to D1, paragraph [0033], last sentence; paragraph [0029], first sentence and paragraph [0026], first sentence.

Second, the respondent noted that the PDP type field and the PDP address field of D11 were coded according to the disclosure of Fig. 5, since D11 was silent on any PDP Type field and the PDP address coding as such. Said coding was another level of detail for the given PDP type element that did not change the nature or existence of said PDP type element. From paragraph [0032] of D1, it was explicit that Fig. 5 illustrated a PDP address format of 128 bits. From paragraph [0033] of D1 (line 30), it was explicit that, in "information field 51", it was possible to indicate whether both of the address types were available in GGSN, hence to indicate the PDP type. On a logical level, it was clear that both information elements, PDP address and PDP type, were to be transported in this format.

2.2.5 The board disagrees. Paragraphs [0032] and [0033] of D1 relate to the message sent in the downlink direction. How the "information field 51, in which it is possible to convey, from the gateway node GGSN to the mobile station MS, data necessary for connection setup" should look like in a message sent from the MS to the GGSN in general, and in the "Activate PDP Context Request" of Fig. 4 in particular, is purely speculative. However straightforward the use of "the very same information" by analogy in an uplink message may be, such as the "PDP context activation or modification request" of paragraphs [0026] and [0027] of D1, it cannot be considered an implicit disclosure. The fact remains that none of these paragraphs of D1 indeed discloses the specific fields of such "Activate PDP Context messages" in the uplink direction. The skilled person could arguably "fill this gap" with not just one, but a plurality of more or less obvious possibilities. Consequently, this discussion belongs to the realm of inventive step rather than novelty.

2.2.6 The respondent, furthermore, introduced an additional feature mapping following the board's observation that a "PDP type" field was already implicitly disclosed in the "Activate PDP Context Request" known from D1 (referring to D11 in paragraphs [0003], [0029] and [0030]). According to the new mapping, features 6 and 6a to 6c were disclosed as follows:

Feature 6:

The common PDP context is established (D1, Fig. 4, "Activate PDP Context Request 402"; [0027]: "On activating the PDP context the mobile station MS transmits 402 for GGSN a request (Activate PDP Context Request)"). Said common PDP context shall communicate internet protocol packets ([0027]: "The request may be in accordance with the present specifications, or it may indicate whether MS supports IPv4 and IPv6 traffic and/or a PDP context supporting IPv4 and IPv6 traffic is to be activated" (emphasis added)). The IP packets shall be in accordance with an IP version specified by the mobile UE ([0027]: "The request may be in accordance with the present specifications, or it may indicate whether MS supports IPv4 and IPv6 traffic

and/or a PDP context supporting IPv4 and IPv6 traffic is to be activated" (emphasis added).

Feature 6a:

The PDP activation request message includes an "end user address information element" (D11, page 127, last paragraph: "The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) message to the SGSN" (emphasis added).

Feature 6b:

The end user information element including a "PDP type number field" having a value set to a predetermined value to indicate a request for the common PDP context (D11, page 127, last paragraph: "The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) message to the SGSN' (emphasis added); in combination with D1, [0037]: "The system may also introduce a completely new PDP type, for instance 'v4v6', which defines that both IPv4 traffic and IPv6 traffic can be transferred by using said PDP context" (emphasis added).

Feature 6c:

An address field representing an address in accordance with the IP version specified by the mobile UE (D11, page 127, last paragraph: "The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) message to the SGSN" (emphasis added). The address is suitable for communicating the internet packets using the common PDP context ([0026]: "MS may also indicate in the request, or according to another embodiment, in the IPv6 address that the IPv6 address also includes the IPv4 address that is to be used in data transmission" (emphasis added).

This new feature mapping is not convincing either. Paragraph [0037] of D1 does not disclose where the "completely new PDP type, for instance 'v4v6'", should be included. It could be in the "information element 51" part of a "PDP address format", as initially suggested by the respondent, it could be in the "PDP type field" of an "Activate PDP Context Request", as pointed out by the board in its preliminary opinion, or it could be elsewhere. Paragraph [0026] of D1 discloses that the MS may indicate in the request or in the IPv6 address that the IPv6 address also includes the IPv4 address that is used to be in data transmission. Even if this indication might specify the IP version, this paragraph fails to disclose where in the request or in the IPv6 address the indication is to be made. There is a difference between an "implicit disclosure", which leads the skilled reader to the firm belief that something which is not explicitly indicated must still necessarily be present, and "filling a gap" in a document. This case is an example of the latter. D1 does not directly and unambiguously disclose where the new PDP type according to paragraph [0037] or the indication of paragraph [0026] should appear. The skilled person entrusted with the task of filling these gaps could arguably think of an array of possibilities, some more straightforward than others, but this does not mean that any of them should be "implicitly disclosed" by D1.

2.2.7 Finally, the respondent submitted that Table 8 on page 167 of D11 showed that the "PDP Type" field was already common for different IP versions: "PDP type, e.g. PPP or IP".

This is likewise not persuasive. Table 8 of D11 in fact shows which MS context fields are stored as part of the Mobility Management and PDP context information in the MS, rather than their actual values. In line with the prior art acknowledged in the patent itself, D11 discloses an IP-version-specific PDP type within the "Activate PDP Context Request message" at least at page 126, first paragraph:

"1) The MS sends an Activate PDP Context Request

message to the SGSN as defined in clause 'PDP

Context Activation Procedure'. The MS shall

leave PDP Address empty and set PDP Type to

IPv6."

2.2.8 In summary, neither D1, read as a whole and considering specifically the combination of Fig. 5 with either of paragraphs [0026], [0037] and [0038], nor D1 read in combination with D11 directly and unambiguously discloses feature 6b of claim 17.

2.2.9 At least for this reason, the subject-matter of claim 17 is new in view of D1 (Article 54(3) EPC) and, consequently, the ground for opposition under Article 100(a) EPC does not prejudice the maintenance of the granted patent.

2.3 Claim 17 - Amendments (Articles 100(c) and 123(2) EPC)

2.3.1 The board agrees with point II.2.2 of the appealed decision that the subject-matter of claim 17 is directly and unambiguously derivable from at least claims 1, 2 and 19 as originally filed.

2.3.2 The respondent, though, submitted that claim 17 contravened Article 123(2) EPC because the following essential features were missing: "IPv4" and "IPv6", "Address Field Content" and the limitation towards "a single IP version".

This is also not convincing. The explicit reference to "IPv4" and "IPv6" appears exclusively in dependent claim 4 as filed, which is an indication that these features are presented as preferred alternatives. As to the limitation towards "a single IP version", this objection seems to be at odds with the respondent's arguments submitted on page 9 of his reply to the statement of grounds of appeal, according to which "feature 6c is not limited to a single internet protocol version as this is simply not required". Furthermore, the wording of feature 6c has been taken from original claim 2 rather than from an embodiment of the description.

2.3.3 Thus, the ground for opposition under Article 100(c) EPC does not prejudice the maintenance of the patent either.

2.4 Sufficiency of disclosure (Article 100(b) EPC)

2.4.1 The respondent has not pursued this objection in his reply to the statement of grounds of appeal and the board sees no reason to diverge from the conclusions attained by the opposition division in point II.2.1 of the appealed decision.

2.4.2 Hence, the ground for opposition under Article 100(b) EPC does also not prejudice the maintenance of the patent.

3. Remittal of the case (Article 111(1) EPC)

3.1 It follows from the above that independent claim 17 of the main request is new (Article 54(3) EPC) in view of document D1.

3.2 However, during the opposition proceedings, further novelty and inventive-step objections were raised against the main request in view of other prior-art documents. The opposition division did not decide on any of these issues, nor have either of the parties elaborated upon them in the appeal proceedings. Under the present circumstances, it is not appropriate to take a final decision on novelty (Article 54(2) EPC) and inventive step (Article 56 EPC). This represents a "special reason" within the meaning of Article 11 RPBA 2020 for remittal of the case.

3.3 Consequently, the board remits the case to the opposition division for further prosecution under Article 111(1) EPC, on the basis of the claim requests on file.

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the opposition division for further prosecution.