“52. … although it is inevitable that when an expert is asked what he would understand from a prior document’s teaching he will give an answer as an individual, that answer is not as such all that helpful. What matters is what the notional skilled man would understand from the document. So it is not so much the expert’s personal view but his reasons for that view—these the court can examine against the standard of the notional unimaginative skilled man. … 53. Thus in weighing the views of rival experts as to what is taught or what is obvious from what is taught, a judge should be careful to distinguish his views on the experts as to whether they are good witnesses or good teachers—good at answering the questions asked and not others, not argumentative and so on, from the more fundamental reasons for their opinions. Ultimately it is the latter which matter—are they reasons which would be perceived by the skilled man?”
“[a] A method for a User Equipment, UE, to receive control information through a Physical Downlink Control Channel, PDCCH, the method comprising: [b] receiving control information from a base station through the PDCCH in units of Control Channel Element, CCE, aggregations, each of the CCE aggregations including at least one CCE in a control region of subframe 'i'; and [c] decoding the received control information in units of search space at subframe 'i', characterized in that [d] the search space at subframe 'i' starts from a position given based on a variable xi and a modulo 'C' operation, wherein 'C' is a variable given by: C = floor(NCCE /LCCE), and wherein 'xi' is given by: xi = (A*xi-1 + B) mod D, wherein A, B and D are predetermined constants, and x-1 is initialized as an identifier of the UE, and NCCE represents the total number of CCEs at subframe 'i', and LCCE is the number of CCEs included in the CCE aggregation, and floor(x) is a largest integer that is equal to or less than x.” characterized in that and wherein 'xi' is given by: xi = (A*xi-1 + B) mod D, wherein A, B and D are predetermined constants, and x-1 is initialized as an identifier of the UE, and NCCE represents the total number of CCEs at subframe 'i', and LCCE is the number of CCEs included in the CCE aggregation, and floor(x) is a largest integer that is equal to or less than x.”
“The method according to claim 1 or 2, wherein D, A, and B are 65537, 39827, and 0, respectively.”
“Knuth notes that Hans Peter Luhn of IBM appears to have been the first to use the concept, in a memo dated January 1953, and that Robert Morris used the term in a survey paper in CACM which elevated the term from technical jargon to formal terminology.[4]”
“It may seem perverse to use a computer, that most precise and deterministic of all machines conceived by the human mind, to produce ‘random’ numbers. More than perverse, it may seem to be a conceptual impossibility. After all, any program produces output that is entirely predictable, hence not truly ‘random’. Nevertheless, practical computer ‘random number generators’ are in common use. We will leave it to philosophers of the computer age to resolve the paradox in a deep way (see e.g. Knuth [1] §3.5 for discussion and references). … The pragmatic point of view is thus that randomness is in the eye of the beholder (or programmer). What is random enough for one application may not be random enough for another. Still, one is not entirely adrift in a sea of incommensurable applications programs: There is an accepted list of statistical tests, some sensible and some merely enshrined by history, that on the whole do a very good job of ferreting out any nonrandomness that is likely to be detected by an applications program (in this case, yours). Good random number generators ought to pass all of these tests or at least the user had better be aware of any that they fail, so that he or she will be able to judge whether they are relevant to the case at hand. For references on this subject, the one to turn to first is Knuth [1]. Be cautious about any source earlier than about 1995, since the field progressed enormously in the following decade.”
“Uniform deviates are just random numbers that lie within a specified range … The state of the art for generating uniform deviates has advanced considerably in the last decade and now begins to resemble a mature field. … The greatest lurking danger for a user today is that many out-of-date and inferior methods remain in general use. Here are some traps to watch for: ● Never use a generator principally based on a linear congruential generator (LCG) or a multiplicative linear congruential generator (MLCG). We say more about this below. ● Never use a generator with a period less than ~ 2 64 ≈ 2 x 10 19, or any generator whose period is undisclosed. ● Never use a generator that warns against using its low-order bits as being completely random. That was good advice once, but it now indicates an obsolete algorithm (usually a LCG). … If all scientific papers whose results are in doubt because of one or more of the above traps were to disappear from library shelves, there would be a gap on each shelf about as big as your fist. You may also want to watch for indications that a generator is overengineered, and therefore wasteful of resources: ● Avoid generators that take more than (say) two dozen arithmetic or logical operations to generate a 64-bit integer or double precision floating result. ● Avoid using generators (over-)designed for serious cryptographic use. ● Avoid using generators with period > 10 100. You really will never need it, and, above some minimum bound, the period of a generator has little to do with its quality. Since we have told you what to avoid from the past, we should immediately follow with the received wisdom of the present: An acceptable random generator must combine at least two (ideally, unrelated) methods. The methods combined should evolve independently and share no state. The combination should be by simple operations that do not produce results less random than their operands. If you don’t want to read the rest of this section, then use the following code to generate all the uniform deviates you’ll ever need. This is our suspenders-and-belt, full-body-armor, never-any-doubt generator; and it also meets the above guidelines for avoiding wasteful, overengineered methods. …”
“The cross-examination of the respondents’ expert followed with customary skill the familiar ‘step by step’ course. I do not find it persuasive. Once an invention has been made it is generally possible to postulate a combination of steps by which the inventor might have arrived at the invention that he claims in his specification if he started from something that was already known. But it is only because the invention has been made and has proved successful that it is possible to postulate from what starting point and by what particular combination of steps the inventor could have arrived at his invention. It may be that taken in isolation none of the steps which it is now possible to postulate, if taken in isolation, appears to call for any inventive ingenuity. It is improbable that this reconstruction a posteriori represents the mental process by which the inventor in fact arrived at his invention, but, even if it were, inventive ingenuity lay in perceiving that the final result which it was the object of the inventor to achieve was attainable from the particular starting point and in his selection of the particular combination of steps which would lead to that result.”
“i) Verify whether the Ericsson function would provide ‘the desired properties’ and conclude that it would not. ii) Observe that the problem lay with the randomisation part of the Ericsson function (and not the mod C part). iii) Do a literature search to find another appropriate hashing/randomisation function. iv) Identify, ultimately from Knuth, LCGs as a good choice.”
“294. I accept Apple’s case. The problem with the Ericsson function would be identified readily and by routine analysis. It would be clear without invention that the mod C part of the function was all right and the Kx + L needed remedy. A literature search would readily throw up LCGs as the best known option and although they would be known to have limitations they would be regarded as adequate for the PDCCH task in hand. 295. The secondary evidence does not displace this conclusion and nor do the existence of other alternatives; in any event an LCG would be at the forefront of any list of options. 296. In reaching this conclusion I have borne very much in mind that Apple’s case involves a number of sequential steps. But I find that they represent systematic uninventive work and not the use of inappropriate hindsight.”
“Thus each value in claim 4 is at least an obvious value. Although I have had to explain my reasoning in a sequence of steps I am satisfied there is no improper salami-slicing. Each step flows into the next for logical and routine reasons. The choices are related in ways which support their combination being obvious. This is basically careful implementation work of the kind for which the notional skilled person is inherently well-equipped, and this was part of the case where I thought Prof Lozano’s advantage over Ms Dwyer was particularly striking. Claim 4 is obvious.”
“The skilled person would recognise that Ericsson was using mod C to get a number between 0 and C-1 and would consider that the obvious and natural way to achieve that end. They would also see that Ericsson is using K*x + L to generate a random number, seeking to select ‘big enough’ values for K and L to make the result random.”
“So, my Lord, a hashing function has two purposes. One is to map a big number of inputs down to a smaller number of outputs, so there is a squeezing process, and the other one is to randomise these mappings so that two very similar inputs do not get mapped to two very similar outputs to minimise confusions. So the mod C, the outer mod C, is doing the squeezing down part of the hashing, and it is a standard way of doing it. It has been used in 3GPP before. It had been proposed already many months before the priority date to do this squeezing down by Motorola, and it is actually in Ms. Dwyer’s report. So that is well understood, the squeezing down. The discussion here, and the work that was taking place, was around the randomisation part, the randomisation part. So the randomisation part here is K x+L, right, because the rest is the mod C which is doing the squeezing down, concentrating the many input into the few outputs. So randomisation is done by K x+L and is not doing a good job at that.”
“Well, like I said, the Skilled Person here is looking for something that randomises properly; that is it. That is all that is missing here. The rest is fine. The outputs are 0 to C-1 as they should be, so that part is functioning well. What is not functioning well is the randomisation part, so one would look to randomise things so you look at the book and see what it says about the number generators and pick an off-the-shelf solution.”
“225. I accept this and think that while the skilled person would certainly have to think about the overall effect of the whole function, it would stand out clearly that the mod C part had the object and effect for which Apple contends. It would not require insight to retain mod C if possible (there is a specific point about using mod C which interfaces with the issues on the specified claims and with which I deal below). 226. Ms Dwyer came close to accepting much of this. She accepted that mod C would be seen as having the ‘squeezing down’ effect to which I have referred. She said ‘I think people would look to change part of the equation, agreed, and the mod C does map the output to the range that is desired. So I think that if they were trying to keep it similar to the original format that is true.’ 227. I therefore accept Apple’s contention that an obvious route was to retain mod C, on the basis that it was adequately performing a well-understood and necessary task, and look to remedy the problem, apparent at this stage, with the Kx + L randomisation part.”
“210. Once the skilled person had verified that not all the desired properties are met [by the Ericsson function], they would look to replace K*x+L with a random number generator having the desired properties. 211. The skilled person would look for the random number generator in the literature, for instance, by turning to a standard reference text. …”
“230. Unsurprisingly, Counsel for Optis submitted that ‘could’ was not good enough. I agree that in itself it is not, but my task is to weigh the evidence of Prof Lozano who clearly said that is what the skilled person would do (there being other possibilities, of course, and I have to weigh that up as well), against the evidence of Ms Dwyer who would not go that far, although my sense at the time was that she was as close as may be to accepting ‘would’. 231. I prefer Prof Lozano’s evidence; I found him the more persuasive expert for reasons given in my overall assessment of the witnesses above. One sensible thing to do would be to look in the literature for an established and understood way to generate randomness. I think it would be the most natural way forward, and certainly one of the leading ones. It is the reliable, routine, systematic approach of the uninventive skilled person. 232. Prof Lozano was fair in putting this forward. He did not reject other options as being possible. Ms Dwyer’s idea of modifying x was not really explored with him, but he was asked about the possibility of varying K and/or L by subframe, the idea put to him being that it would create more decorrelation between subframes. Prof Lozano agreed that changing K and/or L this way was something that the skilled person might do, and indeed it was discussed in RAN1 ... 233. I do not think the existence of such other options makes it any less natural or obvious that the uninventive skilled person would look for an established RNG. …”
“The second [argument] was that it was unknown to use an RNG within a hashing function. … I reject the point because the Ericsson function itself, which is clearly a hashing function, while not explicitly expressing its teaching in terms of an RNG, used what the skilled person would recognise as a source of randomness (Kx + L), coupled with the mod C operation. It was also known, and taught in Knuth, to take only part of a large random number generated by an LCG by various means which included taking the least significant bits using the mod function, and this is essentially hashing. … ”
“ … it is not difficult to produce a pretty good imitation of random data, by using simple arithmetic as we have discussed in Chapter 3. And in fact we can often do even better, by exploiting the nonrandom properties of actual data to construct a hash function that leads to fewer collisions than truly random keys would produce. Consider, for example, [a hash function is described]. Experiments with actual data show, in fact, that this ‘middle square’ method isn’t bad, provided that the keys do not have a lot of leading or trailing zeros; but it turns out that there are safer and saner ways to proceed, just as we found in Chapter 3 that the middle square method is not an especially good random number generator. Extensive tests on typical files have shown that two major types of hash functions work quite well. One is based on division, and the other is based on multiplication. …”
“Never use a generator principally based on … LCG”. “An acceptable random generator must combine at least two (ideally, unrelated) methods.” “… the field’s long preoccupation with LCGs was somewhat misguided”
“252. Although initially very striking, I think the statements in NRC are of low relevance, at most, to the issue of obviousness in this case. I accept Prof Lozano’s evidence that what is under consideration in NRC is demanding situations where very long sequences of very random numbers are needed (‘very random’ in the sense that they pass extremely stringent tests intended to identify even the smallest signs of a pattern; an example was called ‘Diehard’). He was clear that sometimes sequences as long as 10 30 or 10 40 were needed, and that for cryptography sequences were needed and were produced that were ‘longer than the [age] of the universe measured in seconds’, but that that was ‘way beyond what anyone at RAN1 would even think about. At RAN1 we have never seen sequences of more than a few thousand or maybe tens of thousands of repetition of period.’ He said that the more sophisticated RNGs in NRC were ‘way beyond anything that is required in a mobile device’. 253. Accordingly I think the skilled person’s attitude to LCGs would be that they were well known, widely used for a long time, easy to implement and suitable for low power devices, but not of good enough randomness for demanding applications. …. 254. Bringing this understanding to bear on the problem presented by Ericsson, the skilled person would know that there were about 65,000 UEIDs that needed to be distributed randomly, and that that was vastly lower than the scales relevant to cryptography etc. The skilled person would readily understand that LCGs were unsuitable if very large sequences of very random numbers were needed, but that that was not the relevant requirement for the PDCCH. 255. Prof Lozano explained this cogently in his written and oral evidence. …”
“… it was clear from Prof Lozano’s evidence, accepted by Ms Dwyer and also supported by NRC and Knuth (and Wikipedia for what it is worth) that LCGs were very well known, had a long history, and were fast and easy to understand and implement.”
“222. …Apple’s position was that the skilled person would realise that the mod C part of the Ericsson function was there to “squeeze” the random output of the (K*x + L) part down from a large number to a range from 0 to C-1, that the mod C part was therefore necessary and was working all right, and that any change should therefore be to the random, (K*x + L) part.”
“They [the skilled person] would also see that Ericsson is using K*x+L to generate a random number, seeking to select “big enough” values for K and L to make the result random.”
“Accordingly I think the skilled person’s attitude to LCGs would be that they were well known, widely used for a long time, easy to implement and suitable for low power devices, but not of good enough randomness for demanding applications.”
“Mr Justice Meade: … You pointed us to 7.1.7 “When You Only Have 32-Bit Arithmetic”
“Mr Abrahams: So you are referring to, on page 186, it has “LCG 6 Modulo 232”; yes? A. Yes. Q. You see, in the description of this particular method, it says “can use as random: not recommended; can use in bit mix: not recommended.”
“Mr Abrahams: So I am right, am I not, that this book makes clear that you should never use an LCG outside of a combined generator; correct? A. No, later on that, as will be explained, LCGs and MLCGs can still be useful only in carefully controlled situations. Q. It makes clear that those carefully controlled situations are within a combined generator? A. Well, the thrust of these sections is on generating extremely long sequences as I explained yesterday, with periods there are many, many orders of magnitude above what anyone would need for RAN1. So anybody looking into solving the problem that we are discussing here would not be interested in this complicated generators, they would be looking for solutions, such as the ones given in Knuth.”
“It is now reasonable to expect to get “perfect” deviates in no more than a dozen or so arithmetic or logical operations per deviate, and fast, “good enough” deviates in many fewer operations than that.”
“So anybody looking into solving the problem that we are discussing here would not be interested in [these] complicated generators, they would be looking for solutions such as the ones given in Knuth.”