Interdigital Technology Corporation & Ors v Lenovo Group Limited & Ors

Lenovo initially pleaded that it would be obvious to amend the PMS to provide a trigger within claim 1; and that having done so, the requirements of claims 2 & 4 would simply follow from what was already in the standard. This is ‘Case 1’.

In the course of preparing Irvine 1, Dr Irvine explained that he spotted that the PMS already provided that, in some circumstances, SI should be sent ‘in response to’ having a non-zero grant which was too small to send a scheduled MAC-d PDU. On this basis, Lenovo amended its statement of case to plead that anticipation case, plus obviousness of claims 2 & 4 on the basis that they only involve a single, minor, obvious modification to that scheme. This is ‘Case 2’.

In their submissions, IDC placed some emphasis on the way in which Case 2 emerged and the way in which the evidence on Case 1 developed through the expert reports. For those reasons, I will need to summarise these developments.

The PMS is a substantial document. Including Annexes, it comprises more than 90 pages of dense material. Lenovo submitted that their cases of anticipation and obviousness over the PMS involve no selection from the document, since both cases assume that the Skilled Person is implementing HSUPA based on that document.

IDC submitted that Lenovo’s obviousness cases amounted to cases of obviousness over the CGK and relied upon the well-known warnings which attach to such cases – Birss J in Accord v Medac [2016] EWHC 24 (Pat), citing Floyd J. in Napp v ratiopharm [2008] EWHC 3070 (Pat). However, I consider that the ‘inconvenient details’ warning has no real application here because Lenovo rely on the whole PMS. To the extent that there are any ‘inconvenient details’ they are in the PMS itself, and in the very parts on which Lenovo’s case depends, or in the developments from the starting point.

IDC’s second overarching point was that Lenovo’s cases were infused with hindsight. I will deal with that in context.

Although Lenovo preferred to put their obviousness case first (i.e. Case 1), I will deal with alleged anticipation first i.e. Case 2. Lenovo accepted that Case 2 turns on the construction of claim 1, namely that, if IDC’s construction was correct, then Case 2 fails. Since I have found that IDC’s construction was the correct one, it follows that Case 2 fails.

Nonetheless, it is relevant to the obviousness arguments to consider how the anticipation case arose which led to Dr Irvine’s explanation of it in paragraph 9.8 of his first report. This emerged in cross-examination of Dr Irvine:

6 Q. Okay. The point I am talking about now, your para 9.8 point

7 or the opportunistic SI, the non-triggered SI, did you

8 personally identify that point or was it suggested to you?

9 A. We were talking about non-scheduled and scheduled data and

10 going through some examples. (After a pause) We were knocking

11 around some numbers to see what would happen when scheduling

12 information was being sent and that was in a discussion with

13 the lawyers. I honestly cannot remember what was the trigger

14 for that.

15 Q. Okay. Just as you honestly cannot remember the trigger, you

16 cannot honestly remember whose idea it was?

17 A. Oh, that was what I meant.

18 Q. Okay.

19 A. It was, we were having a discussion on Zoom and talking about

20 whether or not when Scheduling Information would be sent when

21 there was a mix of scheduling and non-scheduling data, and

22 came up with that situation.

23 Q. When did this idea surface?

24 A. This idea surfaced when we were in the final stages of review

25 of the first report.

On the basis that claim 1 was anticipated, Lenovo argued that claims 2 and 4 were obvious. In view of my rejection of the anticipation case, it is not necessary to analyse the arguments in detail. However, in order to get to claim 2 on this hypothesis, it was necessary for Lenovo to argue that it was obvious to change the rules in the PMS relating to the sending of periodic SI, such that the timer was also re-set after sending ‘non-triggered SI’ (also referred to as ‘opportunistic SI’). Dr Irvine suggested it was, but Mr Townend said there were technical reasons why the Skilled Person would be deterred from changing the operation of the periodic timers in this way, not least because of the safeguard that triggered SI can be re-transmitted if delivery of the SI to the serving Node B fails. By contrast, ‘non-triggered SI’ is simply a bonus for which no similar safeguard is required. Furthermore, if the periodic timers were re-set for both types of SI, a situation could arise where there was an extended period where the serving Node B was not receiving any SI at all, because each time the timer was re-set the UE would send another ‘non-triggered SI’ that may or may not be received correctly. Dr Irvine responded with yet a further change, namely, that the Skilled Person would apply the safeguard to both triggered and non-triggered SI. This ‘double modification’ featured in a Huawei Tdoc, but the minutes from the relevant meeting showed the proposal ‘died a death’. Dr Irvine agreed and also accepted that this was entirely consistent with Mr Townend’s evidence that it was not a good idea.

For these brief reasons, if claim 1 had been anticipated by the PMS, I would not have found claims 2 and 4 obvious.

In my recitation of Case 1 which follows, there are two aspects to which I return later. The first is the way in which the time or period in which certain key work would have been carried out tended to vary. The second is the way in which the evidence relating to simulations continued to develop through expert reports and indeed through cross-examination.

In their Amended Statement of Case on Validity, Lenovo identified the parts of the PMS on which they relied. These were extracts from 9.1.5 MAC PDU (E-DCH), 9.2.4.2, MAC-e header parameters, 9.2.5.3.2 Scheduling Information and 11.8.1.4 E-TFC Selection. It may be noted that the salient parts of each of these sections is covered in the CGK Annex.

By the time of closing arguments, Lenovo was contending that its case comprised two steps:

Lenovo submitted this case required a straight application of Pozzoli, but they stressed two additional points. First, Lenovo referred to the extract from TQ Delta v Zyxel which I quoted above, submitting that principle only applied in rare and unusual cases. Second, Lenovo placed particular emphasis on the decision of the UK Supreme Court in the Tadalafil case – Actavis v ICOS [2019] UKSC 15. Whilst that case is frequently referred to as containing the latest set of principles relating to obviousness (see in the speech of Lord Hodge [58]-[73], as mentioned above), Lenovo rely on it in addition for the proposition that uninventive steps which the skilled team would take after the priority date in carrying out routine work to implement the prior art are not excluded from consideration in assessing the obviousness of the alleged invention at the priority date (see [59]). This proposition was the answer to Lilly’s case which (as Lord Hodge observed at [52]) would require the court to disregard the work which a skilled person would carry out after the priority date to implement the teaching of the prior art – in that case the Daugan patent.

I also detected hints in Lenovo’s case that they were seeking to draw or at least interest the Court in a factual analogy with Tadalafil but any such invitation must be declined since it is trite that each case depends on its own facts.

In Tadalafil the Daugan patent was published on 6 February 1997 and the patent in issue claimed priority from 30 April 1999. Thus, apart from Lilly’s argument, there was no temporal element which stood in the way of the work involved in the obviousness argument, although it is clear it would have taken possibly months to carry out. Precisely because it was routine work which led to the identification of a dosage regime of 5mg daily dose of tadalafil, the case, it seems to me, embraces several legal fictions. I say ‘several’ because the Court is required to consider the notional skilled team, possessed of the common general knowledge at the priority date of the patent, being presented with and reading the prior art with interest at that date. The key legal fiction for present purposes is that the skilled person is effectively assumed to carry out all the routine work on or as of the priority date so as to render the result that the patent was obvious at that date.

In Tadalafil there was no evidence or suggestion that anyone had actually carried out the ‘routine work’ around the Priority Date (or even afterwards). The present case is very different in that simulations must have been carried out by all those manufacturers who were building equipment for HSUPA networks and all those operators seeking to incorporate HSUPA capability into their networks. The key issue is whether those simulations would have given rise to the identification of the so-called transmission blocking problem and the solution to it in the Patent.

Lenovo, largely but not exclusively through Dr Irvine’s evidence, developed two ways in which this obviousness argument was put. Each argument reached a stage where it was said, the problem was staring the Skilled Person in the face. These submissions emphasise the especial importance of two issues which often feature in obviousness cases: first, the relevance of the question: ‘if it was obvious, why was it not done before?’; and second, the influence of hindsight.

On the second point, I have to consider whether the arguments that the problem was ‘staring the Skilled Person in the face’ stem from hindsight. On the first point, the question requires some modification in the particular circumstances of this case. I need to consider not just the period before the Priority Date but also some months after.

However, before I address the two ways in which Lenovo put their obviousness arguments over the PMS on case 1, I must relate how the evidence on these arguments developed, on which IDC placed some weight.

Dr Irvine’s evidence as to what the Skilled Person would do with the PMS, reading it at the Priority Date, comprised a number of stages which I summarise as follows.

First, I note that Dr Irvine was provided with the prior art of the PMS and Kim and the relevant date of 27 August 2006 before he saw the Patent. It appears from his first report that he initially discussed the PMS generally. Although he provided an overview of the content of the PMS, Dr Irvine was asked to explain what the Skilled Person was taught about scheduling in the document. He said the Skilled Person already knew quite a lot about scheduling and referred to his CGK section. As he related, the PMS does not specify how scheduling is undertaken but it does specify information which has to be provided to the Node B which will allow scheduling to take place, the information being the SI and the happy bit.

In closing, IDC submitted that not only had Dr Irvine been instructed to focus on the issue of scheduling when he read the PMS, he had even been instructed to consider the transmission blocking problem itself. IDC relied on this passage of cross-examination (with IDC’s emphasis):

2 Q. Did the first discussion involved discussion of HSUPA or not

3 HSUPA. I thought you said a moment ago it was?

4 A. I would have to go and check my notes. It certainly started

5 as a general discussion of scheduling. Whether it become

6 specific on scheduling in HSUPA I would have to check my

7 notes.

8 Q. I am not asking you to check your notes, but it is obviously a

9 possibility because you would not have mentioned it otherwise.

10 A. Yes.

11 Q. That was the first meeting and then you were given the TS

12 25.321. Was that the point when the solicitors asked you to

13 explain what the skilled person was taught about scheduling

14 from TS 25.321?

15 A. Yes.

16 Q. That must have directed you to focus on the scheduling

17 sections of TS 25.321 in particular.

18 A. That is correct, yes.

19 Q. I imagine you read them quite carefully.

20 A. Yes.

21 Q. How long did this phase take?

22 A. As I say, I think it was about two weeks between when I was

23 given 25.321 and when I was given the patent.

24 Q. Over those two weeks you were thinking about the scheduling

25 aspects of TS 25.321?

2 A. Yes.

3 Q. Were you ever instructed to consider what happened to HSUPA

4 when a UE had a smaller grant than that required to transmit a

5 MAC-d flow?

6 A. Not in quite those terms, but yes.

7 Q. Was that before you saw the patent?

8 A. Yes, that was before.

As a result, IDC submitted that Dr Irvine’s evidence was unavoidably tainted on the issues of both novelty and obviousness by - literally - asking him to have in mind the problem identified by the Patent (which was not CGK) when considering the prior art. I return to consider this point later, in conjunction with the passage from his cross-examination I quoted at paragraph 117 above. For the moment I continue with a description of how the evidence developed.

In the section of his report on the PMS, Dr Irvine explained his views (drawing particular attention to the periodic timers T_SIG and T_SING), as well as more general points about SI and the purpose of triggering SI i.e. to inform the Node B about things it will not or may not know. The Skilled Person would have considered SI as useful to allow the Node B to make scheduling decisions and sent by the UE to alert the Node B that resources were required. At the end of that section, he referred to three pre-priority documents, two of which were supplied to him by the solicitors and a Qualcomm document which he thought he had found.

Dr Irvine then considered potential developments of the PMS. He considered the Skilled Person would have been interested in improvements suggested by experience of implementing the new features of Release 6 through simulations and initial deployments. Given that by this time Release 6 had been frozen, he said (his paragraph 7.28) that testing and simulations would have been conducted as a matter of course, one objective of which would have been to identify good values of T_SIG and T_SING. He said this would involve running simulations of an HSUPA system to assess parameters such as throughput and latency in order to trade off the signalling load against scheduling responsiveness. He added that such optimisation may not have been undertaken as part of the standardisation of Release 6, but would be done as the networks started to be deployed which occurred in the first half of 2007.

In a later section, he identified the point that gave rise to the anticipation argument (his paragraph 9.8). I have already quoted the passage from his cross-examination (at paragraph 117 above) which elicited that this point was identified in discussions when his first report was in the course of being finalised. He continued with a few paragraphs which set out the essence of the obviousness arguments over the PMS, on which various points arise. It is convenient to quote this section in full here (note that Dr Irvine used the expression ‘stall scenario’ to refer to the transmission blocking problem):

IDC submitted that the evidence in Dr Irvine’s first report about simulations was at a relatively high general level. I agree. It appears that Lenovo thought something similar. In his first report, Mr Townend addressed the disclosure of the PMS in general terms and identified eight areas of possible interest to the Skilled Person, including sections 9.1.5, 9.2.4, 9.2.5 and 11.8 (cf. Lenovo’s pleading). He rejected the notion that the key feature of claim 1 was disclosed in the PMS and then considered whether it would have been obvious to adapt the PMS to include that key feature. He indicated the Skilled Person would have to undertake a two-stage process: first, to recognise the transmission blocking problem and second, to decide to implement a new trigger of sending SI in response to the condition mentioned as a means of resolving the problem in place of some alternative method. He said the PMS does not assist on the first stage. At that stage the simulations argument(s) had not been explained, so Mr Townend did not consider simulations in his first report. It follows that in his second report, Dr Irvine had nothing regarding simulations to respond to. Nonetheless, he expanded on the topic – there is more on simulations in his second report than his first.

Dr Irvine repeated his point that the Skilled Person would have started work on implementations of Release 6 once it was complete and, as part of this work, they would have carried out simulations of the type he had described in 7.27 and 7.28 of his first report. He went on to say that wider simulations would be performed, focussed either on the performance of specific parts of the HSUPA system or on the more general performance of the system as a whole from the user’s point of view. He relied on and exhibited extracts from Chapters 8 and 9 of Holma & Toskala (published 4 months before the priority date) as including examples of both types of simulation.

He then responded to Mr Townend’s evidence (that the Skilled Person would not have identified the problem) by stating, in his view, the Skilled Person would have done so through at least two types of routine simulations which he said would have been conducted before the priority date.

The first type was the mapping analysis, which I address below. I note that in reaching his conclusion that the Skilled Person’s work would reveal the potential for the ‘stall scenario’ to occur, Dr Irvine relied on Mr Townend having noted in his first report that the Skilled Person would appreciate the concept of the stall situation. However, Mr Townend had made that point in the context of the Patent and it in no way supported Dr Irvine’s conclusion.

As to the second type, Dr Irvine expanded on his simulations to find effective values of T_SIG and T_SING and stressed the importance of latency in internet services based on TCP. He then said it was not a surprise that reports of these types of simulation were not publicly available. He explained that these simulations would have been undertaken by equipment vendors and network operators to gain a competitive advantage and the results would have been sensitive proprietary information. Finally, he stressed the importance of web browsing for HSDPA and HSUPA, which would have manifested itself in simulations of downloading data over TCP/IP with a high bandwidth connection on the downlink using HSDPA and a low bandwidth uplink using HSUPA. He was of the view that the TCP acknowledgements (of 320 bits) sent on the low bandwidth uplink would identify any issues of latency.

In his second report, Mr Townend addressed the evidence on simulations given in Dr Irvine’s first report. He disagreed that a ‘stall’ would necessarily be identified by simulations, giving the following reasons:

Dr Irvine’s third report was limited to a response on claims 2 and 4 (since these had not been dealt with in the first round of reports). So the stage was set for Mr Townend’s points to be challenged in the course of cross-examination. However, general assertions aside, it was not apparent that the cross-examiner had been armed with or had specific responses to the points made by Mr Townend in his written evidence, aside from the specific point put in cross-examination about investigating the effects of setting T_SIG to ‘no report’. This point was not covered in Dr Irvine’s written reports – the closest which Dr Irvine got to T_SIG = ‘no report’ was when he was discussing claim 4 in paragraph 7.14 of his second report. Even there, he referred simply to the default value. It was Mr Townend (in reply, in Townend 6) who mentioned that the default value of T_SIG was ‘no report’.

The first way in which Lenovo developed their obviousness argument – which I will call the ‘mapping’ argument – starts with Table 9.2.5.2.1.1 in the PMS – the Scheduling Grant Table or SG Table. This table sets out 38 different power levels which the Serving Grant may take. The next step involves the conversion of the Serving Grant power level into a number of bits of scheduled data, a necessary step so that the UE can perform E-TFC Selection and construct a MAC-e PDU. Although Mr Townend said that the PMS does not specify how the conversion should be done, Dr Irvine pointed out that the PMS contains a cross-reference to TS 25.214, section 5.1.2.5B.2.3 which gives the Skilled Person the necessary information to perform the conversion.

So, mapping the Serving Grant values to the number of bits being transmitted is simply the implementation of the conversion process and has to take place in order to carry out any simulation of the HSUPA transmission chain. Indeed, Lenovo pointed out that the Skilled Person would perform the calculations on paper in advance of actually constructing any simulation model.

Lenovo’s submission was that it would be immediately apparent from the result of that conversion process that the Serving Grant could be non-zero but too small to send one MAC-d PDU. Lenovo pointed out that one of the main applications for HSUPA was envisaged to be the transmission of packet switched data which would entail frequent TCP acknowledgements. Common RLC PDU sizes were 336 bits and 656 bits, based on 320 or 640 bit RLC SDUs with a 16 bit RLC header in Acknowledged Mode (although Mr Townend made this point when discussing the Patent, I accept that it was part of the CGK).

When cross-examining Mr Townend, Counsel took him to a post-priority Tdoc from ZTE in which it appears ZTE spotted there was a problem but proposed a different solution. In the Tdoc, ZTE presented results from a ‘simulation’. It does not matter whether the results were from calculations or an actual simulation, but I tend to agree with IDC that it looks like ZTE had just carried out some calculations. In support of this argument, Lenovo relied on two passages from Mr Townend’s cross-examination:

I interpolate here that, aside from the cross-examination on the ZTE document, Lenovo also submitted that it follows from the fact that transmission blocking is a real possibility that the Skilled Person would come out with numbers in which some grants were too small for many common applications.

The second passage came in a slightly later answer where Mr Townend said this:

Lenovo’s response was to agree, but to add a further consideration and this was identified by Lenovo as the key step in the obviousness analysis. It was said that the Skilled Person knows from their CGK that there are two reasons why a UE might end up below that floor, however good the Serving Node B scheduling algorithm is:

Consequently, so Lenovo submitted, the possibility of transmission blocking, for either of those two reasons, ‘is staring the skilled person in the face’. The Skilled Person would be consciously considering the need to keep the UE above the floor in the SG Table to avoid getting into this ‘mess’. Hence, the Skilled Person could not fail to appreciate that that is not within their control: this ‘mess’ cannot be prevented.

However, if one reads the passage quoted at paragraph 148 above in context, Mr Townend’s evidence does not support Lenovo’s submission that the Skilled Person would be consciously considering the need to keep the UE above the floor. Immediately following that passage came this exchange (in which it will be noted that the ‘question’ is long and comprised of several parts):

14 Q. We agree, you and I agree that the skilled person would think

15 the way you just said. The skilled person would say to

16 themselves, "I must make sure that the Serving Node B does not

17 send a grant below that floor." But in terms of the causes,

18 two of those causes are part of the skilled person's common

19 general knowledge. They know that neighbouring cells can send

20 DOWN commands and they know that Relative Grants and indeed

21 Absolute Grants can be misinterpreted. So they know it is not

22 going to be good enough that their Node B scheduler, that the

23 Serving Node B does not set a grant below the floor. They

24 know there is a risk that things will happen so that the UE

25 goes below the floor, in any event?

2 A. Putting all of those pieces together is clearly what the

3 inventor did. I have not seen anything, as I have been

4 looking at this, that would suggest that the skilled addressee

5 would put all of those pieces together to come to that

6 conclusion. As an example, when you read the MAC

7 specification, and I am not suggesting for a moment that the

8 skilled addressee would not be aware or would not know you

9 could only put whole PDUs in a MAC-e PDU. Obviously, they

10 would know that, but the way that 25.321 is written, I do not

11 think it actually really makes reference to that. Possibly in

12 one line in the pseudo code, but in certainly all of the

13 normative text, it just talks about bringing in data according

14 to the grant or whatever. So the skilled addressee reading

15 the specifications is not really well set up to put together

16 all of the different pieces that we are talking about, even

17 though each of those pieces is within their mental toolbox.

18 That was why I had come to the conclusion that I had that it

19 was not apparent to me that the skilled addressee would put

20 all of those pieces together to identify the problem.

Counsel tried again:

7 Q. Let us imagine the skilled person has got to the point which

8 you have described, which is they have appreciated that there

9 is a floor within the SG table and the scheduler must not send

10 the UE below that floor.

11 A. Yes.

12 Q. Okay. To get from there to identifying the

13 transmission-blocking problem, the only step for the skilled

14 person to remember is that there are two reasons why the UE

15 might go down that table, below that floor, despite the best

16 efforts of the Serving Node B scheduler.

17 A. Yes. If the skilled person had got to that point, then, yes,

18 it would be one additional step to identify that.

Of course, I am not bound to accept Mr Townend’s evidence. I have to place myself in the shoes of the Skilled Person and effectively ask whether he or she would have put all these pieces together. Before taking that step, it is relevant to consider the question: if this was obvious, why was it not spotted by several other participants in the standard setting/implementation process?

On this question, it is relevant that the SG Tables were first published in June 2005, although Dr Irvine said the tables on their own probably would not give the skilled person enough information and they would wait for the specification to be finalised, as it was in September 2005. Although the PMS itself was not published until June 2006 I was satisfied (as I have said) that the relevant content was the same as was published in September 2005. Thus, on Lenovo’s mapping case, a period of about 11 months elapsed before the Priority Date during which period this problem was supposedly staring real-life teams in the face. If it had been, one would have expected many proposals to have emerged in pre-priority Tdocs identifying the transmission blocking problem and solving it, but there are none.

It is also relevant to note that Dr Irvine did not make the mapping argument in his first report, notwithstanding the point he made in his paragraph 9.8 which I regard as related in the sense that both arguments involve a Serving Grant which is insufficient to send any MAC-d PDU. Even in the circumstances of the discussion during the finalisation of his first report which led to his paragraph 9.8, where they were ‘knocking around some numbers’, the mapping argument did not surface. This consideration reinforces the particular force of hindsight – once you know what the problem is, it can ‘stare you in the face’ from various sources.

The two ways in which Lenovo put their obviousness arguments are related in the sense that the work relevant to the first way was a necessary pre-cursor and would have quickly given way to the extensive work involved in simulating an HSUPA set-up to develop or optimise it. For this reason, I discuss the post-priority Tdocs in the next section.

The second way in which Lenovo put their obviousness case over the PMS was the simulations argument. In essence, the argument was that the transmission blocking problem would come to light during routine simulation of an HSUPA system in development.

In closing, Lenovo relied on two types of simulation: first, simulating the scheduler for the purposes of testing/optimisation and second, simulations to find effective values for the periodic timers T_SIG and T_SING. Mr Townend agreed in cross examination that both types of simulation were necessary and routine.

On the first point, Lenovo developed their argument as follows:

First, the experts agreed that the transmission blocking problem would not be a commonly occurring problem, but it would be a real problem with real effects. The UE is unable to transmit when it has data to transmit. Uplink resources are under-utilised because they are allocated to a UE which cannot use them. The effect would be on throughput, packet delay and resource utilisation. Mr Townend agreed it has a material effect on data throughput and latency.

Second, the fact that 3GPP chose to incorporate additional functionality into Release 7 to address the problem confirms it was considered a real problem with real effects. Dr Irvine considered the Skilled Person might be prepared to live with the problem in the context of frozen Release 6 but considered it was worth exploring in the context of developing Release 7.

Third, against that backdrop, Lenovo pointed out that the Skilled Person implementing HSUPA would have to write a scheduling algorithm and would have to simulate it as a matter of routine. Mr Townend agreed that the Skilled Person would have to devote particular attention to optimising the scheduler.

Fourth, the transmission problem would inevitably manifest as unexpectedly high latency at low Serving Grant values.

Lenovo submitted that Mr Townend did not actually dispute that at some point during routine testing and implementation, the problem would manifest itself as an issue of latency or reduced throughput, relying on this passage of cross-examination:

9 Q. You told us earlier that the transmission-blocking problem was

10 a real problem that would have a real effect. It follows from

11 that, does it not, that at some point during routine testing

12 of the scheduling algorithm optimisation and implementation of

13 the system, this problem would manifest itself as an issue of

14 latency or reduced throughput?

15 A. Again, it really comes down to the simulation assumptions that

16 are being used and, indeed, the capabilities of the simulator

17 that is being used which then comes down to really exactly

18 what it is you are trying to do with it as well.

This answer did not get Lenovo home. I was not persuaded that merely detecting latency in simulations of the scheduling algorithm would have led the Skilled Person to identify that transmission blocking was a or the cause of the problem.

The second simulation is more involved. As Lenovo submitted, the PMS provides for timers but leaves it to the implementer to decide (i) whether to implement them and (ii) what values to use for the period. Then the argument was developed as follows (in which I have omitted most of the evidence references relied upon, but have examined each of them):

In the final part of the argument, Lenovo submitted that ‘Dr Irvine was absolutely clear on this and he has enormous experience in running simulations, and his CV is full of references to system performance assessment and the like’.

On the first point, Lenovo relied on this answer given by Dr Irvine in cross-examination, which was certainly the high point of his evidence on this:

As for Dr Irvine’s experience in running simulations, his answers in cross-examination generated the following general picture. Although he was not being cross-examined on the content of his CV when he gave these answers, I read this section of the transcript with his CV open and picked up the references:

Part of the reason why Dr Irvine’s experience of simulations came out only in cross-examination was because, although he realised the importance of simulations when preparing his second report, he did not update his experience in that regard. The lack of focus on simulations until later in the process also explains why Mr Townend did not focus on his experience of simulations in either his first or second reports. In addition, there was no challenge to Mr Townend in cross-examination as regards him being qualified to speak on simulations, and a review of his experience in industry before the Priority Date indicates it is highly likely he had experience of simulations in that work. Having seen Mr Townend in the witness box, he seemed to me to be able to speak with no less authority than Dr Irvine on simulations. In this regard, I refer not just to his demeanour (which it is difficult to ignore) but more to the content of his answers.

So although Lenovo’s submission which I related above in paragraph 168 above was largely justified (albeit a tad exaggerated), I do not proceed on the basis that Dr Irvine’s evidence on simulations trumped that given by Mr Townend.

Reverting to the substance of Lenovo’s argument, there are four critical points in particular which I must examine:

I address these points under the relevant headings below.

This is a ‘background’ point, so I will deal with it first. Lenovo’s position (and Dr Irvine’s evidence) on the significance of the transmission-blocking problem underwent some change. In his first report, in the context of discussing the Patent, Dr Irvine said this:

This paragraph was consistent with Dr Irvine’s later paragraph 9.11 (quoted above).

In his second report, Dr Irvine addressed three post-priority TDocs from ZTE discussed at the WG2#58 meeting held 7-11 May 2007:

In his ‘Errata’, Dr Irvine clarified that when he wrote that last sentence, he had Release 6 in mind, accepting that he should have made that clear, and added that, for Release 7, the stall condition would have been worth exploring. By May 2007, Release 6 had been frozen for some time and it is understandable that only essential corrections would be permitted. However, Dr Irvine’s clarification does not make a lot of sense, in my view. The Skilled Person would either have considered the problem worth fixing or not. That conclusion would not have depended on whether the solution would be incorporated into Release 6 or Release 7.

As can be seen from the way Lenovo put this obviousness argument in closing, by the time it came to the cross-examination of Mr Townend, their point seemed to me to have firmed up somewhat. Perhaps realising that Dr Irvine’s equivocal evidence made the argument more difficult, the point was put to Mr Townend as being ‘a real problem with real effects’. Mr Townend accepted this, but it still begs the question as to whether the Skilled Person would identify the transmission blocking problem from his or her simulation(s) from amongst the ‘noise’ which the results would throw up.

On that point, Mr Townend agreed that simulations would be used to test different conditions (e.g. in city and in rural environments) and also agreed that minority cases are important to the skilled person (cf the edge cases in paragraph 167(e) above) but added the qualification that ‘they are not that easy to tease out with simulations’.

Mr Townend agreed that when the Skilled Person was considering what value to choose for T_SIG, there were two competing factors: first, the more frequently the UE sends SI, the more up-to-date the information the scheduler will be able to use to make scheduling decisions, and that factor suggested a low value for T_SIG; second, sending SI more frequently requires more signalling overhead which the Skilled Person is always looking to minimise, and that factor would suggest a high value for T_SIG or even not enabling it at all. Mr Townend also agreed that the Skilled Person would have to strike the right balance between those two factors. The next stage of the argument was the suggestion that the Skilled Person would do simulations and trials to see what values of T_SIG work best for their system. At that stage, Mr Townend did not agree that simulation would be required to make a decision on whether to adopt ‘no report’ for T_SIG:

7 Q. Obviously, again, one of the values they would try out would

8 be no report?

9 A. Not necessarily, just because no report is one that you could

10 actually make a decision on, frankly, without simulation,

11 because there is no question as to what the impact of that is

12 going to be, frankly, in terms of either of the two factors

13 that you listed. It clearly minimises the overhead, so it is

14 a clear win there. On the other side, it, obviously, you do

15 not get those periodic updates, so at that point you have some

16 very clear, that, some error condition might persist or your

17 algorithm cannot rely on, for example, long-term averaging of

18 data that it gets from the Scheduling Information. It is with

19 the no, the no reporting, it is a pretty much a matter of,

20 "Are you throwing away some functionality that you need for

21 your algorithm?" Because no amount of simulation is necessary

22 to tell you that.

23 Q. Would the skilled person not wonder whether opportunistic SI

24 would occur frequently enough that they did not need periodic

25 SI on top?

2 A. That would depend, I think, in part on, for example, whether

3 they were looking at doing averaging of measurements.

The cross-examination continued but in my view all that it demonstrated was a similarly circular point that if a simulation was conducted at a sufficiently detailed and specific level so as to be apt to reveal the transmission blocking problem, then it would do so. This begged the question as to whether that type of simulation would be carried out as part of ‘routine work’.

On the third point, Mr Townend was asked to assume a skilled person simulating various values of T_SIG but in particular the default value where T-SIG is set to ‘no report’. He indicated that his earlier answers in cross-examination that morning did not support the assumption. However, the passage of cross-examination of Mr Townend relied upon as supporting this second point did not do so, in my judgment. This was the high point which produced an entirely circular answer:

22 Q. If the skilled person simulated T_SIG equals no report,

23 sometimes UEs in the simulation would suffer persistent

24 transmission-blocking?

25 A. That would depend on the simulation.

2 Q. If the simulation reflected the real world enough so that

3 transmission-blocking occurred.

4 A. Yes. If the simulation was sufficiently realistic that

5 transmission-blocking could occur, then if you were to do it

6 in this situation, then you would expect that

7 transmission-blocking would occur somewhere in your simulation

8 runs, yes.

9 Q. When it did occur, it would just be persistent?

10 A. Yes, because there was no -- yes.

I have set out above the passages from Dr Irvine’s evidence where he indicated that the Skilled Person might not consider the transmission-blocking problem as one worth fixing. Those pieces of evidence provide one possible answer as to why other participants in the standard-setting process did not draw attention to the problem or propose the solution in the Patent.

Lenovo evidently considered that there might be problems with Dr Irvine’s evidence in that regard. This manifested itself in two ways: first, Lenovo’s firming up as to the perceived significance of the problem; and second, in the explanation provided in Dr Irvine’s second report to the effect that the those who conducted simulations would have kept the results secret.

Dr Irvine said it was no surprise that reports of simulations to find effective values of T_SIG and T_SING were (and are) not publicly available. He said that equipment vendors and network operators would have undertaken these simulations to try to gain competitive advantage with their Release 6 implementations, although he accepted that relevant results would also feed into Release 7 standardisation efforts. Thus, he said, although it would have been routine for these simulations to be conducted, the results would have been sensitive proprietary information which would not have been shared with others in the market.

Whilst I entirely accept that the details of simulations would have been kept confidential including resulting values of T_SIG and T_SING, this reasoning does not explain why companies would not have identified improvements arising out of the simulations which could have been (a) patented and (b) presented for inclusion into the standard. In my judgment, if a company had identified the transmission blocking problem in the course of their simulations and identified the solution, it is highly likely, in the competitive field of UMTS development that they would have done both those things, not least to avoid another company patenting the solution they had identified. Furthermore, if the problem had been spotted and the solution in the Patent identified, those responsible would have realised that their additional trigger for SI required a change to the Standard. That, in my view, would have resulted in a proposal being put to RAN WG2 at one of its meetings. In other words, the RAN WG2 records provide, in my view, a reliable record as to whether anyone did identify the problem and identify the solution in the Patent at least up until around the time at which it was clear the Patentee’s solution was being adopted into the Standard (see paragraph 194 below).

I must also keep in mind the period of time over which it was said these simulations would have been run. The following timeline is relevant:

This timeline reinforces the evidence that numerous substantial entities in the field (both manufacturers of network equipment and operators implementing new HSUPA networks) would have been carrying out a wide variety of simulations over this period to develop and optimise their HSUPA offerings. No pre-priority Tdocs hinting at the transmission-blocking problem were identified. Therefore, it is necessary to examine various post-priority Tdocs which were referred to in order to see what picture is presented.

The secondary evidence, such as it was, was primarily directed to the case over the PMS and so I will consider it at this point. In his second report, Dr Irvine indicated that after he had formed his opinions and substantive drafting of the earlier sections was complete, Lenovo’s solicitors presented him with 8 post-priority documents from 3GPP RAN 2. Four of these were considered at WG2#58 (7-11 May 2007), two from WG2#58bis (25-29 June 2007) and two from WG2#59 (20-24 August 2007). Six related to a proposal from ZTE and two from Qualcomm.

In summary, these Tdocs show that:

Dr Irvine’s written evidence was that these Tdocs were consistent with his views that (1) the blocking problem would have been identified, (2) would not have been considered worth fixing and (3) the introduction of a new trigger for SI would have been an obvious solution. However, a different picture emerged in cross-examination in which Dr Irvine agreed that:

As IDC submitted, the Patents Court has commented on the limited assistance that can be gleaned from this type of ‘Tdoc’ analysis on numerous occasions. See for example the judgment in Trial A Interdigital Technology Corporation & Anor v Lenovo Group Ld Ltd & Ors [2021] EWHC 2152 (Pat) at [120]-[121]), and Arnold J in Koninklijke Philips NV v Asustek Computer Inc [2018] EWHC 1224 (Pat) at [201]. Leaving aside the point that attendees at 3GPP meetings may not be representative of the relevant Skilled Person in a particular case, the fact that a claimed invention might be published by competitors of the patentee shortly after the priority date may or may not be significant depending on whether it is likely that the competitors had become aware of the work done by the patentee.

The solution in the Patent was incorporated into the standard in version 7.6.0, released on 24 October 2007. I can see that once it was incorporated, there would have been little point in any other participant mentioning either the transmission-blocking problem or the solution in the Patent in any Tdoc or WG2 meeting. I also consider it likely that participants would have been aware that that was coming in advance. However, this leaves an extended period in which the only relevant independent suggestion was that from ZTE in May 2007 which did not derive from simulations.

As at the date of WG2 #58bis (late June 2007), the solution in the Patent had not yet been adopted into the standard. In addition to the discussion of the ‘alternative solution’ at WG2 #58bis, it is likely that this solution had been the subject of prior discussion at a meeting shortly after the priority date. At WG2 #58bis it was in the inventor’s/IDC’s interests to promote their solution. Accordingly, it is more likely than not that it was the inventor who drew attention to this ‘alternative solution’ at that meeting and I so find. It is to be noted that the subsequent Qualcomm proposal was based simply on the discussion at the previous meeting – there is no indication whatsoever that any simulation work contributed to it.

IDC’s fall-back submission was that this whole ‘Tdoc analysis’ exercise was doomed to fail in any event, because, as Dr Irvine explained, the documents were produced by Lenovo’s solicitors, and he had no knowledge as to the search methods used and had taken no steps to ensure they were an objective selection of documents as opposed to ones that simply helped Lenovo. It is not necessary for me to determine this point.

After the evidence had been heard, Lenovo submitted that secondary evidence was not of assistance either way in this case but submitted that their case was entirely consistent with such secondary evidence as exists.

IDC took a measured view as to the value which could be extracted from these Tdocs, submitting that they were either entirely neutral to the issue of obviousness, or if anything they support the case of inventiveness. In my view, to the extent that weight should be given to this secondary evidence, it is slightly double-edged. The evidence suggests that ZTE spotted the problem without simulations (albeit some months after the Priority Date), but their proposed solution missed the invention. If ZTE had spotted the problem without simulations, two questions arise: first, why ZTE appear to have only spotted the problem several months after the Priority Date, when the relevant material in the PMS had been around for a considerable time – the SG Table in particular had been published in June 2005 but the specification was essentially complete in September 2005; second, why are there no indications of any others spotting the problem and proposing the solution claimed in the Patent. Overall, in my view, this evidence tends to damage Lenovo’s and Dr Irvine’s theories of obviousness over the PMS.

It is now time to draw the threads together from the various topics I have discussed above.

There is no doubt that a proposed implementation of HSUPA would require a manufacturer or operator of network equipment to run simulations to optimise a significant number of variables. Various algorithms would have to be designed – in particular, a scheduling algorithm – which, once coded into software, would have to be optimised before live deployment. This would all be routine work of the skilled person. However, there was no official set of simulations and different simulations would give different results.

Although Dr Irvine presented a powerful analysis and the issue overall was finely balanced, ultimately I was not persuaded that routine work would have identified the transmission blocking problem to the Skilled Person leading him or her to the solution embodied in claim 1 of the Patent.

In reaching this conclusion, I paid particular attention to all the evidence references relied upon by Lenovo. I also re-read the whole relevant sections in the cross-examinations of Mr Townend and Dr Irvine. It is clear, as I have endeavoured to explain above, that Lenovo did not secure any clear acceptance from Mr Townend of either part of their obviousness analysis. If you know the end point you are trying to reach, it is easy to direct the questioning with a laser-like focus to lead to that end point. Mr Townend’s answers were a reminder that the uninventive Skilled Person proceeding without hindsight would not have such a focus.

Taking a step back from the detail, I observe that this transmission-blocking problem is one of those points that one cannot forget once it has been pointed out. And once alive to the point, one can then identify various scenarios where the problem is ‘staring you in the face’, the striking expression used by Dr Irvine in relation to both limbs of the obviousness arguments in Case 1.

In this regard, I regard it as of some significance that the problem was suggested to Dr Irvine. From that I infer that either he did not identify the problem simply by considering the values in the SG Table or through considering generally what sort of simulations would have to be carried out to implement an HSUPA system or (and this is possibly more likely) that Lenovo’s solicitors were not confident that he would do so. I have been careful not to overstate the significance of this point because I recognise that, even with the progressive unveiling Medimmune approach, it could be very difficult (if not virtually impossible) to simulate what real-life teams would have done at the Priority Date to find out whether in fact the transmission blocking problem would have been identified.

However, since Dr Irvine was effectively led to the problem, the consequence ought to have been that those instructing him should have taken extra special steps to try to compensate for the hindsight that had thereby been injected into Lenovo’s case. I realise this would have been difficult to achieve and counterintuitive for the team, but it is part of Lenovo’s burden to prove their case.

Of all the factors I have discussed above, the ones which I consider have significant weight (in addition to the influence of hindsight on both arguments) are as follows:

For these combinations of reasons, I reject Lenovo’s Case 1.

Kim is a US Patent Application filed by Samsung on 30 December 2005 entitled ‘Method and Apparatus for Signalling Control Information of Uplink Packet Data Service in Mobile Telecommunications System’. Priority is claimed from a Korean document dated 30 December 2004 (which I have not seen). Kim was published on 6^th July 2006, some 6 weeks before the priority date of the Patent. The parties were agreed on the following points: first, that whether the document is read at the date of its publication or the priority date of the Patent makes no difference. Therefore, for convenience, I will simply refer to reading Kim at the priority date; second, that Kim provides a proposal for HSUPA; and third, between the date when Kim was written and its publication, the development of HSUPA had moved on.

The experts and the parties agreed on the central idea of Kim. It is that where a UE is sending a MAC-e PDU whose payload comprises only SI, the header of the MAC-e PDU is omitted. This can occur because the size of the E-TFCI implicitly indicates that only SI is being sent. Of course, the advantage of omitting the header is that the size of the E-TFC is reduced, saving radio resources and improving efficiency on the enhanced uplink.

[0024] describes Kim’s invention as follows:

The experts were agreed that the Skilled Person would recognise that this invention had been incorporated into TS 25.321 by the priority date.

After setting out much of the familiar technical context of UMTS, Kim describes the operation of the “enhanced uplink” (i.e. HSUPA) from [0058] onwards. The skilled person would appreciate that what Kim refers to as “MAC-e control information” being inserted into a MAC-e PDU at [0058] is SI. At [0060] Kim also refers to an “initial rate request packet”, which is an SI that is sent on its own (i.e. without any data) when the uplink connection is set up.

I set out [0058] here because it featured in the arguments over the meaning to be given to Fig.9:

“[0058] If the Node B 437 grants uplink transmission resources to the UE 402 at a specific point of time, the UE 402 brings as much data as can be transmitted through the transmission resources from the RLC entities 405, 407 and configures and transmits a MAC-e PDU. In the multiplexing and TSN setting block 430, a MAC-e header is inserted into RLC PDUs transferred from the RLC entities 405,407 to get a MAC-e PDU. At this time, if a sufficient space remains in an E_DCH transmitter block or MAC-e control information to be transmitted exists, the MAC-e control information is also inserted into the MAC-e PDU and is transmitted together.”

The general structure of a MAC-e PDU containing RLC data is then described at [0062] to [0068], with the special DDI value being discussed in [0069]-[0071], all illustrated in Figure 6. It is not necessary to set this out because Fig.6 would be familiar to the Skilled Person from the standard (see section 9.1.5, along with the special DDI value of [111111] in section 9.2.4.2). Kim continues:

Table 2 sets out an example set of the MAC-e PDU sizes corresponding to E-TF values from 0 to 3 and then from 125-127.

[0073] and [0074] explain certain points which are in any event obvious from Table 2: that E-TF 0 is the smallest E-TF and corresponds to a minimum size of MAC-e PDU, having a size of 36 bits, whereas the second largest E-TF value of 126 has a size of 18,879 bits.

[0075] explains what the MAC-e payload may comprise. If no RLC PDU is to be transmitted, but only MAC-e control information, then the MAC-e PDU has the minimum size because the MAC-e control information is significantly smaller than that of the RLC PDUs.

Kim notes at [0076] that when SI is sent alone (i.e. it is the MAC-e control SDU) it will be no more than approximately 30 bits. The skilled person would recognise that by the priority date the size had in fact been fixed at 18 bits. Kim suggests at [0078] that because the size of SI alone is considerably smaller than a MAC-e PDU containing RLC PDUs, which was typically 168 or 336 bits, an SI-only PDU could be indicated by the use of a “special” E-TFCI of 0, i.e. the smallest E-TFCI.

The possible structure of such a MAC-e PDU containing only SI is shown in Figures 7A and 7B. The latter of those figures, described at [0083], shows the header-less SI embodiment of the invention.

Kim then discloses the two embodiments on which Lenovo’s anticipation and obviousness case has focused. These are the embodiments illustrated in Figures 8 and 9. I consider it is necessary to have regard to both embodiments.

[0084] identifies Fig.8 as a flowchart illustrating an operation of a UE in accordance with an exemplary embodiment of the present invention:

This is explained further in [0085]-[0090]. In summary, at step 805, one of two events is recognised by the UE:

The remaining steps are straightforward. The MAC-e PDU is configured by the UE with the MAC-e control SDU. The DDI header is then removed in step 815 and the headerless MAC-e PDU is transmitted. The final part of [0090] explains:

“in order to represent the MAC-e PDU from which the header has been removed, a special E-TF value is transmitted over the E-PDCCH.”

The specification moves straight onto Fig.9. [0091] explains:

“FIG. 9 is a flow chart illustrating an operation of a UE in accordance with an exemplary embodiment of the present invention. Similarly to the operation in FIG.8, the operation in FIG.9 also aims at transmitting a MAC-e PDU as configured as shown in FIG.7B.”

The description of the flow through the left-hand side of Figure 9 is at [0092] to [0094]:

“[0092] Referring to FIG. 9, in step 905, a UE selects an E-TF for the E-DCH at the present point of time, and configures a MAC-e PDU to be transmitted according to the E-TF. Considering transmission resources granted from the Node B, the UE determines the size of a MAC-e PDU to be transmitted in the next transmission, and selects an E-TF representing the determined size. The MAC-e PDU is then configured according to the selected E-TF. Accordingly, the UE receives data, suitable to the size denoted by the E-TF, from the E-DCH control block or an RLC buffer, configures a MAC-es PDU or a MAC-e control SDU with the received data, and then configures a MAC-e header for the MAC-es PDU and/or the MAC-e control SDU and attaches the MAC-e header to the MAC-es PDU and/or the MAC-e control SDU.

[0093] In step 910, the UE determines whether the selected E-TF has a predetermined special E-TF value. The UE goes to step 915 if the selected E-TF has the special E-TF value, and goes to step 925 if the selected E-TF does not have the special E-TF value. If the selected E-TF has the special E-TF value, the MAC-e PDU includes only a MAC-e control SDU. In contrast, if the selected E-TF does not have the special E-TF value, the MAC-e PDU includes MAC-es PDUs and a MAC-e control SDU together, or only MAC-es PDUs.

[0094] In step 915, the UE removes the header from the configured MAC-e PDU. As a result, only the MAC-e SDU remains in the MAC-e PDU as shown n FIG. 7B. In step 920, the UE transmits the MAC-e PDU from which the header has been removed. In this context, a MAC-e PDU including a header and a MAC-e control SDU is configured, and then the header is removed to generate a MAC-e PDU to be transmitted. However, when the E-TF has the special E-TF value, the UE may configure a MAC-e PDU that includes no header and consists of only a MAC-e control SDU, and then transmit the MAC-e PDU directly according to UE manufacturers' designs. Also, in order to represent the MAC-e PDU from which the header has been removed, the special E-TF value is transmitted over the E-DPCCH.”

The central issue on Kim is how the Skilled Person would read these paragraphs. In order to carry out that assessment, it is first necessary to note the following differences between Kim and the CGK of HSUPA at the Priority Date which were identified in the cross-examination of Mr Townend and acknowledged by him. Lenovo put forward this list:

Dr Irvine suggested that the Skilled Person would take the description of the various steps in the Fig 9 embodiment literally, whereas Mr Townend was of the view that the Skilled Person would read these paragraphs with his or her knowledge of HSUPA in mind and interpret them accordingly.

So Dr Irvine explained the scheme as follows:

For his part, Mr Townend did not agree with Dr Irvine’s summary of the Fig 9 embodiment. Mr Townend considered that it appeared to rely on an assumption that the UE’s selection of the special E-TFCI of Kim occurs when the UE does not have the resources needed to send any MAC-es PDUs but Mr Townend was of the view that this is not stated in Kim and is inconsistent with the Skilled Person’s CGK.

On Dr Irvine’s first step, the disagreement focussed on the first two sentences of [0092]. Dr Irvine focusses on the first sentence of [0092] – the selection of an E-TF. Yet that first sentence is merely a summary of step 905. The remainder of [0092] describes the process in greater detail. Thus, as Mr Townend pointed out, the selection of the E-TF is not the first thing that happens. Instead, as explained in the second sentence onwards, first the UE determines the size of a MAC-e PDU to be transmitted in the next transmission ‘considering transmission resources granted from the Node B’. Then an E-TF is selected representing the determined size [of MAC-e PDU]. Mr Townend said the Skilled Person would recognise this two-step process for E-TFC Selection as consistent with their CGK and the PMS.

As to the second stage of Dr Irvine’s approach, Mr Townend observed that the idea that selection of the special E-TFCI ‘would occur when the UE does not have the resources needed to send any MAC-es PDUs’ did not appear to have any basis in Kim or in the CGK. Indeed, Mr Townend pointed out that if the correct E-TFC Selection process was followed, the result would be as follows:

Mr Townend acknowledged that the exception to this would be where SI has been triggered in accordance with section 11.8.1.6 of the PMS i.e. where SI has been triggered, it will always be sent. Thus, Mr Townend was of the view that the Skilled Reader of Kim’s second embodiment describes sending SI in two different configurations:

This process would have reflected the PMS and would have been consistent with the Skilled Reader’s CGK. Accordingly, Mr Townend was of the view that in Kim’s second embodiment, there was no disclosure of SI being sent in response to having a non-zero grant smaller than needed to transmit a MAC-e PDU.

In cross-examination, Mr Townend acknowledged there are certain aspects of Kim which are inconsistent with HSUPA as it was specified at the priority date – I have set out the list above. However, he pointed to [0058] as supporting his reading of [0092] and suggested that the Skilled Reader would naturally use his or her CGK (of HSUPA) to fill in the gaps in Kim’s teaching. When focussing on the process of E-TFC Selection, Mr Townend pointed out that the alternative reading (where the largest E-TFC that is supportable by the grant is selected) leads to an absurd result. He illustrated this by assuming an RLC PDU of 336 bits and a grant of 153 bits. On the alternative reading, E-TF 2 would be selected (of size 153 bits), SI would be inserted and the remainder would be filled by padding. As he put it, sending these ‘padding-filled MAC-e PDUs’ would not make any sense.

In Dr Irvine’s cross-examination, it became clear that he had been asked to consider Kim on a particular basis (emphasis added):

12 Q. It is implicit, therefore, to someone reading Kim that if it

13 want to know about, for example, the E-DCH channel it mentions

14 in paragraph 0006 or the HARQ protocol they refer to in

15 paragraph 0007, they will need to refer to the 3GPP standards

16 to find out what these are?

17 A. If they want to find out what the 3GPP versions are, yes.

18 Q. Should they be looking for some other versions as well?

19 A. I was not reading Kim to only relate to how HSUPA was

20 specifically implemented at the time.

21 Q. What other systems were you reading that you are referring to?

22 A. I was reading it more generally as looking for an inventive

23 step within it.

24 Q. Were you looking for an inventive step within Kim?

25 A. Well, what is it telling me to do?

2 Q. Yes.

3 A. I was given Kim and I was asked, "What does Kim tell you about

4 scheduling?"

And a little later, to the same effect:

20 Dr. Irvine, coming back to what you actually said, we are on

21 page 53 of your report and you are now talking about Kim

22 potential developments. When you wrote this, you were told to

23 focus on scheduling information; correct?

24 A. That is correct.

Whilst he maintained his reading of [0092] of Kim, Dr Irvine accepted (a) that the only paragraph in Kim which he considered might describe a new trigger for SI was [0058], but he acknowledged that could be read consistently with the CGK; (b) that on Mr Townend’s view of the Fig 9 embodiment, it would not be understood as adding a new trigger for SI which was not in the CGK and (c) that Fig 9 could be read in that way.

Dr Irvine’s additional point was that if Fig 9 of Kim was read in this way, the Skilled Reader would see there was no difference between the Fig 9 and Fig 10 embodiments of Kim. However, this Fig 10 point had not been discussed in any of the expert reports and had not been put to Mr Townend. I have no idea where any such discussion might have led, so I will not consider Fig 10 any further.

Counsel put to Dr Irvine that on his approach, the Skilled Reader reads Kim with his or her CGK of HSUPA in mind up to Fig 9, but then abandons CGK at that point. Although Dr Irvine denied he had suggested that, his answers were revealing:

5 A. My boss has given me this document and told me, “Go away and

6 mine this for anything interesting”. …

15 Q. The way you have got there, you have been told to think about

16 Scheduling Information and you have asked yourself what else

17 you can get from Kim?

18 A. Yes, that is right.

In closing, IDC submitted that once one removes what they characterised as these misconceptions, the whole basis of Lenovo’s argument, namely that the Skilled Reader would see something special in the Fig 9 embodiment which allows HSUPA to be stripped away, falls away, as Dr Irvine acknowledged:

21 Q. If you are just reading Figure 9, absent knowledge that you

22 had about focusing on scheduling information, in particular,

23 you would think this is just another illustration of the

24 central idea of Kim?

25 A. I think all the diagrams are just illustrations of the central

2 idea of Kim, but yes.

IDC’s final point on the disclosure of Kim was that there is nothing in the Fig 9 embodiment which mentions or hints at transmission blocking. IDC submitted that the only reason why Dr Irvine went down this line of thinking was because of hindsight, taken in conjunction with his instructions:

12 Q. There is nothing in Figure 9 or anywhere in Kim that alerts

13 the skilled addressee to the existence of the

14 transmission-blocking problem, is there?

15 A. To the transmission-blocking problem? It does not

16 specifically flag it up to them. It simply says, “If you do

17 not have enough resources to send a MAC-e PDU, but you do have

18 enough resources to send scheduling information, send

19 scheduling information”. So that is what Kim says.

IDC submitted that there is nothing in the Fig 9 embodiment which ‘says’ anything of the sort.

In their closing, Lenovo argued that their anticipation case based on the scheme of Figure 9 of Kim was straightforward. The reasoning was explained as follows by reference to [0092]:

Steps 910, 915 and 920 at [0093] and [0094] are then simple to follow: if the E-TFC value associated with the MAC-e PDU configured according to [0092] is the special E-TFCI, the header is removed and the MAC-e control SDU (the SI) is sent alone (in the form illustrated in Figure 7B).

On this basis, Lenovo submitted that Kim anticipates claim 1 i.e. where the UE has a non-zero grant that is too small to transmit a MAC-es PDU, then it will send SI (provided that the grant is large enough to permit that).

In the alternative, Lenovo submitted that to the extent that such a system is not clearly and unambiguously disclosed in [0092], then an obvious way to implement [0092] would be as Dr Irvine suggests and as set out above.

When assessing this central dispute, I bear in mind that, in terms of its terminology, the experts agreed that the Skilled Person would recognise that Kim uses the term ‘scheduling information’ and ‘MAC-e control information’ to refer to what is SI in TS 25.321, and that Kim uses ‘transport format’ or ‘E-TF’ to refer to E-TFC/E-TFCI.

In my view, the answer to the central issue is provided by considering the context within which the teaching in Kim would be read and understood by the Skilled Person.

As far as I could detect, only two possible specific contexts were put forward: either the Skilled Person would read and consider Kim’s disclosure in the context of implementing HSUPA or in the context of a WiMAX system.

Dr Irvine did point out that HSUPA was an unusual communications system because there is so much variability in what it is that you can send. He referred to time division multiplex systems which use fixed transmission intervals into which ‘I can put whatever it is I am able to send’.

So far as WiMAX is concerned, it was not discussed in any of the written expert reports and it follows that I received no information about it, whether as part of CGK or otherwise. I do not know whether it was a TDM system or not. It happens to have been discussed in one of Dr Irvine’s exhibits – an extract from the December 2006 edition (i.e. post-priority) of the IEEE Vehicular Technology magazine which was edited by Dr Irvine in the context of a proposal for 4G. The first mention of WiMAX in direct evidence came from Dr Irvine in an answer on Day 4.

Dr Irvine made it clear in his answers that he thought Kim was pointed/directed at HSUPA, but Counsel picked up that he was suggesting Kim could have been aimed at other systems and pursued that suggestion in this exchange:

7 Q. What else do you think they might be trying to implement,

8 other than HSUPA?

9 A. Any system where you have, you are sending Scheduling

10 Information and you want to improve the efficiency of sending

11 that Scheduling Information by not identifying it with a

12 header.

13 Q. Right. Would you at least accept that the most natural way to

14 read Kim is together with TS 25.321, explaining how the MAC

15 layer works in UMTS?

16 A. I would certainly accept it is a natural way of doing it.

17 Q. Why is it not the most natural way? Can you give another way

18 that is more natural than that?

19 A. If I was reading Kim and I was looking, for example, at WiMAX

20 and I had that in my mind, I might be reading Kim and saying,

21 "Is there anything in this that I could take from that which

22 might then apply to my particular situation?"

The only other mention of WiMAX came a few pages later:

…you drew attention to the use of the term "E-TF" in

2 Figure 9.

3 A. Yes.

4 Q. That is a term that relates to HSUPA rather than something

5 such as WiMAX; correct?

6 A. Yes, but because the patent had explained what it meant by

7 E-TF, then I would be able to take that concept and apply it

8 to other technologies.

Whilst I entirely accept that the Skilled Person would have been able to take the central idea of Kim and apply it in other communications systems, such as WiMAX, I do not consider the reference to WiMAX or other systems takes the analysis any further than that.

I accept Mr Townend’s view that the Skilled Person would read Kim with his or her HSUPA CGK in mind. On that basis, I accept Mr Townend’s view as to what the Fig 9 embodiment of Kim would disclose to the Skilled Person, as summarised in paragraphs 229-234 above. I also accept that Dr Irvine’s alternative reading was a hindsight view prompted by the particular way in which he was invited to consider Kim. For these reasons, I reject Lenovo’s case that Kim anticipates.

It is not necessary to set out any of the well-known propositions of law which apply to an obviousness attack. Suffice to say I have them fully in mind.

I can deal with Lenovo’s case of obviousness over Kim relatively briefly.

In Dr Irvine’s first report, when assessing potential developments from Kim, he considered that the figure 9 embodiment would be “potentially useful and would be of most interest to the Skilled Person”.

In their Opening Skeleton, Lenovo submitted that a real person working at the priority date would not use Kim as a starting point for commercial reasons, namely that they would not be keen on producing an alternative system to 3GGP HSUPA. (The submission was that such considerations are irrelevant to the Skilled Person). Dr Irvine was asked whether he agreed:

Q. Do you agree that a real person working at the priority date would not use Kim as a starting point, full stop?

A. I have personally been asked to go and look at old patents to see if they can be mined again for useful information. Would somebody take the system that Kim had described and implement it? There is HSUPA out there. Would they go back to a document like Kim and look for any interesting nuggets? Maybe.

Q. The highest you can go is “maybe”, assuming somebody is looking for nuggets?

A. Yes.

…

Q. The skilled person interested in developing HSUPA Release 7 at the priority date is not going to go back in time and start developing a system they know to be obsolete, are they?

A. This is where you come back to your nuggets. You might look at older documents which had been following a particular theme, and knowing what you know now, go back and look at those to see if there are any interesting ideas that had not been followed through that you could now then follow through.

Q. You are assuming someone who has some motivation to go looking through these documents for the nuggets and they get to Kim and they do not read Kim as just talking about HSUPA; they read Kim as talking about something more general?

A. Yes.

Q. As to suggesting which had never in fact been done in HSUPA?

A. Yes.

Q. But have you to do all that to get the nugget?

A. Yes.

Q. Can I suggest that these amount to good technical reasons as to why the skilled addressee would not go through that process?

A.

They do amount to good technical reasons that the skilled addressee would not go through those; yes.

So far as considering Kim in the context of HSUPA is concerned, the Skilled Person would note (as I have said above) that the central idea of Kim had already been incorporated into HSUPA in Release 6. This was the reason why Dr Irvine accepted that Kim was ‘really old news’ by the priority date.

I do not think the Skilled Person would read [0092] to [0094] as a suggestion to re-write the process of E-TFC restriction and selection which was by then in the standard. It was not suggested that the Skilled Person had any motivation to re-consider, let alone re-write the processes of E-TFC restriction and selection which were in the standard (which is what Dr Irvine’s approach would have required). Those paragraphs would be read as just another way of explaining how the central idea in Kim could be implemented. On reading those paragraphs, the Skilled Person would, in my view, simply note that this was yet another respect in which HSUPA had moved on since Kim was written. In other words, having considered Kim and his Fig 9 embodiment with interest, the Skilled Person would have no motivation to do anything except put it on one side.

Overall, I formed the view that this obviousness argument was also driven by hindsight and I reject it.

In case I am wrong about the validity of claim 1 over Kim, I will consider the position of claim 2. I agree with IDC that claim 2 remains inventive. I need only cite the following two passages of cross-examination. In the first, Mr Townend was effectively asked to assume Dr Irvine’s understanding of [0092]-[0095] of Kim, but his answer led back to the earlier discussion of Lenovo’s Case 2 (i.e. whether claims 2 & 4 were obvious based on a simple modification to the PMS):

2 Q. I understand. Let me rephrase my question. If they are

3 building a system in accordance with their understanding of

4 paragraphs 91-95 of Kim and following those instructions as

5 best they could, it would be an obvious thing for them to do

6 to include within their system a timer like T_SIG and T_SING

7 which provided for SI to be sent, triggered periodically.

8 A. Unfortunately, I think it does matter whether, how to read,

9 how we are reading the second embodiment, because under what I

10 will call my reading, the reading consistent with the CGK, it

11 would certainly be natural to add the triggers if they were

12 not already there, sorry, to add the periodic sending, because

13 my reading relies on there being triggers in the first place.

14 Under what I can call your reading, what it amounts to

15 is opportunistic SI, because what you are saying, I think, is

16 that you have picked an E-TFC and if there is space in it, you

17 will put in Scheduling Information. So we are then, I think,

18 back into that whole thing of does it make sense to add

19 periodic scheduling on top of opportunistic SI? I am not

20 convinced that that is an obvious thing to do, for all the

21 reasons we talked about this morning.

IDC also pointed to the extent of the ingenuity in Dr Irvine’s answer of how to get to claim 2 from his understanding of Kim, and that in this answer even he was equivocal:

For completeness, I find that claim 4 was not inventive over claim 2. On that basis, it was obvious to allow the network to configure the period of the timer. Indeed, in IDC’s Opening, this feature was acknowledged to be CGK.

For all the above reasons, I find EP(UK) 2 421 318 B1 to be valid and essential.

I will hear Counsel as to the form of Order if it cannot be agreed. I direct that time for seeking permission to appeal shall not run until after the hearing on the form of Order (or the making of such Order if it is agreed). I draw attention to paragraph 19.1 of the Patents Court Guide, which says that a hearing on the form of Order should take place within 28 days of hand down. In the present case, 28 days from hand down will be 28 February 2023.

Mobile telecommunication systems are characterised, as they were at the Priority Date, by the support of user mobility, which is the ability for users to use the system while moving throughout the area covered by the system. In practical terms, user devices such as mobile phones are connected to the system using radio frequency communications.

The vast majority of commercial mobile telecommunication systems (from the 1980s to the present day) are so-called cellular radio networks, where the coverage area of the system is divided into a number of cells. This is illustrated in Figure 1 below. Each cell (shown as rough circular shapes in different shades) is served by a base station transmitter and receiver (or transceiver) (shown as small triangles) through an antenna system.

In some mobile telecommunication systems (such as that shown in Figure 1 above) each base station would serve a single cell. In other mobile telecommunication systems, the base stations would often serve more than one cell each.

A single base station may have a number of directional antennas, each of which serves a cell. The cells of each antenna overlap and base stations might be situated so that their cells cover adjacent and overlapping areas. This is shown in Figure 2 below: three base stations are shown (1, 2 and 3) each of which has three directional antennas (A, B and C) which in turn each serve a cell (indicated by the blue, red and yellow cardioids).

If a mobile phone is in an overlapping area, it might have a connection to multiple cells, in which case it is said to be in soft handover between those cells. In the special case where the mobile phone has a connection to multiple cells of the same base station (and it receives a single power command through all of those base stations), it is said to be in softer handover between those cells, and the base station to which those cells belong is able to combine those signals. The set of cells with which a mobile phone is in soft (or softer) handover is known as the active set.

Figure 2 shows a representation of a mobile phone moving through the area covered by a mobile telecommunications system employing soft and softer handover, at five different instances, with five different active sets. It is not necessary to go through each instance, but note that at instance 5, the mobile phone’s active set consists of cell 1B, cell 1C, and cell 2A. Because cell 1B and cell 1C are served by the same base station (base station 1), at instance 5 the mobile phone is in softer handover between those two cells. Additionally, at instance 5 the mobile phone is in soft handover between (i) cells 1B and 1C, and (ii) cell 2A (because (i) cells 1B and 1C, and (ii) cell 2A are not served by the same base station).

The base stations are connected to other pieces of inter-connected network equipment, such as controllers, switching centres, routers and subscriber databases, that work together to provide the telecommunication services to the end users of the system.

The user devices, such as mobile phones, cellular data modems in computers and tablets, communicate with the network equipment (and vice versa) using radio frequency communications. The communication from the user equipment is described as the uplink, and the communication to the user equipment is known as the downlink.

Uplink and downlink communications within a cell are usually distinguished because they are transmitted either:

Communications from different users to a base station, and from different base stations (or, more specifically, different cells), are distinguished using:

Real life systems often use combinations of these technologies. At the Priority Date in the UK, 3G networks primarily used codes (known as wideband CDMA, or WCDMA) to differentiate between communications from a base station to different users, and from different users to a base station, and different frequencies to distinguish uplink from downlink communications. In the UK, UMTS was an FDD WCDMA system and generally in this CGK Annex, references are to a FDD system, unless explicitly stated otherwise.

Amongst the 3G systems developed is the UMTS system developed by the 3^rd Generation Project Partnership (3GPP). The first release of UMTS (Release 99) was “frozen” in 2000, and commercial networks launched in Europe in 2003. A release is a complete set of Technical Specifications which together specify a particular iteration of a mobile telecommunications system. Features are “frozen” to allow manufacturers and networks to implement the standard.

In an FDD WCDMA system, multiple adjacent cells use the same pair of frequencies (one for downlink and one for uplink) and use specially selected spreading and scrambling codes to distinguish transmissions from different sources (user devices in the uplink or cells in downlink).

For example, in Figure 2 above:

It is not necessary to explain in any detail how this is accomplished, however, there are a number of important consequences of this technology:

The remainder of this section contains a description of the aspects of UMTS which are relevant to these proceedings. Many of these aspects of UMTS are also used in HSUPA, with certain modifications, which are explained below.

Figure 3 below shows the overall system architecture of the UMTS system, and its connections to external networks. No relevant modifications were made to the system architecture to implement HSUPA.

The UMTS system can be thought of as comprising the following functional network elements, as shown in Figure 3 above:

Data sent may terminate beyond the Core Network (for example, a call made from a mobile phone to a landline will terminate in the Public Switched Telephone Network). In addition, data received may originate from beyond the Core Network (for example, a video streamed from the internet). Other than this, only the UE and the UTRAN are relevant to the Patent, and so it is not necessary to consider the functionality of the Core Network.

As can be seen in Figure 3 above, the UTRAN comprises the following logical entities:

As Node Bs are the UMTS-specific version of base stations, the terms “active set”, “soft handover”, and “softer handover” can be applied to Node Bs and cells of those Node Bs in the same way that they were applied to base stations generally.

RNCs can serve several different roles simultaneously and are named according to which role is relevant. Thus, if an RNC is described as the Serving RNC (SRNC), it means it is the RNC which controls Radio Resource Control (RRC) signalling (see further below) for a UE and maintains a connection to the Core Network for that UE. No other roles of the RNC are relevant for the purposes of this trial. RRC signalling from the SRNC is sent through all Node Bs with cells in the active set.

Node Bs and RNCs are commonly referred to as “logical” entities because there is nothing in the standards which requires them to be two physically separate entities. However, for present purposes each logical entity can be considered a physically separate entity.

UMTS characterises the functions of the UE, the Node B and the SRNC by specifying the protocols in them.

A protocol specifies a set of predefined rules that allow devices to communicate with each other.

The relevant UMTS protocols for this report are, referring to the bottom three layers of the OSI model:

These protocols exist on both the UE side and the UTRAN side of the telecommunication system and, for example, the RRC functionality in the UE is frequently referred to as being in the UE’s “RRC protocol entity”. The functions of each of the protocols is explained at paragraph 35 below.

Each of the UE and the UTRAN will contain a “protocol stack” comprising all these protocols (i.e. RRC, RLC, MAC and the physical layer). The relevant part of the UE’s protocol stack comprises RRC, RLC, MAC and the physical layer – the higher layers are not relevant in this case. Strictly in UMTS there is some physical layer functionality in RNCs and some (very specific) MAC functionality in the Node B, but they are not relevant to this case, so we can proceed on the basis that in the UTRAN in UMTS, the Node B’s protocol stack comprises only the layer 1 (physical layer) functionality (i.e. only a physical layer protocol entity), and the SRNC’s protocol stack comprises only the layer 2 and 3 functionality (i.e. RRC, RLC and MAC functionality or protocol entities). Therefore, the Node B and the SRNC combined provide the corresponding functionality (or protocol entities) for all the relevant protocols in the UE.

Each protocol entity communicates with its “peer entity” on the other side. For example, the RRC protocol entity in the UE communicates with its peer RRC protocol entity in the SRNC. However, such communication between peer entities is indirect. The peer RRC protocol entities cannot communicate directly – information sent from the UE RRC protocol entity to the SRNC RRC protocol entity must make use of relevant lower-layer protocol entities in the protocol stack both at the UE and the SRNC, and also in any intervening logical entity (here, the Node B). The peer entities are not concerned with the operation of the lower-layer protocols, nor do the lower-layer protocols have to know the contents of the higher-layer messages they are transmitting. Figure 4 below (adapted from Figure 11 of TS 25.301 V6.2.0.) shows some physical layer functionality in the SRNC. This is to deal with the user device being connected to two (or more) cells at once during "macrodiversity" (as mentioned below) and shows the protocols in the UE, the Node B and the SRNC in UMTS. Protocol entities connected with horizontal lines communicate with each other, using lower protocol entities to carry the data.

There are a few points to note about this scheme:

Flows of data between these protocols are described as belonging to different radio bearers or channels depending on which protocol entities they are passing between.

Data which is sent over the UMTS system will either be:

Figure 5 below (adapted from Figure 2 of TS 25.301 V6.2.0) shows the protocols, radio bearers and channels relevant to this report. The left hand side of Figure 5 shows flows of control data through the protocol stack. The right hand side shows flows of user data through the protocol stack.

As can be seen in Figure 5 (reading from top to bottom, and left to right):

In the UE, for uplink communications, the protocols perform the following functions:

Set out below are the relevant UMTS channels.

In the UTRAN, for uplink data, each protocol performs the reverse process of that performed in the UE. For RRC, this means that the SRNC communicates with the Node B in order to set up the lower-layer entities, and also provides various instructions to the UE. For downlink data, much of the functionality is swapped between the UE and the UTRAN.

In UMTS, the flows of data discussed above are transmitted between layers in “packets”. A packet of data, which a lower layer in the protocol stack receives from the layer above, is known as a Service Data Unit (SDU) for the receiving layer. Generally, each layer will at least add its own header to an SDU before passing it on to a lower layer. A packet of data (including header) which a higher layer passes to a lower layer is known as a Protocol Data Unit (PDU). The part of the new PDU which contains data from the layer above (i.e. the lower layer’s SDU) is also known as the PDU’s “payload”.

Figure 6 below (taken from Figure 9 of the ITU-T X.200 standard (07/94), commonly known as the OSI 7-layer model) illustrates the mapping of data into the data units of two layers in a given network element, namely the upper (N)-layer and the lower (N-1)-layer. The “payload” of (N-1)-PDU is (N-1)-SDU. The figure describes the header as being “Protocol control information” or “PCI”.

Whilst a lower layer will process a higher layer PDU (for example, by adding a header and passing it on to a lower layer), it will not interpret the contents of a higher layer PDU. The higher layer PDU is said to be “transparent” to the lower layer. This is because ultimately the critical communication is only between peer entities within the protocol stack, as explained above.

Thus:

The physical layer receives a MAC PDU as a Transport Block (TB). However, this is merely a difference in terminology, and the Transport Block is in effect the physical layer SDU.

Quality of Service (QoS) is used within UMTS to describe the required service attributes which a communication (e.g. a phone call, streaming a video, downloading a webpage, uploading an email) must have.

The standards set out various ways of defining QoS (including priority of the data, traffic classes or QoS classes, required bit rate and residual bit error rate). In particular, RRC can control the scheduling of uplink data by giving each logical channel a priority between 1 (highest priority) and 8 (lowest priority).

There are four QoS traffic classes in UMTS:

Delay is the main distinguishing factor between the four QoS traffic classes, although there are also differences between the error correction mechanisms which are used as a result and, consequently, differences in the transmit power which must be used for a given bit error rate. Furthermore, conversational class and streaming class traffic (which are both real time classes) may have a guaranteed bit rate specified.

Although there is no strict relationship between a QoS traffic class and the type of data it can carry, there are typical types of data (such as voice, video and web browsing) for which a QoS traffic class may be used (respectively, conversational class, streaming class and interactive class).

Within each class, priority levels may be specified. Using these, the relevant network elements can prioritise data flows with a high priority value over data flows with a lower priority value. Alongside these priorities, QoS will also take into consideration required data rate and residual bit error rate.

RRC is responsible for configuring the radio interface between the UTRAN and the UE in accordance with the required QoS traffic class (and other attributes) for a connection. This includes configuring RLC, MAC (including logical channel priorities), transport channel(s) and the physical layer.

In any system using CDMA technology, fast power control is critically important. Power control is especially important in the uplink where it ensures that the UE transmits at the minimum power required for the SRNC to receive from Node Bs having cells in the active set the UE’s transmissions with the desired block error rate (BLER). Using the minimum required power means that the transmission from one UE is less likely to block or unnecessarily interfere with transmissions from other UEs using cell(s) in its active set.

When the UE is configured to transmit using dedicated channels, the SRNC estimates a signal to interference power ratio (SIR) target for the UE’s transmissions required to ensure the desired BLER; the SRNC then sends this SIR target to those Node B(s). The Node B(s) instruct the UE to increase or decrease transmit power to maintain the SIR as close as possible to the target.

The power control commands are sent to the UE, and so the UE can change transmit power level, every 0.667ms (or 15 times every 10ms).

While the power control commands manage the overall transmit power of the UE, the UE can transmit multiple physical channels at different power levels in order to support their individual QoS requirements.

This is accomplished by establishing a single physical channel as a baseline and then defining all other channel powers relative to that baseline. The power control commands then cause the power for every channel to increase or decrease together, while preserving the proportional relationship between their power levels.

In UMTS, the dedicated physical control channel (DPCCH), which carries physical layer control information, is used as the baseline power level relative to which all other dedicated channel powers in the UE are set.

UMTS allows a user to use several “applications” at the same time. For example, a user might be simultaneously using three applications: talking on the phone, browsing the web and sending an email.

Each application in use will require logical traffic channels (i.e. DTCH) to send the user data, and logical control channels (i.e. DCCH) to manage the channels carrying the user data. So in the example in the preceding paragraph:

Typically, RRC will configure three logical control channels (DCCH) and part of this configuration will be that they are multiplexed onto a single transport channel (DCH) (rather than configuring one transport channel per logical control channel). Indeed, it might also be possible to multiplex one of the logical traffic channels (DTCH) onto the same transport channel (DCH). The multiplexing of different logical channels onto the same transport channel in the MAC-d is known as “C/T multiplexing”. When two (or more) logical channels are C/T multiplexed a MAC header comprising a C/T field (a four-bit number identifying the logical channel to which the MAC SDU belongs) is added to each PDU individually based on its logical channel, so that whilst the physical channel will not distinguish between packets from different logical channels, the peer MAC protocol entity (for example, in the SRNC) can de-multiplex the received transport channel and send packets to the correct logical channel (whether control (DCCH) or traffic (DTCH)). Each MAC PDU is still dealt with as an individual Transport Block (TB) by the physical layer.

The physical layer can also multiplex transport channels into a single Coded Composite Transport Channel (CCTrCH) for further processing by the physical layer. For example, the three DCH transport channels carrying the user data for the user’s three applications in the example above (i.e. carrying the three DTCH logical traffic channels), would be multiplexed in the physical layer into a single CCTrCH if they are going to be sent over a single dedicated physical channel (or multiple physical channels of the same type, a solution adopted where one physical channel cannot carry the amount of data required). In contrast to C/T multiplexing, physical layer multiplexing allows for different levels of error protection between the different transport channels being multiplexed because the physical layer can distinguish between packets based on the transport channels they arrive on and process them differently.

Data is transmitted within defined periods known as Transmission Time Intervals (TTI). Every TTI (for example, every 10ms) a UE will need to (i) determine which data to send to the Node B and (ii) send it.

In UMTS, MAC is responsible for determining which data to send from a UE to a Node B. How it does so is tightly controlled.

Each TTI a UE can send a single Transport Format Combination (TFC) to the Node B. A TFC is, as the name suggests, a combination of “Transport Formats” that specifies the size of packet from each transport channel and the total size of data sent for each transport channel. When the UE has data to transmit, it selects a TFC and fills it with data. The skilled person would recognise that the PMS in section 11.4 specifies how this is done in some detail but, since the way it is handled in UMTS is not relevant to this dispute, it is not necessary to set it out.

HSDPA was the key new UTRAN feature included in Release 5. It was introduced with the objectives of improving user experience by enhancing system capacity and efficiency. As previously noted, HSDPA aimed to provide higher data rates for downlink user data sent from a Node B to a UE to support particular services such as web browsing and streaming. HSDPA was not (and is not) a standalone system: a UE implementing HSDPA is required by the standard to also implement UMTS.

By the Priority Date, the standardisation of HSDPA was sufficiently complete that HSDPA was already part of commercially available products.

HSDPA introduced various techniques into UMTS, including:

This is a long section and it may assist to set out how it is structured:

The Introduction of HSUPA into the 3GPP Standards

HSDPA introduced enhanced downlink capabilities, but they were not matched by uplink capability until HSUPA was introduced in Release 6, which was complete by September 2005, with only corrections and clarifications being added after that date. The 3GPP working groups moved on to the development of Release 7 which would include further HSUPA functionality. As indicated by the PMS itself, early Release 7 specifications started to be released shortly before the Priority Date, but Release 7 was in active development at the Priority Date. HSDPA networks were commercially available by the Priority Date but not HSUPA networks (the first commercial HSUPA network was launched in February 2007).

Like HSDPA, HSUPA was not (and is not) a standalone telecommunications system. A UE implementing HSUPA is required by the standard to also implement both UMTS and HSDPA. Therefore, much of the description of UMTS above is also an accurate description of HSUPA. As was the case in UMTS, the behaviour of the UE in both HSDPA and HSUPA is very tightly specified, while the behaviour of the network is, to the greatest extent possible, left to implementation.

The aim of HSUPA was to provide enhancements to the uplink similar to those provided to the downlink by HSDPA, in particular in terms of user experience (throughput and delay) and capacity. It introduced a new “enhanced” uplink transport channel called the Enhanced (Dedicated) Transport CHannel (E-DCH) - Dedicated because each UE has its own E-DCH data path to the Node B that is continuous and independent from the DCHs and E-DCHs of other UEs. HSUPA also introduced to the uplink techniques similar to those in HSDPA, namely:

HSUPA also supports the sending of “non-scheduled data”, which is data that is not subject to fast Node B scheduling. The existence of such data is relevant, but the details of its operation are not, so it is not addressed in detail.

High-level overview of HSUPA

The aspect of HSUPA most relevant to this trial is the fast Node B-controlled scheduling. Being physically close to the air interface, the Node B has more instantaneous information about the uplink interference situation than the SNRC and can control uplink data rates in a rapid manner.

Put simply, uplink scheduling in HSUPA allows the Node B to control how much data (and power) each UE within its service area is transmitting at any moment in time, both to optimise the user experience of all users and to minimise interference, in turn increasing the overall capacity and throughput of the system. For example, more resources might be allocated to users with a lot of data waiting to be sent, or they might be allocated to users close to the Node B for whom more of the power would be used to send data and less to overcoming the pathloss to the Node B.

The scheduling function in HSUPA is split between the Node B (which is responsible for resource allocation) and the UE (which is responsible for making use of the resource allocation to send data).

The Node B scheduling is implemented by the UE receiving grant messages from the Node Bs with which it is in soft handover (i.e. where a UE has a connection to multiple cells) and using those to derive a single “Serving Grant” value which will be used to control the amount of scheduled data that can be sent at a time. The Serving Grant is quantified as a relative power level, expressed as a ratio to the power at which the existing UMTS Dedicated Physical Control Channel (DPCCH) is transmitted, but is eventually converted into a number of bits of scheduled data that can be transmitted.

There are two types of grant messages used by the Node B to control the maximum amount of transmit power used to send scheduled data. One is an Absolute Grant (which is sent only by the serving E-DCH cell and which is intended to set the Serving Grant to a specific value) and the other is a Relative Grant (which is used to move the Serving Grant to a higher or lower value).

The UE provides status information (known as “Scheduling Information”) to the Node B so that the scheduling function receives, among other things, information on the amount of data in the UE’s buffers awaiting transmission and the radio channel conditions or relative power the UE can use for its data transmissions.

The 3GPP specifications define rules for when Scheduling Information is to be sent by the UE, for example, the expiration of a timer, which leads to periodic transmission of Scheduling Information. The triggering conditions are discussed in detail below in paragraphs 127 to 134.

The Node B scheduler uses the Scheduling Information sent by the UE together with a so-called “happy bit” (which indicates whether the UE is “happy” or “unhappy” with the current data rate) to make decisions on whether to adjust the UE’s Serving Grant.

HSUPA can be configured with either a 2ms or 10ms TTI, which means that a single packet of data (called a MAC-e PDU, or, equivalently, an E-DCH transport block) is sent to the physical layer either every 2ms or 10ms.

HSUPA uses a “stop-and-wait” HARQ, which involves the transmitter waiting to send a second block of data until it has received an acknowledgement (ACK, an indication that a packet has been correctly received) for the previous block (or until a maximum number of retransmissions has been reached, or, perhaps, a timer has expired). In order to prevent the obvious delays that this would cause, HSUPA calls for multiple HARQ processes. The operation of HARQ is substantially the same for both 2ms and 10ms TTI, but the number of HARQ processes is not. 2ms TTI used 8 HARQ processes, whilst 10ms TTI used 4 HARQ processes. HARQ processes are conventionally numbered from 0 (zero). This allows the HARQ processes to operate in sequence and cyclically (i.e. simply by knowing which TTI is next, the UE can identify the one operational HARQ process for that TTI), such that in the first TTI, HARQ process 0 transmits, then in subsequent TTIs, HARQ processes 1 to 7 transmit whilst HARQ process 0 waits for its ACK or a negative acknowledgment (NACK, an indication that an errored packet has been received), then in TTI 9, HARQ process 0 can either transmit the next packet (i.e. the one after the packet sent on HARQ process 7) or retransmit the packet it transmitted last time (in case there has been a NACK (or no ACK)).

As part of the initial set-up of HSUPA for a UE, individual HARQ processes can be “restricted” by RRC (meaning that they cannot be used for scheduled data), and as part of the scheduling grant process, individual (or all) HARQ processes can dynamically be activated and deactivated (meaning that they can and cannot be used for scheduled data).

HSUPA entails significant changes from UMTS and HSDPA for the sending of data. In each TTI, the UE can send zero or one MAC-e PDU (partly because there is only one uplink transport channel, the new E-DCH). This MAC-e PDU may contain data from multiple logical channels (for example, it could contain data for a video call, a webpage, and an email, as well as associated higher layer control information). If Scheduling Information is to be sent, it is included in the MAC-e PDU. The size of the MAC-e PDU is constrained to match one of 128 pre-defined sizes (each being an E-DCH Transport Format Combination (E-TFC). The E-TFC is the HSUPA equivalent of, but not the same as, the TFC in UMTS.

The process of selecting the E-TFC and determining what data is to be included in the MAC-e PDU is somewhat complex, and is described in greater detail later. An overview is set out here.

In each TTI, the UE will first update the Serving Grant (according to any Absolute and Relative Grants received), and will then work out what data, if any, it is able to send in that TTI.

This involves multiple steps, including:

The UE will then multiplex together any required Scheduling Information and the maximum possible amount of data, subject to all of these constraints and the priority ranking of the logical channels, before selecting the smallest E-TFC that will fit the resulting MAC-e PDU.

The UE will then transmit the (scheduled and non-scheduled) data (and any Scheduling Information) on one or more of the new E-DCH Dedicated Physical Data Channels (E-DPDCH(s)), and related control information on the new E-DCH Dedicated Physical Control Channels E-DPCCH (see below).

HSUPA protocol stack and relevant channels

HSUPA introduced new channels for sending and controlling the sending of user data on the new Enhanced Dedicated Transport Channel (E-DCH), new protocol entities in the MAC to allow access to the new channels in the UE, and new peer MAC protocol entities in the Node B (in contrast to UMTS, which had no (relevant) MAC functionality in the Node B) and the RNC to join the new channels back to the pre-existing system.

Figure 8 below (adapted from Figure 5.6.10.3-1 of TS 25.301 V7.0.0.) shows the protocols in the UE, the Node B and the SRNC. As with UMTS, protocol entities connected with horizontal lines communicate with each other, using lower protocol entities to carry the data.

The MAC-d layer protocol entity was retained in HSUPA, and additional entities were introduced:

As already stated, HSUPA also introduced new uplink channels. The E-DCH carries user plane data and non-physical layer control data. After transport channel processing, the E-DCH maps on to one or more (up to six, to support higher data rates) uplink physical channels, the E-DCH Dedicated Physical Data CHannels (E-DPDCHs). The E-DPDCHs require simultaneous transmission of an uplink physical control channel, the E-DCH Dedicated Physical Control CHannel (E-DPCCH), to carry physical layer control data to deliver the information the receiver needs in order to know what format of E-DPDCH transmission is being used.

Two downlink physical channels were also introduced to facilitate uplink scheduling:

Finally, a third downlink physical channel was introduced to carry HARQ acknowledgment information (ACKs and NACKs) to the UE called the E-DCH HARQ Indicator CHannel (E-HICH).

Table 2 is an updated version of Table 1 above, showing the newly-introduced HSUPA channels (in red), and identifying whether those channels are uplink or downlink channels.

RRC role in HSUPA

RRC configures whether each MAC-d flow (a conceptual grouping of logical channels with similar QoS requirements - shown in green in Table 2 above) is either (i) subject to Node B-controlled scheduling or (ii) allocated to a non-scheduled transmission (but not both).

Non-scheduled transmissions are conceptually similar to the allocation of a transport format to a logical channel in UMTS – a UE is given the ability to configure a specific MAC-d flow to have a guaranteed physical layer data rate, effectively disabling Node B scheduling. In contrast, Node B-controlled scheduling allows the UE to use a maximum amount of power to transmit data from any channel configured to utilise Node B-controlled scheduling.

As in UMTS, RRC can control the scheduling of uplink data by giving each logical channel a priority between 1 (highest) and 8 (lowest). The UE is required to maximise the transmission of higher priority data, that is to say, data from the highest priority logical channel with data in its buffer.

Relevant MAC functions in HSUPA

The MAC-e/es in the UE is responsible for determining what data, both user plane data and non-physical layer control data, is sent over the new channels each TTI. As explained below (in section 18, beginning on page 105), how the MAC-e/es selects data for transmission is tightly controlled but is based on the allocated resources and the power available for enhanced uplink transmission. The MAC-e/es multiplexes the selected data in order of its logical channel priorities, subject to certain constraints. Data from the highest priority logical channel is concatenated (i.e. inserted one after the other) into a MAC-es PDU and, if allowed, data from lower priority logical channels is concatenated, in priority order, into separate MAC-es PDUs. (Data from a single logical channel might be multiplexed into several MAC-es PDUs, if the MAC-d PDU sizes are different, but this is not relevant to this dispute). One or more MAC-es PDUs is/are multiplexed in accordance with pre-defined limits into a single MAC-e PDU, until the grants or the available power are exhausted. A MAC-e PDU might also include Scheduling Information and padding bits. A MAC-e PDU is carried on the E-DPDCH as a single transport block, the E-TFC.

Each E-TFC governs the overall size of data which can be multiplexed into it. The E-TFC used is signalled on the E-DPCCH by means of a seven-bit E-DCH Transport Format Combination Indicator (E-TFCI), which indicates the size of the transmitted data by reference to a lookup table of transport block sizes within the E-TFC Set. There are four configured transport block tables for the Enhanced Uplink, two for the 10ms TTI, two for the 2ms TTI, in each case optimised for a 336-bit RLC PDU size, or exponentially distributed. They are set out in Annex B to the PMS.

The single MAC-e PDU transmitted in a TTI could therefore contain data from a number of logical channels. Some of these logical channels might be grouped together within the MAC-e/es as MAC-d flows.

The peer MAC-e protocol entity in the Node B determines whether a HARQ retransmission of the MAC-e PDU is required, and if not it de-multiplexes the MAC-e PDU into its constituent MAC-d flows. The peer MAC-es protocol entity in the SRNC combines data from different Node Bs to which the UE is sending data (due to soft handover), separates the MAC-d flows into their different logical channels (necessary only if the MAC-d flow is made up of more than one logical channel), and forwards them to the MAC-d which forwards them to the RLC.

MAC-e/es functions in Node B scheduling

The MAC-e/es:

Aspects of the MAC-e/es functionality are covered in the following sections, finishing with a more detailed discussion of the MAC-e and MAC-es header fields. An understanding of the information carried in these header fields, how they relate to the information sent on the E-DPCCH, and when they are used, is important for understanding the cited prior art, Kim, and consequently, its relevance to the Patent.

First Function: resource allocation and Scheduling Information

The circumstances in which a UE can send Scheduling Information to the Node B depend on the resources it has been allocated. It is necessary to understand some terminology relating to handover, the allocation of scheduling grants by the Node Bs in the E-DCH Active Set, and the updating of the Serving Grant by the UE, before turning to the handling and contents of Scheduling Information.

Terminology

As with UMTS, in HSUPA a UE can be in soft or softer handover with multiple cells at the same time. The set of cells with which a UE is in soft (or softer) handover is known as the E-DCH active set (which may be the same as the UMTS active set or a subset of it).

Of the Node Bs controlling the cells of the E-DCH active set, one Node B has greater control than the others over the UE. This Node B is known as the Serving Node B. The cells of the Serving Node B through which the UE is controlled (and it need not be all cells controlled by the Serving Node B) are known as the E-DCH Serving Radio Link Set (or E-DCH Serving RLS). The cell of the E-DCH Serving RLS through which the Serving Node B exerts greatest control over the UE is known as the Serving E-DCH Cell.

Each cell in the E-DCH active set not controlled by the Serving Node B is known as a Non-serving E-DCH RL, or a Non-serving RL. The Node B(s) which control each Non-serving E-DCH RL have a reduced amount of control over the UE.

The E-DCH active set for a UE can be shown using Figure 2, reproduced below as Figure 9. The UE is in soft handover, for example, at instance 3 between cells served by three different Node Bs, and in softer handover at instance 2 between two cells served by the same Node B.

Table 3 below shows for the five instances in Figure 9 above the E-DCH active set, the Serving E-DCH Cell (and by implication the Serving Node B), the rest of the E-DCH Serving RLS, and any Non-serving RL(s), and, by column, which cells can transmit which scheduling grants (explained in section 9 below). Note that in instance 5, the Serving E-DCH Cell has changed from 2A to 1B, and Node B1 is the Serving Node B.

Resource allocation

As set out in paragraph 91 above, HSUPA introduced two new downlink physical channels on which grants for the transmission of scheduled data are sent:

The Absolute Grant and the Relative Grant are the two ways in which a Node B can modify the resources which a UE will use to transmit scheduled data.

The UE maintains a variable, the Serving Grant (SG) which is used to store the grant that is derived from the received Absolute Grant and Relative Grant messages. The Serving Grant is defined as a ratio of the E-DPDCH power to the baseline power level of the DPCCH, and represents the maximum power ratio allowed to be used for the transmission of scheduled data on the E-DCH.

The Absolute Grant

The Absolute Grant for a UE can only be transmitted by the Serving Node B through the Serving E-DCH cell (e.g. see Fig 9 above, where in instances 1 to 4, only Node B 2 can transmit an Absolute Grant, and then only through Cell 2A). The Absolute Grant provides the Serving Node B with the greatest amount of control over a UE’s Serving Grant, including by specifying the maximum power which can be used for the transmission of scheduled data. The Absolute Grant can vary the Serving Grant the most, although as discussed in paragraph 120 below, the Serving Grant is updated using the Serving Grant Update procedure, and certain values of the RG from a Non-serving RL may override certain values of the Absolute Grant from the Serving E-DCH Cell.

The Absolute Grant’s functionality varies depending on whether a 10ms or a 2ms TTI is configured, but includes:

Scheduled data is not allowed to be sent on an inactive HARQ process (whether deactivated or restricted by RRC). However, as a general rule, both non-scheduled transmissions and Scheduling Information can be sent on deactivated or restricted HARQ processes, so if all HARQ processes are deactivated or restricted, a UE can still send non-scheduled transmissions and Scheduling Information.

Relative Grants

Relative Grants instruct the UE to increase (“UP”), decrease (“DOWN”) or hold (“HOLD”) the transmit power previously used to transmit the E-DPDCH in a given HARQ process, with reference to a lookup table set out in the PMS - Table 9.2.5.2.1.1: Scheduling Grant Table (SG-table). It shows the 38 values a Serving Grant can take as the result of the UE implementing a Relative Grant command in the Serving Grant Update procedure, and the index for each such Serving Grant value.

Relative Grants can be transmitted by:

The starting point in interpreting a Relative Grant is to look at the E-DPDCH to DPCCH power ratio used for the E-TFC selected in the previous TTI of the current HARQ process. In particular, the previous value of the Serving Grant is not used as the starting point.

This is then adjusted to account for any non-scheduled data and Scheduling Information that was transmitted. The lookup table is used to convert the power ratio into a baseline index value.

A “DOWN” Relative Grant command decreases the baseline index value by one step. An “UP” Relative Grant command increases the baseline index value by either three, two, or one steps.

If neither an “UP” nor a “DOWN” Relative Grant command is received, the UE interprets the absence (sometimes referred to as discontinuous transmission or DTX) as a “HOLD”. This is perhaps not the most useful name, as a “HOLD” command does not prevent changes (down or up) to the Serving Grant (for example, because the UE might receive a Relative Grant from another Node B).

The Serving Grant Update procedure

The skilled person would know that the PMS – in section 11.8.1.3.1 - contains detailed “pseudo-code”, i.e. a step-by-step procedure, which specifies the Serving Grant Update procedure. It provides that, in the event that a UE receives more than one scheduling grant in a given TTI, which may conflict with one another, the new Serving Grant is set to the minimum of the Serving Grant resulting from a “DOWN” Relative Grant (i.e. receipt of multiple "DOWN" Relative Grant in one TTI does not result in multiple steps down) and the resulting Serving Grant from the Serving E-DCH cell’s scheduling grant.

Scheduling Information

Scheduling Information (sometimes abbreviated in the PMS to SI) is part of the uplink control information in HSUPA, the remainder being the 10 bits of control information sent on the E-DPCCH – see section 4.6.11). It provides information to the Node B to allow the Node B to make scheduling decisions for scheduled data transmitted from the UE in the uplink. It is not used to regulate non-scheduled transmissions and contains no information about non-scheduled data.

Scheduling Information is specified to include 18 bits of information. Scheduling Information is transmitted in a MAC-e PDU, either alone, or multiplexed with other data, in which case it is included at the end of the MAC-e PDU (but before any padding).

Although there is considerable detail about SI in the sections which follow, Lenovo were keen to stress one part of section 9.3.1 in TS25.309 from March 2006 (a document presented to Dr Irvine by Lenovo’s solicitors) where it states: ‘For the UE to request resources from the Node B(s), Scheduling Requests will be transmitted in the uplink in the form of Scheduling Information and Happy Bit.’ As Lenovo submitted, Mr Townend agreed that the Skilled Person would be thinking in such terms: i.e. that SI was a means for the UE to request resources.

Contents of Scheduling Information

Scheduling Information comprised four fields, each encoded with a specified number of bits. Those fields are:

Figure 10 (taken from Figure 9.2.5.3.2-1 of the PMS) below sets out the format of the Scheduling Information message, containing 18 bits.

Scheduling Information reporting

Scheduling Information was reported (i.e. transmitted from the UE to the Node B) because either:

Triggers for transmitting Scheduling Information were categorised into two main classes, based on the value of the UE’s Serving Grant.

In one of those two classes of triggers (set out in section 11.8.1.6.1 of the PMS), Scheduling Information is triggered by the following events where the Serving Grant is equal to Zero_Grant or all HARQ processes are deactivated (i.e. a UE is not allowed to send scheduled data):

In the second of those two classes of triggers (set out in section 11.8.1.6.2 of the PMS), Scheduling Information is triggered by the following events where the Serving Grant is not equal to Zero_Grant and at least one HARQ process is activated (i.e. a UE is allowed to send scheduled data):

There was also a further trigger (set out in section 11.8.1.6.3 of the PMS) at the Priority Date that was not within either of the preceding two categories. In this trigger, if a MAC-e PDU containing triggered Scheduling Information fails to be delivered to the Serving E-DCH RLS (i.e. either a NACK or no ACK is received from the Serving Node B – which Lenovo characterised as ‘delivery failure SI’), then:

Even if multiple events trigger the transmission of Scheduling Information, by the time it can be transmitted (it may be delayed by a HARQ retransmission), only one Scheduling Information shall be sent in the MAC-e PDU.

There is a general prohibition on sending Scheduling Information if TEBS is zero (i.e. the buffer in the UE is empty), even if Scheduling Information is otherwise triggered. The only exception to this prohibition is that Scheduling Information shall be included in a MAC-e PDU if the E-TFC which would otherwise be used has sufficient space to include Scheduling Information (as mentioned above at paragraph 127.2).

Furthermore, as previously stated, the UE can send Scheduling Information on HARQ processes which are deactivated or restricted by RRC, i.e. even when scheduled data cannot be sent.

Grants for the transmission of triggered Scheduling Information

If Scheduling Information is triggered, section 11.8.1.6 of the PMS requires that it shall be included in the next available transmission, although no more than one Scheduling Information shall be included in any transmission. A HARQ retransmission would take priority, but subject to that, Scheduling Information is allowed to take place on the HARQ process for the upcoming transmission, even if it is deactivated, or restricted by RRC.

Therefore, if Scheduling Information is triggered, section 11.8.1.4 of the PMS requires the UE to assume that there is a non-scheduled grant available for transmission of the Scheduling Information, and that the Scheduling Information has a priority higher than any other logical channel.

Second Function: E-TFC restriction

In each TTI, a UE will only select an E-TFC which it has sufficient power to transmit.

In a first step, the UE determines power available for enhanced uplink transmission by estimating the remaining power available on the uplink based on the maximum UE uplink transmission power, after the power required for various other channels has been taken into account. The maximum transmission power is a known parameter at the UE. It is limited either by the physical capabilities of the UE or signalled by the network.

In a second step, the UE determines which E-TFCs are supported, and which are blocked, by comparing:

If the power required is greater than the power available, the E-TFC is in a blocked state, subject to any configured “minimum set”, which specifies E-TFCs that are exempt from such blocking and may be transmitted irrespective of the power available: see section 11.8.1.4 of the PMS.

If the power required is not greater than the power available, the E-TFC is in supported state.

The process of determining which E-TFCs are in which state is known as E-TFC restriction. Only E-TFCs in a supported state are considered for transmission each TTI.

Third Function: MAC-e PDU generation and E-TFC Selection

Based on the outcome of the E-TFC restriction procedure (taking into account power required for uplink transmissions for UMTS and HSDPA, and the E-DPCCH), the Serving Grant Update procedure, and the Scheduling Information reporting procedure, the UE can determine what data to send in the upcoming TTI.

The Prior MAC Specification contains two descriptions of MAC-e PDU generation and E-TFC Selection.

The first, is in section 11.8.1.4 titled, E-TFC Selection (the Normative Description).

The second, in Annex C, is in the form of informative pseudo-code for E-TFC Selection (the Informative Description).

By the time the UE comes to generate a MAC-e PDU, it has determined:

The Normative Description lists the requirements which must be met when selecting an E-TFC and the data to be carried in the MAC-e PDU. In particular, the Normative Description states that:

The Normative Description also:

Although the skilled addressee would know that the Informative Description only “describes one possible implementation” of MAC-e PDU creation and E-TFC Selection, they would also understand that it demonstrated a sensible method of complying with the relevant parts of the standard. Mr Townend was of the view, which Dr Irvine did not dispute and with which I agree, that they would use it to aid their understanding of the Normative Description, especially with respect to how the various steps could be put together in a practical manner.

Fourth function: Configuring control information sent on the E-DPCCH

In order to correctly receive and deconstruct the MAC-e PDU, the Node B will need to receive two sets of control information from the UE:

The E-DPCCH carries ten bits of information in each TTI, made up of:

The E-TFCI indicates the size of the transmitted data (i.e. together the MAC-es PDUs, the MAC-e header, any Scheduling Information, and any padding) by reference to a lookup table of transport block sizes within the E-TFC Set.

The RSN specifies whether the E-TFC contains a retransmission, and if so, whether the first, second or subsequent retransmission. Beyond the second retransmission, the combination of the RSN and the transmission timing allows the receiver to determine the exact transmission number.

The happy bit indicates whether or not the UE is “unhappy”. The UE is “unhappy” if it is transmitting the maximum amount of data currently allowed, could transmit at a higher data rate, and will take more than a configurable period of time to empty its buffer based on the current Serving Grant. It is “happy” in all other circumstances.

Fifth function: HARQ retransmissions

If the previous MAC-e PDU sent on a HARQ process requires retransmission then (subject to the maximum number of HARQ transmissions not being already reached) that MAC-e PDU will be retransmitted using the same E-TFC in the next TTI for which the HARQ process is operational, and so a new MAC-e PDU cannot be transmitted in the TTI.

MAC-e and MAC-es header information

In HSUPA, there is no need for a MAC-d header.  The MAC-d merely routes data from RLC to the MAC-e/es in the UE in response to requests from the MAC-e/es to the RLC (and routes packets from the MAC-es to the RLC in the SRNC).  This is in contrast to UMTS, where the MAC-d’s functions include C/T multiplexing and the addition of relevant headers (see paragraph 58 above).  Therefore, in HSUPA, a MAC-d PDU is the same as: (i) an RLC PDU; (ii) a MAC-d SDU; and (iii) a MAC-es SDU.

Each MAC-es PDU carries higher layer data in the form of MAC-d PDUs of the same size and from a single logical channel, and has a MAC-es header. One or more MAC-es PDUs can be multiplexed into a MAC-e PDU, which has a MAC-e header portion per MAC-es PDU. This is shown in Figures 9.1.5.2 and 9.1.5.2a of the PMS, which show a MAC-es PDU and a MAC-e PDU respectively. These are reproduced below as Figure 11 and Figure 12 respectively.

As can be seen from Figure 11, each MAC-es PDU has a single header field, the TSN, or Transmission Sequence Number (6 bits) associated with it. The TSN identifies the order of the MAC-es PDU in relation to other MAC-es PDUs containing data from the same logical channel. This allows the MAC-es to reorder MAC-es PDUs so that it can deliver RLC PDUs to the RLC in order.

As can be seen in Figure 12 (in which colours have been added for clarity):

The inclusion of these elements is optional in that they may not be included in each MAC-e PDU. For example, there is no requirement to include Scheduling Information in every MAC-e PDU. It is only included in the circumstances set out in section 15 above. However, it is necessary that the MAC-e PDU sent on the E-DPDCH(s) is the same size as indicated by the E-TFCI on the E-DPCCH. The availability of the DDI₀ and padding is therefore necessary to allow transmission and correct reception of a MAC-e PDU, as explained below.

After including all MAC-es PDUs (and associated headers), how the amount of remaining space in the MAC-e PDU (determined from the E-TFC size) is used is determined by a three-part rule which is set out in section 9.2.4.2:

These rules taken together with the fixed size header portions (and the content of the header information) allow the Node B to infer where the boundaries between MAC-es PDU are, whether or not Scheduling Information is included, and how many bits of padding are included. In other words, the Node B has sufficient information to split up the MAC-e PDU into its constituent parts.

Where Scheduling Information is to be sent alone (i.e. with no MAC-es PDUs), the MAC-e PDU takes a simpler form, as shown in Figure 9.1.5.2b of the PMS and which is reproduced below as Figure 13. In this case, the MAC-e PDU simply comprises the 18 bits of Scheduling Information alone, with no header information or padding.