T 1580/23 (Adapted PDU header field/NOKIA) 28-05-2025

1. MAIN REQUEST

Claim 1 as granted comprises the following limiting features:

1 A method comprising

1.1 first determining for a PDU, to be provided to a receiver entity,

1.1.1 whether a segment of an SDU, is to be included in the PDU and, if so,

1.2 second determining the position of the segment relative to the SDU,

1.3 the PDU comprising a header part and a data field part;

1.4 determining whether to include information in the header part in dependence of the first determining, and, if so,

1.5 determining the content of the information in the header part in dependence on the second determining;

1.6 providing the PDU to a receiver entity

1.7 determining that the position of the segment of the SDU is between a first segment and a last segment of the SDU and

1.8 determining therefore that the content of the information in the header part indicates segment offset.

1.1 Claim 1 - novelty (Articles 100(a) and 54 EPC)

1.1.1 Document D4 concerns a method in which a sending entity first determines, for a PDU to be provided to a receiver entity, whether a segment of an SDU is to be included in the PDU and, if so, it determines the position of the segment relative to the SDU. The PDU comprises a header part and a data field part. The header part includes, for each SDU segment, corresponding "SN, D and ELI fields" (see Fig. 13). The SN field is an SDU sequence number of the corresponding SDU segment. Furthermore, the two-bit "D field" indicates the type of SDU segment (i.e. "00" for a complete SDU, "01" for the first segment of an SDU, "10" for the last segment of an SDU and "11" for a "middle segment" of an SDU). In addition, the "D field" and the "ELI field" together specifically indicate the parts of the SDU included in the SDU segment (e.g. its length). The sending entity determines the values of the SN, D and ELI fields for each SDU segment included in the PDU according to its type and provides the PDU to the receiver entity.

1.1.2 In Reasons 8 of the appealed decision, the opposition division found that document D4 disclosed all the features of claim 1.

1.1.3 The appellant argued that D4 was silent with respect to feature 1.4. The findings of the opposition division in Reasons 8.4, according to which the "D, SN, ELI fields" were included in the "header part" only if it was determined that the SDU was not included in full within the PDU to be transmitted was incorrect. The opposition division only could have arrived at its wrong conclusion by considering Figure 13 of D4 in isolation, i.e. without regard to the description of D4. However, according to the established case law of the Boards of Appeal, a figure could never be interpreted in isolation from the overall content of the application but only in that general context, referring to decision T 676/90. Because D4 taught to always include the "D, SN, ELI fields" in the "header part" irrespective of whether a complete SDU or an SDU segment was to be included in the PDU, D4 did not show feature 1.4 of claim 1 of the opposed patent.

1.1.4 The board agrees with the appellant's interpretation of document D4 to the extent that the header of D4 comprises an instance of the SN, D and ELI fields also if the PDU comprises a complete SDU - rather than a "middle segment". In this regard, the passage of D4 cited in paragraph (34) of the statement of grounds of appeal makes apparent that, in D4, a complete SDU is still considered to be a segment ("If the D field indicates that the segment is a complete SDU, ..."). However, the appellant's conclusion set out in paragraph (35) of the statement of grounds of appeal is that "D4 teaches that the header portion of a transferred data unit includes an SN field, an ELI field and a D field irrespective of whether a complete SDU or an SDU segment is to be included in the PDU". Thus, the appellant's definition of an SDU segment - contrary to that of D4 - would exclude a complete SDU. In addition, the appellant derives from this definition that the determination of feature 1.4 must be such that information is to be included in the "header part" if and only if it is determined that only an SDU segment is to be included in the PDU. In other words, according to the appellant, if the PDU is to contain only complete SDUs, no information shall be included in the header and, consequently, D4 cannot anticipate the claimed subject-matter.

1.1.5 The board disagrees. Whatever happens in the system of document D4 when the PDU contains only complete SDUs is irrelevant for the present novelty discussion, since claim 1 does not impose any negative limitation on that specific case. Rather, the claim concerns "middle segments" as per feature 1.7 (see also paragraph (106) of the statement of grounds of appeal). In the system of D4, each SDU segment included in a PDU can be uniquely represented by an SN, a D field, a special corresponding ELI field, and corresponding data (see D4a, page 12/14, second paragraph and Fig. 13). This means that, as indicated by the opposition division in Reasons 8.4 of the appealed decision, each time it is determined that a "middle segment" of an SDU is to be included in the PDU, it is also determined to include corresponding "SN, D and ELI fields" in the "header part" in dependence of the "first determination" step. That alone thus suffices to disclose feature 1.4 and the subject-matter of claim 1 is therefore not new in view of D4.

1.2 It follows that the ground for opposition under Article 100(a) EPC in conjunction with Article 54 EPC prejudices the maintenance of the patent as granted.

2. AUXILIARY REQUESTS

Claim 1 of each of auxiliary request 1 to 7b differs from claim 1 as granted in the following sub-features:

(a) "information field in the header part" in features 1.4, 1.5 and 1.8 [auxiliary request 1],

(b) "wherein the information comprises a length indicator field" in feature 1.4 [auxiliary request 2],

(c) "the [deleted: information] length indicator field" in features 1.5 and 1.8 [auxiliary request 2],

(d) "wherein the header part comprises framing information, the framing information comprising a first bit indicative of whether the first byte of the data field corresponds to the first byte of a SDU and a second bit indicative of whether the last byte of the data field corresponds to the last byte of a SDU" in feature 1.4 [auxiliary request 3] or in feature 1.3 [auxiliary requests 4 to 6],

and in the addition of the following features as characterising portion of claim 1 of auxiliary requests 4 to 7 and 7b (board's outline):

1.9 the header part comprises [a] data field element (DFE) information[field], the DFE indicative of the number of DFEs in the data field and

1.10 comprising providing DFE information[field] after the second bit of the framing information and before the first bit of the framing information.

2.1 Auxiliary requests 1 to 3 - claim 1 - novelty (Article 54 EPC)

2.1.1 The appellant submitted that the subject-matter of claim 1 of auxiliary requests 1, 2 and 3 was new and inventive for the same reasons as presented in the context of claim 1 of the main request.

2.1.2 The board nonetheless agrees with the opposition division that:

- the "ELI field" of D4 in fact discloses

sub-features (a), (b) and (c),

- the "D field" of D4 constitutes framing information in accordance with sub-feature(d). The "D field" comprises:

(i) a first bit indicative of whether the first byte of the data field corresponds to the first byte of an SDU, i.e. it does when D contains 00 (complete SDU) or 01 (first segment), it does not when D contains 10 (last segment) or 11 (middle segment), and

(ii) a second bit indicative of whether the last byte of the data field corresponds to the last byte of an SDU, i.e. it does when D contains 00 (complete SDU) or 10 (last segment), it does not when D contains 01 (first segment) or 11 (middle segment).

2.1.3 Thus, none of auxiliary requests 1, 2 and 3 is allowable under Article 54 EPC either.

2.2 Auxiliary requests 4 to 7 and 7b - claim 1 - inventive step (Article 56 EPC) starting from D4

Starting point

2.2.1 Document D4 is to be considered as a suitable starting point for the assessment of inventive step of the

subject-matter of claim 1 of these auxiliary requests. The appellant did not dispute this.

Distinguishing features

2.2.2 The board agrees with the appellant that D4 does not disclose directly and unambiguously features 1.9 and 1.10.

Technical effect and objective technical problem

2.2.3 As to the technical effect of the distinguishing features, the appellant submitted that the presence and the placement of the "data field element (DFE)" within the header enabled a receiver to determine the data field start position in the PDU as soon as possible. In particular, the receiver thus knew the length of the LI fields part directly after having read the data field element (the number of the DFEs indicated by the DFE determined how many LI fields would follow before the start of the data part). Conversely, the receiver of the header according to Figure 13 of D4 had to read the header at least until the second last field of the header (i.e. the last "D field") in order to be aware of the number of DFEs and thus to know how long the LI fields part was. In fact, the receiver had to read the entire header, because only after reading the entire header the receiver could determine the last "D field" and, thus, the "SN fields" enclosed between the first and the last "D fields". Thus, compared to the claimed subject-matter, the receiver had to read more, i.e. process more header information before being able to actually derive the number of LI fields. Moreover, document D4 provided no motivation for the skilled person, facing the objective technical problem (namely, "to enable the receiver to determine the data field start position in the PDU as soon as possible in order to perform parallel processing at the receiver"), to modify or adapt the teaching of D4 in order to arrive at the claimed subject-matter. In fact, the skilled person would not have considered including the

"N field" of document D8 into the "header part" of D4, because the teaching of D4 and, in particular, the data packet format shown in D4, was based on the concept that, for each data segment included in the PDU, separate header information fields were provided (referring to D4, Fig. 13). Besides, D4 itself included no hint or incentive that could lead the skilled person to abandon the sequential processing disclosed therein.

2.2.4 This is not convincing. Regardless of the claimed subject-matter's silence as to the specific capabilities (in particular any parallel-processing capabilities) of the "receiver entity" mentioned in feature 1.6 of claim 1, paragraph [0029] of the opposed patent itself already implies that the technical effect invoked by the appellant (i.e. "[s]uch a field may enable the receiver to determine immediately where the data field part starts in the PDU since the receiver immediately knows how many LI fields will follow the header") cannot be achieved by solely including a field "that specifies the amount of SDUs (data field elements (DFEs)) carried in the PDU".

Rather, as the same paragraph explicitly indicates, "[by] knowing the LI field size in advance, the receiver knows where the data field part begins". Indeed, this effect can only be achieved if (a) the number of DFEs is known, (b) all the corresponding LI fields are of the same predefined fixed size and (c) there are no other fields within the PDU between the LI fields and data fields or - if present - their length is also known in advance. Indeed, only this detailed knowledge about the PDU structure as generated at the transmitter side would allow the receiver side to determine where the data field part actually starts by multiplying the number of DFEs by the respective LI field size. Since, however, feature 1.9 relates at most to condition (a), it cannot convincingly attain the alleged technical effect, either by itself or in combination with feature 1.10. In other words, the sole presence of features 1.9 and 1.10 cannot credibly cause the technical effect invoked by the appellant. Rather, additional limitations - not present in claim 1 - would be needed.

2.2.5 The appellant argued in this regard that it was not necessary to explicitly include conditions (b) and (c) in claim 1, since the latter were part of the common general knowledge of the skilled person. In particular, the appellant submitted that the proposed technical effect was encompassed by the technical teaching of the opposed patent, with reference to G 2/21. The conditions (b) and (c) could be supplemented to the information contained in the original application by the skilled person's common technical knowledge. In the background section, the original application pointed out that "the communication system and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved". In the detailed description section, the application as originally filed stated that "an example of wireless communication systems are architectures standardized by the 3rd Generation Partnership Project (3GPP)". At the international filing date, the skilled person knew that according to the 3GPP architecture, the LI fields were of a fixed size (referring, for example, to 3GPP standard TS 136 322 V12.3.0, section 6.2.2.5), i.e. condition (b). Likewise, the 3GPP standard in chapter 6 described all possible fields of an AMD PDU segment header. It consisted of a fixed part and an extension part, the latter consisting of E and LI fields (see 3GPP TS 136 322 V12.3.0, section 6.2.1.5), i.e. condition (c). Accordingly, the skilled person with their common technical knowledge in mind, and based on the application as originally filed was aware of the detailed information relating to conditions (b) and (c). Because all three conditions were met, the technical effect under dispute was actually achieved.

2.2.6 This argumentation does not sway the board either. In short, the appellant tried to prove that the addition of feature 1.9 to a well-known method according to the 3GPP standard TS 136 322 V12.3.0 would bring about the alleged technical effect by virtue of the specific use of "LI and E fields" in the referred standard, which satisfied conditions (b) and (c). However, as already stated in T 2010/22 (Reasons 4.6.1), the derivability of a credible technical effect from the original description may only be seen as a necessary requirement for the purposes of assessing inventive step but not a sufficient one; the decisive question remains whether the claimed features themselves credibly bring about the technical effect over the whole range claimed.

In the present case, the claimed method is not limited to any 3GPP standard, let alone the specific one cited by the appellant. Rather, the generic terms "SDU" and "PDU" appearing in claim 1 were used in the field of telecommunications even as part of the very basic Open Systems Interconnection (OSI) layer model. This model already refers to a (service) data unit which is to be encapsulated in another (protocol) data unit at a lower OSI layer. Thus, the sole reference to "SDU" and "PDU" in the claim is by no means sufficient to establish, in the claimed subject-matter, the same or corresponding limitations to the ones derived by the appellant from 3GPP standard TS 136 322 V12.3.0 - or any other 3GPP standard - such as the use of fixed-length "LI fields". As a consequence, the board remains of the view that, in spite of the references to 3GPP standards in the patent description, the claimed method does not impose - explicitly or implicitly - any limitations in respect of conditions (b) and (c).

2.2.7 In summary, the "DFE information[field]" according to feature 1.9 provides - at most - a count of SDU segments included in a PDU. Hence, the board agrees with the opposition division that "the ability to count the number of LI field[s] present in the header part whenever one LI field is associated with each SDU segment [...] would also be provided in the solution of D4 in the same way" (see Reasons 19.3.2 of the decision under appeal). However, these features alone cannot be credibly associated with the technical effect suggested by the appellant.

2.2.8 Since the board cannot see any other technical effect which is derivable from present claim 1 on the basis of distinguishing features 1.9 and 1.10, it must be concluded that no objective technical problem is actually solved by the claimed subject-matter. As a consequence, those features relate merely to an arbitrary or non-functional modification of the prior art (i.e. to an arbitrary data structure), which cannot contribute to an inventive step (see e.g. G 1/19, Reasons 49; T 176/97, Reasons 4.4; T 1294/16, Reasons 26.2; T 746/22, Reasons 1.5 or T 1699/22, Reasons 2.7).

2.2.9 It follows that none of auxiliary requests 4, 5 and 6 is allowable under Article 56 EPC.

2.2.10 Moreover, irrespective of admittance issues, the same conclusion applies also to auxiliary requests 7 and 7b. The amendments in those requests (cf. point X above) were actually made in view of Reasons 18.2.4 of the decision under appeal. There, only feature 1.10, but not feature 1.9, was treated as a distinguishing feature. However, feature 1.9 was already acknowledged as a distinguishing feature in the board's assessment of inventive step in points 2.2.1 to 2.2.8 above. Thus, it is not discernible, nor was it argued by the appellant, why the respective amendments would overcome the objection under Article 56 EPC.

3. Since there are no allowable claim requests on file, the appeal must be dismissed.