Cloud Cycle Limited v Verifi LLC & Anor [2024] EWHC 2001 (Ch)

[2024] EWHC 2001 (Ch)Case No IP-2023-000104
IN THE HIGH COURT OF JUSTICE
BUSINESS AND PROPERTY COURTS OF ENGLAND AND WALES
INTELLECTUAL PROPERTY LIST (ChD)
Intellectual property enterprise court
Venue The Rolls Building 7 Rolls Buildings London, EC4A 1NLDate 6 August 2024
Before
RECORDER DOUGLAS CAMPBELL KC(sitting as a High Court Judge)
Between
cloud cycle limitedClaimantverifi llcDefendantsgcp applied technologies (UK) limitedDefendant
Mr Richard Davis KC and Ms Becky Knott (instructed by Potter Clarkson LLP) appeared for ClaimantMr James Abrahams KC and Mr Edmund Eustace (instructed by Powell Gilbert LLP) appeared for DefendantsHearing Hearing dates: 11-12 July 2024
approved Judgment
RECORDER DOUGLAS CAMPBELL KC :

Introduction

[1]The issue in this trial is whether acts done by the Claimant (“Cloud Cycle”) in relation to a system for monitoring the properties of concrete in a concrete mixing truck infringe claim 1 of EP (UK) 1 720 689 (“the Patent”, or “EP 689”). I will explain more about the Patent in due course but essentially it relates to a method for calculating and reporting a property of concrete called “slump” in a concrete delivery truck. The Defendants (together “Verifi”) are the proprietor and exclusive licensee of the Patent and it is unnecessary to distinguish between them.[2]The action started as a declaration for non-infringement but it can now be treated as a conventional infringement action. It has two unusual features. First, there is no issue of validity. Secondly, there is no allegation of infringement upon a normal interpretation of claim 1. Instead, Verifi relies entirely on the infringement under the doctrine of equivalents, as explained by the Supreme Court in Actavis v Eli Lilly [2017] UKSC 48 (“Actavis”). When I refer to the Actavis questions in this judgment, I refer to such questions as later explained by the Court of Appeal in Icescape v Ice-World [2018] EWCA Civ 2219.[3]The proceedings commenced by claim form on 19 October 2023. The Defendants applied for an interim injunction on 8 January 2024. That application was dismissed on 7 February 2024 but the trial itself was expedited: see paragraph [7] of the Court’s Order of 31 January 2024. The case management conference was then heard before HHJ Hacon on 22 March 2024.[4]HHJ Hacon identified the following list of issues at the case management conference, which I have slightly amended: 1. What is the inventive concept of claim 1 of EP 689? 2. Does the Cloud Cycle System achieve substantially the same result in substantially the same way as the Claimant’s and/or Defendants’ inventive concept of claim 1? 3. Would it be obvious to the skilled person, reading EP 689 at the priority date, knowing that the Cloud Cycle System achieves substantially the same result as the Claimant’s and/or Defendants’ inventive concept of claim 1, that it does so in substantially the same way. 4. Would the skilled person reading EP 689 at the priority date have concluded that the patentee nonetheless intended that strict compliance with the literal meaning of claim 1, was an essential requirement of the invention.[5]Issues 2, 3, and 4 reflect the Actavis questions. Issue 1 is a necessary pre-cursor to issues 2 and 3. Most of the argument at trial was spent on issue 1.

The witnesses

[6]Both sides called 2 expert witnesses, pursuant to paragraph [9] of the case management conference order which permitted each side to call 1 expert witness in the field of civil engineering and 1 expert witness in the field of electronic engineering.[7]Cloud Cycle’s civil engineering expert was Nicholas Humpish. Mr Humpish’s original degree was in economics, but he had a great deal of hands on experience in the concrete mixing trade. He joined Hymix, a major UK manufacturer of concrete mixers, in 1988 and served as its managing director from 1994 until 2019. He was a good witness and plainly knew a great deal about his subject from a practical perspective.[8]Cloud Cycle’s electrical engineering expert was Professor Josef Kittler. He is currently Distinguished Professor at the University of Surrey working in the Centre for Vision, Speech, and Signal Processing. He did not claim to have any particular experience relating to the concrete industry but was instead relied upon for his expertise relating to signal processing, particularly that used in Cloud Cycle’s system. I am grateful to Professor Kittler for his assistance.[9]Verifi’s civil engineering expert was Professor Christopher Goodier, currently Professor at the School of Architectural, Building and Civil Engineering at Loughborough University. Professor Goodier was knowledgeable about concrete to a greater extent than the case actually required, but that is certainly not a criticism of his evidence. The Claimant submitted that Professor Goodier was “at times, evasive and was concentrating more on explaining how complicated everything was rather than attempting to simplify and explain matters to the court”. I reject both points. Professor Goodier was not being evasive at all, nor was he seeking deliberately to complicate matters.[10]Verifi’s electronic engineering expert was Mr John Holland. He has worked in a variety of engineering companies, most notably at Practicon Limited from 1997 to date. Practicon provides a variety of control systems to industry. In 2002 Mr Holland took on the role of Concrete Systems Manager and since then he has overseen all functions of Practicon’s concrete systems department. The Claimant accepted that Mr Holland was doing his best to assist the Court but submitted that he had not properly understood the claimed invention. I agree with both points, but I do not accept that the error (which Mr Holland himself accepted in cross-examination) was such as to taint the rest of his evidence. It also seemed to me that Mr Holland was not as knowledgeable about the concrete mixer industry as Mr Humpish was, but that is not a criticism of him as a witness either.

The skilled addressee

[11]There is no issue as to validity, so it is only necessary to consider the skilled addressee required for purposes of implementing the Patent.[12]It was not disputed that the Patent was addressed to a team comprising a civil engineer, with expertise in concrete technology, and an electronic engineer, with expertise in signal processing, hence why the parties called the witnesses identified above. I agree with Cloud Cycle that concentrating on the everyday workers using the system is too limited.

The common general knowledge

[13]I find that the common general knowledge at the priority date included the following. I have taken some parts of it from areas of Professor Goodier’s evidence which were not challenged.

Properties of concrete and concrete trucks

[14]Concrete consists of three essential components: cement, aggregates and water, although additional materials may be added as required. The proportions and grades of each component varies according to the desired specification and a wide range of specifications is possible.[15]The Patent relates to concrete delivered to a construction site in a drum mixer truck. This type of concrete is known as ready-mix concrete and is typically produced at concrete production plants, also known as batching plants. There are variants on the process, such as the wet-batching process whereby all of the constituent materials including water are mixed in a static mixer prior to loading on to the concrete truck, and the dry-batching process whereby each of the materials (including water) is added directly to the drum of the concrete truck itself. These variants do not matter for present purposes. What does matter is that the chemical reaction which leads the concrete to set and then harden begins as soon as water is added. The concrete must therefore be delivered from the batching plant to the construction site and poured within a short period (eg 2 hours) after such addition.[16]The drum of the concrete mixer is rotated when the concrete is being added, discharged, and throughout the delivery process. The drum agitation is necessary to prevent separation/segregation and settling and to maintain workability of the concrete prior to its use. Trucks are normally fitted with a pressurised water tank which can be used by the driver for cleaning the truck after discharge, and in some circumstances may be used to add more water to the concrete.[17]The above was all common general knowledge. The behaviour of concrete as a Bingham, or non-Newtonian, fluid, turns out to be complex, and was not shown to be common general knowledge.

Slump, and direct measurements thereof

[18]The accepted industry measure of the consistency or workability of concrete before it sets is known as slump. The name comes from the test used to measure this property, which at the priority date was specified in British Standard BS EN 12350-2:2000. Essentially the test involves filling a truncated cone, known as an Abrams cone, with fresh concrete, inverting it on a flat surface, lifting off the cone, and measuring the distance h by which the concrete slumps with a tape measure. There are more details, including aspects of sampling, but I do not need to describe them. The following diagram, taken from Professor Goodier’s Figure 3, shows how the measurement of h is done:[19]Slump can vary from 0mm to more than 200mm. The results are reported to the nearest 10mm, and so might be eg “50 slump”. The British standard divided measured slump into 5 classes S1-S5, where S1 was 10 to 40mm, and so on. Different specifications might require different values of h.[20]The measurement appears simple but it is easy to perform and it provides useful information. If h is too small, the concrete may not be sufficiently workable. If h is too large, the concrete may contain too much water and its hardened strength may be reduced further than is desirable.[21]Whether a slump test would be performed on the concrete delivered to a construction site would depend on the circumstances. Where quality was particularly important, such as public infrastructure products and high-rise buildings, a formal test would generally be conducted and the result recorded. For less sensitive applications such as a residential driveway, patio, or base for a shed, it might not be.

Ways of estimating slump at the priority date

[22]The gold standard way of measuring slump was as per the British Standard, as explained above. However it was often convenient to estimate slump at various stages of the process, for instance after it had been loaded on to the mixer truck but before delivery to the construction site. For instance if it was considered that the concrete contained too little water for the desired specification, then water (but not too much) could be added using the pressurised water tank referred to above.[23]It was not disputed that some concrete mixer drivers used various informal methods to guesstimate slump values based on their own experience. Mr Humpish referred to drivers listening to the sounds of the mixer drive line, Mr Holland referred to drivers estimating slump by listening to the sound of the concrete as it moved in the drum, and Professor Goodier referred to truck drivers looking at the behaviour of concrete. All of these are subjective measurements, not accurate ones.[24]There was initially some controversy about the extent to which (hydraulic) pressure gauges were used to estimate slump in a concrete mixing truck, but this was resolved during cross-examination.[25]Mr Humpish exhibited a Hymix concrete mixer manual dating from the late 1990s which had a section dealing with an optional “Slump Meter”. The slump meter used the drum speed and hydraulic oil pressure (ie of the drum motor) to provide an estimate of slump. Hydraulic pressure and torque are not the same thing, but there is a relationship between them which means that hydraulic pressure was often used as a proxy for measuring torque, which in turn made it possible to estimate slump. Later improvements in speed and direction controllers meant that it was not necessary to have a dedicated speed meter.[26]Mr Humpish also exhibited a more detailed document entitled “The Pressure Gauge Slump Meter” explaining that all readings should be taken at the same speed band, eg about 10 rpm. Mr Humpish explained that a driver would set the speed of the drum using the relevant controls, measure the hydraulic pressure using the gauge, and then mark a position on the gauge with a permanent marker or scratches to indicate a particular value of slump. He emphasised “the important thing was it was always the same speed”. In this way the pressure gauge was calibrated to estimate slump. This calibration was still a rough one but it was nevertheless commonly used. I accept this evidence.[27]There was some dispute as to whether different types of concrete would give different pressure measurements for the same slump when measured at the same drum speed. Mr Humpish told me this would not be the case, and he was not effectively challenged on that view given constraints of time. I do not need to resolve this.[28]Mr Holland was not aware of the particular documents exhibited by Mr Humpish, but then Mr Holland was not working in the concrete mixer truck industry. Mr Holland nevertheless accepted in cross-examination that almost every truck had a pressure meter on it which was used to give an indication of slump; that he was aware that marks were put on such gauges for such purpose; that the pressure was measured at a preset speed because speed is related to slump; and that if the drum was not operated at a preset speed, you would have to take speed into account, perhaps by calibrating it for different speeds. I accept this evidence.[29]Conversely there was no evidence suggesting that anyone ever tried to estimate slump using pressure readings at anything other than a constant speed. Indeed the evidence of both Mr Humpish and Mr Holland emphasised the need for using a constant speed, and that this was done because otherwise the results would be inaccurate.[30]In the light of the above I find that it was common general knowledge to estimate slump by using pressure readings obtained when the concrete mixer drum was rotating at a constant speed. Such estimates were more accurate than those obtained using the subjective methods, but were still somewhat crude.[31]The evidence did not establish that it was common general knowledge to use this method when the concrete mixer was in transit. Professor Goodier’s evidence that the pressure gauges were located on the exterior of the vehicle rather than in the driver’s cab, and that the pressure gauge was only used when the trucks were running at a higher mixing speed and thus stationary, was not challenged. Mr Humpish also accepted that a truck would have to be stationary to achieve a speed of 10 RPM.[32]Nor was it common general knowledge “to calculate slump electronically using values derived from sensors monitoring the driving force (torque) required to rotate the mixing drum containing the concrete” as alleged by the Claimant: see the Particulars of Claim at paragraph [12] and the Claimant’s Response to the Amended Statement of Case on Infringement at paragraph [7(4)(i)].[33]The main evidence in support of this allegation was Mr Humpish’s evidence that “there were at least 16 trucks on the road that did just that prior to 2004” . There was no reason to doubt Mr Humpish’s evidence about the 16 trucks, which was supported by his exhibit NJH-10, but neither of Verifi’s experts was aware of any electronic slump calculation at all being used at the priority date. Mr Humpish himself said that this product “was not marketed broadly”. Indeed in its closing submissions the Claimant seemed to accept that Mr Humpish’s evidence only went so far as showing that such devices were “out there”, not that they were common general knowledge. In my view that was a realistic assessment of this evidence. I note that this evidence might in principle have been used by the Claimant in an attack on validity, but the Claimant chose not to make any such attack.

Signal noise encountered when measuring mixer drum speed

[34]Mr Holland agreed with Professor Kittler’s evidence that the sensors used to measure mixer drum speed would pick up a signal consisting of a number of components, namely i. nominal value of a set drum speed; ii. variations from the nominal value due to truck dynamics, such as changes in vehicle speed or transmission shifting; iii. variations due to the nature of the mixing process; and iv. sensor measurement noise.

Signal change detection

[35]Verifi submitted that “the specific algorithm for stability used by the patent is a form of signal change detection and that was basic common general knowledge”, and that Professor Kittler accepted this. I do not agree. As Cloud Cycle submitted, this mischaracterises his evidence. All Professor Kittler accepted was that the Patent taught signal change detection, and that this general concept was part of the common general knowledge. He did not accept that “the specific algorithm for stability used by the patent”, whatever is meant by this, was common general knowledge. Verifi submitted that Mr Holland’s 2nd report, at paragraphs 11-13, provided further support for the same proposition but these paragraphs do not specifically address the algorithm for stability used by the Patent either. It does not appear to me that this argument was even pleaded in the first place, and I say no more about it.

The Patent

[36]I now come to the Patent. I will not attempt to set out each and every section of importance but will focus on those of most interest.[37]Paragraph [0001] sets out the field of the invention, as follows: [0001] The present invention generally relates to delivery vehicles and particularly to mobile concrete mixing trucks that mix and deliver concrete. More specifically, the present invention relates to the calculation and reporting of slump using sensors associated with a concrete truck.[38]The next section sets out the background of the invention. It explains problems which can arise due to adding either too much or too little water to the concrete in mixer trucks, notes that the slump of the mix in the barrel (ie the drum) is related to the driving force required to rotate the mixing barrel, and that sensors are used to determine the torque loading. Thus far there is nothing surprising, having regard to the common general knowledge.[39]Paragraph [0007] then says: [0007] Improvements related to sensing and determining slump are desirable.[40]Verifi submitted that this meant that the Patent was promising increased accuracy in terms of sensing and determining slumps. I do not see why this follows. More accurate methods would be desirable, but so would methods which were (for instance) quicker, cheaper, simpler, and/or more flexible. Paragraph [0007] is entirely general.[41]Cloud Cycle relied on paragraph [0008] as relating to measurements made while a vehicle was in transit, but since this paragraph has nothing to do with slump I do not rely on it.[42]Paragraph [0013] says: [0013] EP-A-0126573 discloses a method of and system for controlling the mixing of concrete. It discloses furthermore a system for calculating and reporting slump in a concrete delivery vehicle truck in accordance with the preamble of claim 1, where said system also includes means for inhibiting loading of the solid constituents until the speed of operation of the mixer has reached a pre-set value.[43]Despite the statement that EP-A-0126573 (“EP ‘573”) discloses a system in accordance with the preamble of claim 1, neither side took me to it. I found this surprising given the detailed argument as to the nature of the inventive concept of the Patent which I set out below, and the fact that Verifi’s solicitors gave EP ‘573 to Mr Holland so that he could give evidence about it, which he duly did. That evidence was not disputed by Cloud Cycle and I will summarise it as follows.[44]EP ‘573 is a patent application in the name of Ready Mix Concrete. It involves using a pressure sensor on the truck as part of a system which measures slump electronically for the purposes of adding an appropriate amount of water at the batching plant. The truck also has a drum speed sensor which is used to confirm that the drum has been spun up to a predetermined speed which is sufficiently fast for the constituents to be added.[45]Both from the terms of paragraph [0013] of the Patent, and from Mr Holland’s evidence, it will be seen that this system is similar in principle to the common general knowledge system which I have mentioned in paragraph [30] above.[46]I pass over the section of the Patent dealing with the Summary of the Invention since the wording is very similar to that used in the claim. The main section of the Patent is a very lengthy detailed description of the embodiments of the invention, containing lots of flow charts and block diagrams. It would be disproportionate to set out the entirety of this passage, which is in any event publicly available should any reader of this judgment require more detail. Before me, the main focus was on paragraphs [0051] and [0060]-[0061], which explain how the patented system works with particular reference to Figures 4C and 4D. I begin with paragraph [0051], which states in part as follows: [0051] Referring now to Fig. 4C, slump calculation management in step 114 can be explained. Some calculations will only proceed if the drum speed is stable. The drum speed may be unstable if the operator has increased the drum speed for mixing purposes, or if changes in the vehicle speed or transmission shifting has occurred recently. The drum speed must be stable and below a threshold maximum RPM for valid slump calculation to be generated. In step 170, therefore, the drum speed stability is evaluated, by analyzing stored drum rotation information collected as described below with reference to Fig. 4D. If the drum speed is stable, then in step 172 a slump calculation is made. Slump calculations in step 172 are performed utilizing an empirically generated lookup table identifying concrete slump as a function of measured hydraulic pressure of the drum drive motor and drum rotational speed...[47]` Thus the emphasis is that the drum speed may be unstable during a transition period, examples of which are given; that the drum speed must be stable (and below a threshold) for valid slump calculation; that hydraulic pressure of the drum drive motor and drum rotational speed are the input variables to the calculations; and that an empirically generated lookup table is used to provide the actual estimate of slump. No further details are given in the Patent about this lookup table, save that new slump lookup tables could be downloaded: see paragraph [0040]. Yet clearly such tables must be important if accurate slump measurements are to be obtained. Mr Holland agreed that the Patent was only populating its table from empirically observed results, and that the Patent did not give a more accurate result than what was put into the empirical table.[48]Paragraphs [0060]-[0061] are in part as follows: [0060] After the steps noted above, drum management proceeds to step 214, in which the drum speed stability is evaluated. In step 214, it is determined whether the pressure and speed of the drum hydraulic motor have been measured for a full drum rotation. If so, then in step 215 a flag is set indicating that the current rotation speed is stable…. [0061] If in step 214 pressure and speed have not been measured for a full rotation of the drum, then in step 227 the current pressure and speed measurements are compared to stored pressure and speed measurements for the current drum rotation, to determine if pressure and speed are stable. If the pressure and speed are stable, then the current speed and pressure readings are stored in the history (step 229) such that pressure and speed readings will continue to accumulate until a full drum rotation has been completed. If, however, the current drum pressure and speed measurements are not stable as compared to prior measurements for the same drum rotation, then the drum rotation speed or pressure are not stable, and in step 230 the stored pressure and speed measurements are erased, and the current reading is stored, so that the current reading may be compared to future readings to attempt to accumulate a new full drum rotation of pressure and speed measurements that are stable and usable for a slump measurement. It has been found that accurate slump measurement is not only dependent upon rotation speed as well as pressure, but that stable drum speed is needed for slump measurement accuracy. Thus, the steps in Fig. 4D maintain accuracy of measurement.”[49]Thus the emphasis is again on ensuring that the drum rotation speed is stable, and if so then a flag is set. Paragraph [0061] explains that stability is determined by comparing current pressure and speed measurement to stored (ie prior) measurements, and erasing the stored measurements in favour of the current measurements if the comparison shows that the current measurements are not stable. The “finding” that accurate slump measurement is not only dependent upon rotation speed as well as pressure, but that stable drum speed is needed for slump measurement accuracy, is only stating what was already known from the common general knowledge. Such “finding” is also consistent with the Patent’s description of EP ‘573 and Mr Holland’s evidence about that.[50]The final sentence is not the full story since it ignores the importance of the lookup table, but it is still true to say that the steps in Figure 4D enable accuracy of measurement since they ensure that the drum speed is stable. I was also told by Cloud Cycle, without objection by Verifi, that the only relevant reference to slump measurement accuracy in the Patent was in this description of Figure 4D: note the “thus” in the final sentence above.

Claim 1

[51]I now, finally, come to claim 1. Verifi prepared a helpful claim breakdown, as follows: A A system (10) for calculating and reporting slump in a concrete delivery truck (12) having a concrete mixing drum (14) and hydraulic drive (16) for rotating the mixing drum, the system (10) comprising B a rotational sensor (20) mounted to the mixing drum (14) and configured to sense a rotational speed of the mixing drum (14), C1 a hydraulic sensor (22) coupled to the hydraulic drive and configured to sense a hydraulic pressure required to turn the mixing drum (14), C2 and a processor (24) computing a slump value using the sensed hydraulic pressure required to turn the mixing drum from the hydraulic sensor (22), characterized in that the processor (24) is operative to D(i) compare current pressure and speed measurements to previously stored pressure and speed measurements,(ii) determine if the speed and pressure are stable,(iii) erase the stored pressure and speed measurements if the speed and pressure are not stable,(iv) store the current pressure and speed measurements, E1 continue said steps (i) to (iv) until pressure and speed measurements have been stored for a full drum rotation E2 and then calculate a current slump valve using the stored pressure and speed measurements[52]There was no issue of infringement upon the normal interpretation of claim 1 and it turned out that there were no material disputes about the construction of the terms used in claim 1 either. Before going on to consider the inventive concept of claim 1, I will remind myself of the relevant legal principles applicable thereto.

Legal context

[53]It has long been the law that a patent has to be construed without reference to the infringement, “as if we had to construe it before the Defendant was born”: see Lord Esher MR in Nobel v Anderson (1894) 11 RPC 519 at 523, cited by Jacob LJ in Technip France SA’s Patent at [2004] RPC 46. I see no reason why the approach to identifying the inventive concept of a claim should be any different.[54]Before Actavis the term “inventive concept” had previously been used in the context of the Court’s approach to obviousness (see Pozzoli v BDMO [2007] FSR 37, [2007] EWCA Civ 588). For instance in Pozzoli itself, Jacob LJ explained that identifying the inventive concept of the claim in question meant identifying the essence of the claim, stripping out unnecessary verbiage: see ibid at [17]-[18].[55]There was some dispute before me as to whether the same term meant different things in the context of validity and infringement. Cloud Cycle said not, Verifi said there was a “subtle difference”.[56]In this context it should be noted that Pozzoli dates from a time before it was realised that a doctrine of equivalents existed in UK patent law. It was not yet appreciated that, as Lord Neuberger observed in Actavis in the context of the third Actavis question, “the fact that the language of the claim does not on any sensible reading cover the variant is certainly not enough to justify holding that the patentee does not satisfy the third question”: see ibid at [65].[57]That said, in Icescape the Court of Appeal identified the inventive concept using an approach which is essentially that of Jacob LJ. At paragraph [72] Kitchin LJ (as he then was) identified what he called the “the patent’s inventive core” and disregarded parts of the claim which did not matter. The reason they did not matter was because they were common general knowledge, but I do not read his judgment as saying that this is the only possible reason why integers might not matter. Floyd LJ agreed with Kitchin LJ in relation to infringement (see [91]) and added as follows, my emphasis:
“96. It is now clear from the Supreme Court’s decision in Actavis that purposive construction forms but the first stage in the determination of the scope of protection conferred by the claims. In a sense, the first extreme referred to in Article 1 of the Protocol has been replaced by purposive construction, because it now represents the minimum protection afforded by the patent. There is a second, non-interpretative exercise which allows the patentee a degree of protection outside the normal, purposive meaning of the claims where the variant from the claim achieves substantially the same effect in substantially the same way. 97. It should not be thought, however, that the claims do not continue to have an important function. It is variants from the claim which have to achieve substantially the same effect in substantially same way as the invention. The claims remain the starting point for the subsequent analysis of variants. Although we may have edged closer to it, the new approach does not transgress the second of the outlawed approaches in the Protocol, which treats the claim merely as a somewhat vague guideline.”
Longmore LJ agreed with both judgments.[58]Thus the correct approach is to start with the claim and identify its inventive core. It is that core which then represents the inventive concept for the purpose of the Actavis questions. As will be apparent from the next section, both sides argued the case before me on this basis. I shall apply that approach.[59]For purposes of identifying the inventive core it was common ground that the two-part structure of the claim (which is used as per Rule 43 of the Implementing Regulations of the EPC) is a relevant consideration: see Meade QC (as he then was) in Fisher & Paykel v Resmed [2017] EWHC 2748 at paragraph [86]. However this is not the be-all and end-all, as Icescape, which was decided after Fisher & Paykel,makes clear. In Icescape the inventive concept was found in the pre-characterising portion.

What is the inventive concept of claim 1?

[60]The parties set out their respective submissions as to the inventive concept in writing. Cloud Cycle’s submission (as per paragraph 5(a) of its Response to the Amended Statement of Case on Infringement) was as follows:
“In the context of a system having the features of integers A – C, to verify that successive speed and pressure measurements are stable (meaning smooth, lacking excessive noise or significant disturbances i.e., substantially constant) before using them for slump calculation. The values need to be substantially stable over one full drum rotation before they can be considered accurate. This process involves comparing current and previous (stored) measurements and if they are not stable erasing the previous measurements and starting again with the current ones.”
[61]It will be seen that Cloud Cycle’s submission has two distinct aspects. One is about evaluating stability of speed and pressure measurements before using them for slump calculation (“stability evaluation”), and the other is about consistency of speed/pressure measurement over one full drum rotation (“full drum rotation”). These features are derived from integers D and E1 respectively.[62]Verifi’s submission (as per paragraph 5(a) of its Amended Statement of Case on Infringement) was as follows:
“The inventive concept of claim 1 of EP 689 is that, in the context of a system having the features of integers A – C, stable pressure and stable drum speed measurements (‘stable’ referring in both cases to signal ‘smoothness’ i.e. lack of excessive noise or significant disturbances) are used to determine a more accurate slump value.”
[63]It will be seen that very little of integers D or E1 has survived in Verifi’s formulation except for the references to “stable” pressure and speed measurements. This is despite counsel for Verifi’s submission that D and E1 were “absolutely not common general knowledge, absolutely new … I fully accept that D and E1 contain inventive contribution”. Conversely, Verifi has introduced the phrase “more accurate”.[64]Both sides accepted the principle that benefits which are only present in some embodiments could not be relied upon in support of the inventive concept. Both nevertheless went on to make submissions as follows.[65]Cloud Cycle argued that of the 4 possible signal noise components, the Patent was only concerned about truck dynamic variations. While it is true that the second sentence of paragraph [0051] mentions reasons for lack of stability falling within this category, I agree with Verifi that the claim is not so limited and nor is the inventive concept. There was no technical basis for this argument either, since the Patent can deal with instability due to any of these sources.[66]Verifi argued that the invention of claim 1 enabled reliable slump calculations to be made while the truck is in transit. I agree with Cloud Cycle that the claim is not limited to a truck in transit, nor for that matter is the claim limited to using any particular drum speeds (eg to those drum speeds typically used during transit). For instance there is no threshold RPM in the claim, nor are there any requirements about the relationship between speeds (eg how much faster one speed has to be than the other). In addition the operator might choose to adjust the speed for mixing purposes when the vehicle was stationary (eg either at the loading or unloading end).[67]Cloud Cycle also submitted, without objection from Verifi, that claim 2 depended on claim 1, yet claim 2 made it clear that slump calculation is not just applicable when the truck is in transit.[68]Verifi submitted that its claim used both a rotational sensor and a hydraulic sensor to calculate a current slump value. I agree with Cloud Cycle that reliable slump calculations require a reliable lookup table, which is not claimed or even disclosed. Integer E2 does refer to calculating a current slump value using the stored pressure and speed measurements but without such a lookup table, or some unclaimed and undisclosed equivalent thereto, the claimed system is no more reliable or accurate than the prior art. In addition prior art methods used pressure at a given speed to give an indication of slump, as explained above, so such methods required both pressure and speed to be known. It was only the older prior art methods which actually required a specific rotational sensor to measure speed.[69]Another of Verifi’s arguments was that the claimed system could be calibrated for different mixes of concrete. So it could, but the claim is not limited to different mixes and the user still needs to perform such calibration since the Patent offers no assistance with this.[70]Verifi submitted that the Patent enabled further automation such as the addition of water while the truck was being driven. However the claim has nothing about this either. In addition prior art trucks were fitted with pressurised water for, among other things, this very purpose.[71]I return to paragraphs [0051] and [0060]-[0061] of the Patent since I am in no doubt that claim 1 was written around them. The skilled reader would understand from these paragraphs that slump calculations, in the context of a system having the features of integers A-C, are to be performed according to the following steps: a) compare the current pressure and speed measurements to previously stored values thereof; b) determine if the speed and pressure are stable c) do not use the stored values if the speed and pressure are not stable, d) store the current pressure and speed measurements e) repeat steps (a) to (d) until the system has been stable for long enough that a calculation can be performed f) and then calculate a current slump value using the stored pressure and speed measurements.[72]In my view the inventive core, and hence the inventive concept, is as set out above. The Patent thus differs from the common general knowledge of the prior art in that it measures different values of speed and pressure, rather than by measuring pressure at a known speed, but its calculations are still based on stable values of speed and pressure. The Patent then still relies on empirical data which has been obtained from somewhere, as did the prior art.[73]It will be noted that I have essentially incorporated claim features D(i), (ii), (iv), part of E1, and E2, but I have departed from the literal wording, and the normal interpretation, of the claim in two respects. The fact of such departure is not surprising – indeed, it is inevitable - given that the whole purpose of the doctrine of equivalents is to go beyond such normal interpretation.[74]My first departure is as regards the requirement in D(iii) to “erase” the stored measurements if the speed and pressure are not stable. I do not consider that erasing such measurements is part of the inventive concept, although it is certainly discussed in the relevant passages of the Patent, since it is sufficient that such measurements are merely not used. The reference to erasing would most likely be understood as a reference to the practical constraints on information storage at the priority date.[75]My second departure is as regards “full drum rotation”. It is true that storing the measurements for a full drum rotation could in principle remove the effects of any rotational asymmetry, which Cloud Cycle called “mixing variation noise”. Mr Holland agreed with this. However Cloud Cycle were also at pains to point out that the Patent’s approach to evaluating stability would not work for addressing mixing variation noise, and that mixing variation noise was not mentioned in the Patent at all. In any event it does not seem to me to matter to the inventive concept whether the pressure and speed measurements have been stored for a full drum rotation. Nor does it matter that the system sets a flag for a full drum rotation. What does matter is that there must be sufficient stability for a long enough time that a calculation can be performed, which is then performed as per integer E2. This means that the inventive concept has a fuzzy boundary, but so does the claim itself: consider the scope of the word “stable”.[76]However I will also consider an alternative possibility for (e), namely that the inventive concept instead requires “repeat steps (a) to (d) until pressure and speed measurements have been stored for a full drum rotation”.[77]It will be apparent that I have not adopted either side’s formulation of the inventive concept although my view is closer to that put forward by Cloud Cycle. Verifi’s construction ignores virtually all the details of paragraphs [0051] and [0060]-[0061] and puts the inventive concept of the Patent at too high and too abstract a level having regard to the Patent’s teaching. Does the Cloud Cycle System achieve substantially the same result in substantially the same way as the inventive concept of claim 1?[78]I will use the inventive concept I have identified, rather than those identified by the parties, in answering this question and the next. First I need to explain how the Cloud Cycle System works.[79]Cloud Cycle served a Product and Process Description which went through a number of increasingly elaborate versions. The end result was a complicated document which contained (in Cloud Cycle’s words) “vastly more detail than is necessary” and which was further explained by Professor Kittler. I will explain the key points as best I can without disclosing any confidential information.[80]The Cloud Cycle System has two parts, the first being on a conventional concrete mixing truck and the second being on a data cloud.[81]Two measurements are taken on the truck:(1) The first measurement is from an accelerometer attached to the drum. The on-truck processing does three things with the accelerometer input. First, it calculates a drum speed measurement. Secondly, it filters that measurement: the details of the filtering do not matter, but the effect is that the filter smooths and average the measurements over a period of 20 seconds. Thirdly, it causes a time delay.(2) The second measurement is from two pressure sensors, the difference between which give a value indicative of the driving torque. The measurement from each pressure sensor is input into a “sliding window averager”. This averager likewise filters the output data, the effect of which is that the measurements are smoothed and averaged over a period of 20 seconds. An averager will induce a time delay, hence why the drum speed measurement was subject to a matching delay.[82]I should explain that the term “sliding window” is used in this context to refer to a set of samples consisting of a time series, whereby the oldest sample in the series is discarded as each new sample is obtained. The average is calculated across the set of samples currently within the “window”.[83]The drum rotation is often 3 RPM or more in use, and a rate of 3 RPM is equivalent to saying that a full drum revolution takes 20 seconds. Since the Cloud Cycle System averages over a window of 20 seconds, it follows that the Cloud Cycle System will often operate over a time window which in fact comprises a whole drum rotation even though this is not specifically intended.[84]Pairs of drum speed and differential pressure data are output from their respective filters once every 10 seconds, at which point they are transmitted from the truck to the cloud.[85]Processing is conducted in the cloud using a ‘slump prediction model’. The precise details of this are confidential but are not necessary for purposes of this explanation. In general terms the data is fitted into a linear regression (i.e. a straight line model) of drum speed against torque from which slump can be calculated. Since this is a straight line model it needs multiple (differing) speed/pressure value pairs as a straight line cannot be defined from a single pair of values. For a linear regression, the more and/or better spread pairs the better.[86]I now turn to the first Actavis question. It will be apparent that this method does not operate as per any of my steps (b), (c), or (e) of the inventive concept. On the contrary, all measurements of speed and pressure are used at all times regardless of stability and/or for how long the system has been stable. It follows that the Cloud Cycle System does not achieve substantially the same result in substantially the same way as the inventive concept of claim 1. The answer to the first Actavis question is no, and the infringement case stops there.[87]This conclusion is reinforced by some evidence of Professor Kittler where he took the differences between the Patent and the Cloud Cycle System to the extreme. He explained that if disruptive factors were continuously present (e.g. due to the vehicle speed changing constantly while driving through traffic), then the method of the Patent would never be able to produce a useful slump measurement, while the Cloud Cycle System would function reliably. On the contrary, if the drum speed and pressure measurements were always constant then the Cloud Cycle System would fail to estimate the slump, whereas the method claimed in the Patent would function perfectly. Mr Holland agreed with Professor Kittler’s logic. Mr Holland also pointed out (as was common ground) that the extremes were unlikely to happen in the real world, but that makes no difference to the argument.[88]The fact that the Cloud Cycle System will often operate over a time window which comprises a whole drum rotation means that nothing turns on whether the alternative possibility for (e) is correct. In particular, if the inventive concept does include this alternative possibility for (e) rather than the version which I set out above, then the Cloud Cycle System still achieves (or at least, will often achieve) that part of the inventive concept and so it is not a difference at all.[89]Cloud Cycle had additional arguments on this issue, such as its argument that smoothing and erasure were different. On my construction of the inventive concept, this argument does not arise and it is not necessary to consider it in any detail. It is not strictly necessary to consider the second and third Actavis questions either, but I will do so since more time was spent on them and the case may go further. Would it be obvious to the skilled person, reading EP 689 at the priority date, knowing that the Cloud Cycle System achieves substantially the same result as the inventive concept of claim 1, that it does so in substantially the same way?[90]As pointed out by Arnold LJ in Fibrogen v Akebia [2020] EWHC 866 (Pat), [2020] RPC 15 at [446] the way in which the Supreme Court has formulated this question means that there will rarely be scope for the answer to the “no” if the answer to the first Actavis question is “yes”. I am not aware of any case in which that has happened, and neither was either side’s counsel.[91]One possibility is where the way in which the alleged infringement actually works is a mystery. For instance in a biological system it might not be obvious that the relevant binding site was the same for both the patented molecule and the infringing molecule. Cloud Cycle submitted that this was also true in the present case. In particular Cloud Cycle submitted that to the skilled addressee reading the Patent it was a mystery how Cloud Cycle’s system worked. There did seem to be some force in this submission, but Cloud Cycle did not do enough to persuade me that the difficulties were as great as they submitted. They wisely focussed on their better arguments instead, and are to be commended for doing so.[92]I conclude that if the answer to the first Actavis question had been “yes” then so would the answer to the second Actavis question. Would the skilled person reading EP 689 at the priority date have concluded that the patentee nonetheless intended that strict compliance with the literal meaning of claim 1, was an essential requirement of the invention?[93]In Fibrogen v Akebia [2020] EWHC 866 (Pat), [2020] RPC 15, Arnold LJ gave no fewer than 8 reasons on the facts as to why strict compliance would have been taken to be intended: see [449]-[460]. One of these was the “disclosed but not claimed” principle which is well-established in German law: see ibid at [454]. This principle has been considered in a number of subsequent cases, such as Facebook Ireland v Voxer [2021] EWHC 1377 (Pat); Shenzhen Carku v Noco [2022] EWHC 2034 (Pat); Philip Morris v Nicoventures [2023] EWHC 2616 (Pat). Another was the prosecution history: see [459].[94]In this case, Cloud Cycle’s main case was based on the arguments which I have already accepted in relation to the first Actavis question. They have therefore served their purpose. If, however, I had rejected these arguments in relation to the first Actavis question I cannot see why I would have gone on to accept the same arguments in relation to the third Actavis question.[95]Cloud Cycle also submitted that there was a squeeze on insufficiency, such that unless the claim was confined to its strict literal meaning it would be insufficient. I agree with Verifi that the evidence came nowhere near establishing the alleged insufficiency.[96]Finally Cloud Cycle sought to rely on the prosecution history, or rather from a single letter dated 24 June 2016 drawn therefrom. I agree with Verifi that neither of the two conditions identified by Lord Neuberger in Actavis at [88] were shown to apply in this case, and nor was it fair to rely on a single letter from the file absent its context. I place no reliance on the letter.[97]I conclude that if the answer to the first and second Actavis questions had been “yes” and “yes”, then the answer to the third Actavis question would have been “no”. Put another way, if I am wrong thus far then I can see no grounds on which strict compliance would have been intended.

Conclusion

[98]The answer to the first Actavis question is “no”, hence there is no infringement under the doctrine of equivalents. It was not necessary to go further, although I have done so.[99]In Fibrogen, Arnold LJ concluded his assessment of infringement under the doctrine of equivalents by cross-checking his conclusion with the Protocol on the Interpretation of Article 69 of the European Patent Convention: see [461]. I will do likewise. In my judgment, extending the scope of protection of claim 1 of the Patent in this case in the manner contended by Verifi would also go well beyond fair protection for the patentee and would not afford a reasonable degree of certainty for third parties. This confirms my conclusion.[100]I will therefore grant Cloud Cycle the declaration sought. I will hear counsel on the precise form of order I should make.