T 3257/19 (Mobility protocol type/QUALCOMM) of 20.1.2023

Summary of Facts and Submissions

I. The appeal was lodged against the decision of the examining division to refuse the present European patent application for lack of novelty (Article 54 EPC) with respect to claims 11, 14 and 15 of a main request, for lack of inventive step (Article 56 EPC) with respect to at least claim 1 of each of the main request and auxiliary requests 1, 2 and 3, and for lack of clarity (Article 84 EPC) with respect to the independent claims of auxiliary request 3.

II. During the examination proceedings, the examining division referred inter alia to the following prior-art document:

D11: Qualcomm Europe: "Processing PCC in Release 8 -

IP-CAN Type & RAT Type", S2-081161, 3GPP SA2 #63,

Athens, Greece, February 2008.

III. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the claims of one of four requests (main request, auxiliary requests 1, 2 and 3) subject to the decision and re-submitted with the statement of grounds of appeal.

IV. In a communication pursuant to Article 15(1) RPBA 2020, the board stated its (negative) preliminary opinion on the allowability of all the claim requests.

V. In response to that communication, the appellant informed the board that it would not be attending the arranged oral proceedings, and requested a decision "according to the current status of the file".

VI. The board then cancelled those oral proceedings.

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

"A method (700) for handling policy rules in wireless networks, comprising:

receiving (702) encapsulation information related to data flow communication from a core network gateway (206), wherein the encapsulation information includes a mobility protocol type;

generating (704) one or more policy rules related to the data flow communication;

transmitting (710) the policy rules to an access network gateway (204);

and

transmitting (708) the received encapsulation information to the access network gateway (204)."

Claim 1 of auxiliary request 1 is identical to claim 1 of the main request.

Claim 1 of auxiliary request 2 reads as follows:

"A method (700) for handling policy rules in wireless networks, comprising:

receiving (702) encapsulation information related to data flow communication from a core network gateway (206), wherein the encapsulation information includes a mobility protocol type;

generating (704) one or more policy rules related to the data flow communication;

transmitting (710) the policy rules to an access network gateway (204);

and

transmitting (708) the received encapsulation information to the access network gateway (204), wherein a trusted non-3GPP IP access device acts as the access network gateway."

Claim 1 of auxiliary request 3 reads as follows:

"A method (700) for handling policy rules in wireless networks, comprising:

receiving (702) encapsulation information related to data flow communication from a core network gateway (206), wherein the encapsulation information includes a mobility protocol type;

generating (704) one or more policy rules related to the data flow communication;

transmitting (710) the policy rules to an access network gateway (204);

and

transmitting (708) the received encapsulation information to the access network gateway (204) for utilizing the encapsulation information to unencapsulate tunneled IP flows, wherein a trusted non-3GPP IP access device acts as the access network gateway."

Reasons for the Decision

1. Decision in written proceedings

1.1 In accordance with established case law, where oral proceedings are appointed upon a party's request and where the party subsequently expresses their intention not to attend, the appellant's statement is equivalent to a withdrawal of the request for oral proceedings.

1.2 As the board does not consider holding oral proceedings to be expedient in this case (see Article 116(1) EPC), these were cancelled and the requested decision is to be handed down in written proceedings (Article 12(8) RPBA 2020).

1.3 Given that the appellant's indication of non-attendance was not submitted within one month of notification of the board's communication under Article 15(1) RPBA 2020, no reimbursement of the appeal fee can be ordered under Rule 103(4)(c) EPC.

2. Effective filing date of the application

The examining division concluded in Reasons 7.4 of the appealed decision that the effective filing date pursuant to Article 89 EPC of the claims of all four claim requests was, at the earliest, 14 March 2008. The appellant has not questioned this finding and the board sees no reason to contest it either.

3. Publication date of document D11

3.1 The appellant submitted that the publication date of document D11 had not been reliably established by the examining division. In particular, the appellant objected that the examining division failed to explain the meaning of the "server date" referred to in the reasons of the appealed decision and, even if that date was considered as the "upload date" of the presently downloadable version of the zip-file, the reasons were completely silent with regard to when the discussed zip-file was indeed made available for download by anyone. Even if it was the case, it could not be determined that the document "could be found with the help of a public web search engine by using one or more keywords all related to the essence of the content of that document", with reference to case T 1553/06, Headnote 4. Furthermore, the content of the written contributions in the list provided by the examining division could not be reliably determined based on the list of contributions alone. It was not apparent whether the referenced list, which bears a date in 2019, was created and made available to the public prior to the effective date of the application. There were various inconsistencies between the dates borne by document D11 and the date attributed to the respective zip-file at the server referred to by the examining division. In addition, the meeting referenced in the appealed decision had taken place on "18-22 February 2008".

3.2 The appellant seems to argue that the examining division failed to establish beyond reasonable doubt the exact earliest date of public availability of those documents. However, according to the established case law (see e.g. T 884/18, Reasons 6), this is no longer the applicable standard of proof required for assessing whether or not documents downloaded from the Internet or standard preparatory documents belong to the state of the art. In view of the available evidence and arguments, the board is sufficiently convinced that D11 was indeed made available by file upload to a public 3GPP server before the 3GPP TSG-SA2 Meeting #63 took place, i.e., at any rate, well before 14 March 2008.

3.3 It follows that document D11 is to be considered prior art under Article 54(2) EPC.

4. MAIN REQUEST

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

A method for handling policy rules in wireless networks, comprising:

(a) receiving encapsulation information related to data flow communication from a core network gateway,

(b) wherein the encapsulation information includes a mobility protocol type (MPT);

(c) generating one or more policy rules related to the data flow communication;

(d) transmitting the policy rules to an access network gateway;

(e) transmitting the received encapsulation information to the access network gateway.

4.1 Claim 1 - inventive step (Article 56 EPC)

4.1.1 The appellant considered document D11 to be the closest prior art, since it was directed to a multi-mobility protocol architecture involving signalling exchange with various access networks. In the appellant's favour, the board takes D11 as a suitable starting point for the assessment of inventive step.

4.1.2 Using the wording of claim 1, document D11 discloses:

A method for handling policy rules in wireless networks, comprising:

(a) receiving (p. 12, step after C.1; p. 13, step 5; p. 14, step 6a) encapsulation information related to data flow communication from a core network gateway (p. 12 to 14: "PDN GW"),

(b) wherein the encapsulation information includes a MPT (p. 12 to 14: "MPT");

(c) generating one or more policy rules related to the data flow communication (p. 9: "Based on this information, the PCRF can derive tunneled QoS rules for the BBERF"; p. 12 to 14: "(un-)tunneled QoS rules");

(d) transmitting (p. 12, step C.8; p. 13, step 13; p. 14, step after 7) the policy rules to an access network gateway (p. 12: "Serving GW", p. 13 and 14: "Trusted Non-3GPP IP Access").

4.1.3 The subject-matter of claim 1 thus differs from D11 in feature (e).

4.1.4 This subject-matter was considered, at least implicitly, in Reasons 13.1.2 of the appealed decision, where the examining division concluded that no technical effect was induced by feature (e), because the transmitted QoS rules already contained all the information needed by the "trusted non-3GPP IP access" device.

4.1.5 The board does not share this view. In D11, when GTP or PMIPv6 is used as MPT, the access network gateway is an endpoint of an "S2a" or "S5" tunnel and has access to un-tunnelled information from/to the UE (see e.g. page 11, steps 13 to 15; page 12, steps C.1 to C.8; page 13, steps 4 to 9). Explicitly receiving the MPT information from the PCRF helps the access network gateway verify that PCRF has considered the same MPT when generating the (un-tunnelled) QoS rules. When DSMIPv6 is used, the access network gateway is however not an endpoint of the tunnel extending between UE and PDN GW (see e.g. page 14, steps 4, 5 and 7). In this case, receiving the MPT from the PCRF enables the access network gateway to realise that the QoS rules are tunnelled and that further information, such as the encapsulation header, might be needed.

Thus, on the basis of distinguishing feature (e), the board considers the objective technical problem to be how to enable the access network gateway to verify that the QoS rules received from the PCRF correctly take into account the mobility protocol used by the UE in the system of D11.

4.1.6 The subject-matter of claim 1 does not involve an inventive step (Article 56 EPC) starting from D11 for the following reasons:

Document D11 explicitly discloses on page 9 that the PCRF needs to know what MPT is used in the core network. Based on the protocol, a different logic is used and different procedures are "expected". This means that the QoS rules subsequently provided by the PCRF to the access network gateway (e.g. "Serving GW", "Trusted Non-3GPP IP Access") should take into consideration the specific MPT to be used by the UE (e.g. GTP, PMIPv6, DSMIPv6). Otherwise, the access network gateway would not be able to correctly perform QoS filtering on encapsulated flows. Hence, forwarding the MPT information received from the PDN GW (together with the updated QoS rules) would have been the most straightforward manner to let the access network gateway verify that the PCRF has applied the correct procedures in accordance with the mobility protocol actually used by the UE.

4.1.7 The appellant submitted that, according to the teaching of D11, the "Trusted Non-3GPP IP Access" had to be aware of the MPT without being explicitly signalled by the MPT, and that D11 was not explicit with regard to the source of such knowledge at the Trusted Non-3GPP IP Access. The Trusted Non-3GPP IP Access could have been statically configured for a specific MPT, or, alternatively, the "Gateway Control" transmitted by hPCRF to the Trusted Non-3GPP IP Access in the step following step 7 on page 14 of D11 could provide the Trusted Non-3GPP IP Access with sufficient information regarding how to interpret data encapsulated in accordance with the selected MPT. However, both approaches would have limitations, such as (i) the need for a static configuration of the Trusted Non-3GPP IP Access for a specific MPT or (ii) the need for a specific implementation of hPCRF for disparate mobility protocols.

4.1.8 This is not convincing. There is no indication that D11 should suffer from the limitations (i) and (ii) indicated by the appellant and that the Trusted Non-3GPP IP Access of D11 had to be able to interpret the QoS rules irrespective of the MPT used. If PMIPv6 is used, the Trusted Non-3GPP IP Access is already aware by reason of its participation as a PMIP Tunnel endpoint (see page 13, step 9). If DSMIPv6 is used, the Trusted Non-3GPP IP Access can at least infer this situation from the fact that the QoS rules are "tunnelled" (see page 14).

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

5. AUXILIARY REQUEST 1

5.1 Claim 1 - inventive step (Article 56 EPC)

5.1.1 Claim 1 of auxiliary request 1 is identical to claim 1 of the main request. Therefore, the reasoning set out in point 4.1 above applies mutatis mutandis.

5.1.2 The appellant submitted that D11 did not recognise the limitations attributable to not providing the MPT to the access network, and that feature (e) involved a trade-off, since providing the mobility protocol type to the access network involved (i) additional signalling to which both the core network and the various access networks had to adhere, (ii) additional standardisation efforts and (iii) a paradigm shift of transferring additional responsibility towards an implementation of the access network from the implementation of the core network. These efforts resulted in enhanced flexibility with regard to signalling between the core network and the access network. Starting from D11 alone, the skilled person would thus not have arrived at the result of the above trade-off.

5.1.3 This argument is not persuasive. The skilled person, starting from D11, would generally have known that disadvantages (i) and (ii) are actually compensated by the advantage obtained through the addition of feature (e). As regards (iii), the addition of feature (e) constitutes no change of paradigm vis-à-vis D11, since in this document the QoS rules generated by the PCRF take into account the MPT used, as opposed to the previous situation in which the PCRF did not know which MPT was being used or whether rules were tunnelled (see "Notes" on pages 6 to 8).

5.2 Auxiliary request 1 is therefore not allowable under Article 56 EPC either.

6. AUXILIARY REQUEST 2

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

(f) wherein a trusted non-3GPP IP access device acts as the access network gateway.

6.1 Claim 1 - inventive step (Article 56 EPC)

6.1.1 Feature (f) is already disclosed by document D11 (see pages 13 and 14: "Trusted Non-3GPP IP Access"). The

subject-matter of claim 1 of auxiliary request 2 thus differs from D11 only in feature (e) and the reasoning set out in point 4.1 above applies mutatis mutandis.

6.2 Hence, auxiliary request 2 is likewise not allowable under Article 56 EPC.

7. AUXILIARY REQUEST 3

Claim 1 of auxiliary request 3 comprises all the limiting features of claim 1 of auxiliary request 2 and the following additional feature (board's outline and underlining):

(g) transmitting the received encapsulation information to the access network gateway is done for utilising the encapsulation information to unencapsulate tunnelled IP flows.

7.1 Claim 1 - clarity (Article 84 EPC)

7.1.1 The board concurs with the examining division that feature (g) is not clear, and that it is not apparent which limitation the further method step is supposed to specify.

7.1.2 The appellant submitted that this feature functionally limited the "encapsulation information" by defining its content such that it had to be suitable for the claimed use. In other words, the discussed feature defined the content of the encapsulation information such that the latter was able to serve the function of unencapsulating tunnelled IP flows. The present application (see paragraphs [0049] and [0062] as filed) defined that the encapsulation information could assume among others a NULL value, but the NULL value would not be suitable for unencapsulating the tunnelled IP flows. Thus, by defining the suitability of the "encapsulation information" for unencapsulating, a further limitation was imposed upon the (generic) term "encapsulation information".

7.1.3 This is not convincing. It is not apparent that the addition of feature (g) should necessarily further limit feature (e) so as to exclude the inclusion of a "NULL value" as part of the encapsulation information. Even in those cases where the encapsulation information is set to NULL, the serving gateway still must perform decapsulation of IP flows as part of the GTP or PMIP tunnelling between itself and the PDN gateway (see paragraph [0050] of the description as filed). Hence, claim 1 fails to clearly establish for which

subject-matter protection is actually sought.

7.2 Auxiliary request 3 is thus not allowable under Article 84 EPC.

8. Since there is no allowable claim request on file, the appeal must be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.