T 2051/15 (Seamless handover/ERICSSON) of 5.9.2019

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division refusing European patent application No. 08779269.3 (international publication No. WO 2008/133587 A1).

II. The refusal was based, inter alia, on the ground that the subject-matter of claim 1 of the third auxiliary request lacked an inventive step (Article 56 EPC) having regard to the disclosures of, inter alia, D15 and D16 (see document list below, point X). Regarding a fourth auxiliary request, the examining division held that the subject-matter of claim 1 prima facie did not involve an inventive step either. For this reason, it did not admit the request (Rule 137(3) EPC). The remaining requests were refused for other reasons not relevant to the board's decision.

III. With the statement of grounds of appeal, the appellant filed claims respectively of a main request and first and second auxiliary requests.

IV. In a communication accompanying a summons to oral proceedings, the board gave, inter alia, a negative preliminary opinion as to the inventiveness of the subject-matter of claim 1 of each request.

V. Together with a written response dated 1 August 2019, the appellant filed amendments to the claims of all the requests on file.

VI. Oral proceedings before the board were held on 5 September 2019.

The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the claims of the main request or, in the alternative, on the basis of the claims of either a first or a second auxiliary request, all requests as filed with the submission dated 1 August 2019.

At the end of the oral proceedings, the chairman announced the board's decision.

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

"A method of supporting seamless handover of a mobile station (20) from a source base station (16-1) to a target base station (16-2) in a wireless communication network, where base stations receive Packet Data Convergence Protocol, PDCP, protocol data units from mobile stations for ordered, sequential transfer as PDCP service data units to an associated core network, said method comprising:

during handover execution, receiving (36) at the target base station PDCP service data units and sequence number information forwarded from the source base station, wherein the forwarded PDCP service data units comprise PDCP service data units being held at the source base station for sequential transfer to the associated core network and the forwarded sequence number information indicates sequence numbers corresponding to the forwarded PDCP service data units;

reordering the forwarded PDCP service data units as needed at the target base station for sequential transfer from the target base station to the associated core network, characterized in that the reordering includes

identifying missing PDCP service data units based on the forwarded sequence number information, and

requesting (7,9,10) retransmission by the mobile station (20) of PDCP protocol data units regenerated from the missing PDCP service data units."

VIII. Claim 1 of the first auxiliary request is the same as claim 1 of the main request except that the wireless communication network referred to in the claim is "a Long Term Evolution, LTE, wireless communication network", and in that the final feature reads:

"requesting (7,9,10) retransmission by the mobile station (20) of PDCP protocol data units, whereby the PDCP protocol data units are regenerated by the mobile stationfrom the missing PDCP service data units using different ciphering than for the PDCP protocol data units received by the source base station."

IX. Claim 1 of the second auxiliary request is the same as claim 1 of the first auxiliary request except that the final feature reads:

"requesting (7,9,10) retransmission by the mobile station (20) of PDCP protocol data units regenerated by the mobile station from the missing PDCP service data units using different ciphering and different header compression than for the PDCP protocol data units received by the source base station."

X. The following documents are relevant to the board's decision:

D15: 3GPP document No. R2-071590

D16: 3GPP document No. R2-063247

D17: 3GPP joint document Nos. S3-070272 and S3-070234

D18: 3GPP document No. R3-070383

More detailed citation information is set out in the impugned decision at the beginning of section II, "Reasons for the Decision".

Reasons for the Decision

1. Main request - claim 1 - inventive step

1.1 The application concerns a method of supporting seamless handover. The method operates at the PDCP sub-layer, which is a protocol layer used in LTE-based mobile communication systems. In normal operation, a retransmission mechanism (also called ARQ) operates between a mobile terminal (in the following also referred to as "UE") and a base station ("eNB") to which it is connected. The retransmission mechanism ensures that the mobile station retransmits PDCP protocol data units (which contain PDCP service data units, i.e. SDUs) which are not acknowledged by the eNB. In normal operation (i.e not a handover situation), an eNB retains out-of-sequence SDUs until missing SDUs of the sequence are successfully received. When all SDUs are received, the eNB places them in the correct order for onward transmission to the core network, i.e., using the terminology of claim 1, "reorders" the SDUs.

1.2 D15 is considered to represent the closest prior art. D15 is an LTE-related document concerned with handover of the mobile terminal from a first base station ("source eNB") to a second base station ("target eNB").

1.3 Point 10.1.2.3, last paragraph, of D15 reads as follows:

"Upon handover, the source eNB forwards uplink PDCP SDUs successfully received in-sequence to SAE Gateway, forwards uplink PDCP SDUs received out-of-sequence to the target eNB and discards any remaining uplink RLC PDUs. The UE re-transmits the uplink PDCP SDUs that have not been successfully received by the source eNB. Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB.

Re-ordering of uplink PDCP SDUs during handover is based on a continuous SN [sequence number] and is provided by the re-ordering function at the target eNB PDCP layer, which can be activated at least during inter-eNB mobility." (Board's underlining).

1.4 It follows from this passage that D15 discloses all the features of the preamble of claim 1. This was not disputed.

1.5 With regard to re-transmission, D15 discloses that "The UE re-transmits the uplink PDCP SDUs that have not been successfully received by the source eNB" (see the second passage underlined above). In the board's understanding,this means SDUs "not successfully received and acknowledged", since the UE does not know whether SDUs have been successfully received unless an acknowledgement has been received.

1.6 The problem to be solved starting out from D15 can be considered as being to reduce the number of transmissions of duplicate SDUs from the UE. This general problem does not rely on a knowledge of the solution, since it is mentioned in D15, point 2, that "the HO procedure should be lossless, it should not duplicate SDUs ...".

1.7 The appellant argued that the statement in D15 that the handover procedure "should not duplicate SDUs" did not refer to the UE-eNB interface but to the eNB-core network interface. The board finds this argument unconvincing since the term "lossless", as used in the above-cited sentence, clearly refers to the radio link, since that is the main source of lost SDUs, and logically therefore the requirement to not duplicate transmissions refers to the same.

1.8 In seeking a solution to this problem, the skilled person would be aware of document D16, which is entitled "SDU Handling During Inter eNB Handover". D16 concerns the forwarding of RLC SDUs rather than PDCP SDUs. However, RLC and PDCP are adjacent sub-layers in which the ARQ mechanism for normal transmissions would be essentially the same. Furthermore, the introduction of D15, point 1, includes the statement: "In the uplink, the source eNB should forward all successfully received uplink SDUs to the SAE Gateway and discard any remaining uplink segments.". This is the same starting point as D16, point 1, which states that "Upon handover, the source eNB forwards all successfully received uplink RLC SDUs to the aGW and discards any remaining uplink RLC PDUs". D15, point 2, goes on to state that "Moving PDCP to the eNB should not change how E-UTRAN was agreed to provide mobility.". In other words, the skilled person's first recourse for solving problems involving retransmission of PDCP SDUs would be to consult documents concerned with the earlier concept in which the RLC layer is terminated at the eNB.

1.9 D16, point 2.1, identifies the cause of excessive retransmissions: "A UE has to retransmit all the unacknowledged RLC SDUs even if they are successfully received at the source eNB", and "The entire problem described above comes from the fact that UE does not have up-to-date information regarding eNB's reception of UL traffic. If a UE can have information regarding all the successfully received RLC SDU in the source eNB, the UE will be able to transmit only SDUs that are not successfully transmitted to the source eNB".

D16, point 2.1, then discloses the following solution:

"One method to make UE aware of the reception of the reception status of the source eNB is that after sending handover command, source eNB informs target eNB of information regarding the SDUs that are successfully decoded and delivered to aGW. Then, the target eNB relays the information to the UE by including it into the response message to handover complete message from the UE. By using this information, the UE can transmit only RLC SDUs that are not acknowledged by source eNB."

1.10 The skilled person who implemented this solution in the context of D15 would arrive at a solution in which the source eNB reports to the target eNB the sequence numbers (SN) of the SDUs successfully received and delivered and the target eNB relays these SNs to the UE. This report would consist of the SNs of the SDUs forwarded by the source eNB to the network, in addition to the SNs of those SDUs held pending and forwarded to the target eNB as already performed in D15. In D15, these latter SNs are transmitted to the target eNB together with the forwarded SDUs, so that re-ordering can be carried out (cf. D15, page 5, lines 6-8). Therefore, the result of combining D15 and D16 would be that, in addition to what is already performed in D15, the report containing the SNs would be relayed on to the UE. The UE would then implicitly identify the missing SDUs for retransmission.

1.11 The only difference between this solution and claim 1 is that claim 1 requires the target eNB to identify the missing SDUs based on the SNs and to request retransmission by the UE, instead of the UE identifying the missing SDUs from the report sent by the target eNB.

1.12 However, it would have been obvious to the skilled person that any of the three nodes in possession of the same information (i.e. information concerning which SDUs have been successfully received) could equivalently identify the missing SDUs. These nodes are respectively the source eNB, the target eNB and the UE. Furthermore, in a communication network, it is commonplace to carry out processing in network elements with the most processing capacity. In the present case, that would self-evidently be one of the two eNBs, since it is a standard aim in mobile networks to reduce the amount of processing to be carried out in a mobile station. Consequently, it would be obvious to move the identifying of the missing SDUs to either one of the eNBs, including the target eNB. The skilled person would thus arrive at the subject-matter of claim 1 without exercising inventive skill.

1.13 The appellant argued that the source and the target eNBs were only in possession of the same information in an ideal situation where no forwarded SDUs were lost or delayed on the link between the two eNBs, and that identifying the missing SDUs in the target eNB had the advantage that such missing or lost SDUs could be taken into account.

However, even accepting this advantage (which nevertheless is assessed to be negligible given that the inter-eNB connection is a wired connection), this would merely be a hint to the skilled person to select the target eNB rather than the source eNB. In any case, there is no evidence of any unexpected or surprising improvement which could justify the acknowledgement of an inventive step, noting that in the description of the present application, it is proposed to carry out processing either in the source eNB or the target eNB, without there being any discussion whatsoever that the latter embodiment is advantageous (cf. paragraph [0051]). In any case, plausibly the skilled person would consider it more logical to identify the missing SDUs in the target eNB as this is the eNB responsible for re-ordering the SDUs.

1.14 The appellant further argued that a change of location of the function for identifying the missing SDUs required a drastic change in D16s architecture with unclear side effects.

However, the change of architecture by moving the identifying function from the UE to the target eNB is apparently not drastic. Moreover, the consequences appear to be entirely predictable (similar to changing from an ACK-based ARQ mechanism to a NACK-based one).

1.15 The appellant further argued that the skilled person starting out from D15 would not obviously recognise the reason why there was poor performance during handover. In this respect, analysing data flows was not a routine task but one from which inventions were produced.

However, the skilled person starting out from D15 does not initially need to recognise the reason for poor performance on the basis of common general knowledge, since he would at the latest become aware of the reason when consulting D16. This argument is therefore not convincing either.

1.16 Consequently, the subject-matter of claim 1 does not involve an inventive step (Articles 52(1) and 56 EPC).

2. First auxiliary request - claim 1 - inventive step

2.1 Claim 1 of the first auxiliary request essentially differs from claim 1 of the main request in that retransmission by the mobile station uses different ciphering than for the PDCP protocol data units received by the source base station.

2.2 The use of different ciphering is assessed to not contribute to inventive step for the following reasons. Firstly, it is obvious on the basis of common general knowledge that communication between a UE and a new eNB should use a different ciphering key (cf. e.g. D17), i.e. that during handover, the ciphering key at some point must be changed. This was not challenged by the appellant. Then, apparently, there are only two plausible ways of proceeding, depending on when the change of key is to take place: either the retransmitted SDUs use the ciphering state of the source eNB, or the retransmitted SDUs use the ciphering state of the target eNB. The skilled person would straightforwardly select either of these according to circumstances (e.g. whichever fits best with the remaining steps of the method). A simple choice between two alternatives does not require inventive skill.

2.3 The appellant argued that this feature avoided the need to transmit the ciphering state of the forwarded SDUs to the target eNB. However, this argument is not a convincing reason for acknowledging an inventive step since this effect would only be achieved by also forwarding deciphered rather than enciphered SDUs from the source to the target eNB (cf. paragraph [0037] of the description), which is a feature which is not claimed. Furthermore, in D15 it is proposed that ciphering takes place at the PDCP sub-layer which resides at the eNB. It is therefore obvious that the forwarded SDUs would be deciphered at the source eNB before forwarding, obviating the need to transfer the ciphering key of the source eNB to the target eNB.

2.4 The appellant further argued that there was a combinatorial effect between this feature and the re-transmitting feature in view of a processing efficiency gain due to only having to cipher and re-transmit the SDUs which are actually missing. However, even if there is plausibly some benefit in reducing the number of SDUs to be re-coded, this is merely the inherent, entirely unsurprising bonus effect resulting from taking the obvious step of using the ciphering state of the target eNB for retransmissions. Consequently, this effect does not justify the recognition of an inventive step either.

2.5 The appellant further argued that D15 and D17 could not be combined because it was impossible to attend two separate working group meetings at the same time. This argument is however unconvincing because there is no need for "the skilled person" to have attended any of these meetings in order to be able to study D15 and D17. In any case, D17 is only referred to as confirming what is taken to be common general knowledge (cf. point 2.2 above).

2.6 In view of the above and for the reasons set out in point 1 above, the subject-matter of claim 1 of the first auxiliary request does not involve an inventive step (Articles 52(1) and 56 EPC).

3. Second auxiliary request - claim 1 - inventive step

3.1 Claim 1 of the second auxiliary request differs from claim 1 of the first auxiliary request in that retransmission by the mobile station additionally uses "different header compression than for the PDCP protocol data units received by the source base station".

3.2 Using different header compression relates to the changing of another uplink parameter analogous using to different ciphering. Assuming that the idea per se to use different header compression in each base station is obvious on the basis of common general knowledge, which the appellant did not deny (cf. e.g. D18), the same considerations apply, mutatis mutandis, as discussed above in respect of using different ciphering (the appellant and the examining division refer to this approach as "parallelism"). This feature therefore does not contribute to inventive step either.

3.3 The appellant argued, referring to D18, that this did not take account of the possible different points in time that a change in header compression state could take effect, namely (a) after the handover had been completed, or (b) already for the retransmission of the missing SDUs (this being the claimed solution), both options being practicable.

3.3.1 In the board's view, analogously to the change of ciphering state, both (a) and (b) would be considered by the skilled person and either one or other adopted according to circumstances and without inventive skill (cf. point 2.2 above). Consequently, this argument is, likewise, unconvincing.

3.3.2 The appellant further drew attention to the "interworking" of ciphering and header compression (cf. page 15 of the statement of grounds of appeal). The subsequent discussion appears rather speculative (and not very comprehensible), and none of these aspects are mentioned in the description. As regards interworking, it appears to be entirely logical in respect of retransmissions to treat the ciphering state and header compression in the same way as both are essentially a form of coding handled by the same PDCP sub-layer. This argument is therefore also unconvincing.

3.4 In view of the above and the reasons set out in points 1 and 2 above, the subject-matter of claim 1 of the second auxiliary request does not involve an inventive step (Articles 52(1) and 56 EPC).

4. Conclusion

As there is no allowable request, it follows that the appeal must be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.