Abbott Diabetes Care Inc & Ors v Dexcom Incorporated & Ors

executing, on a receiver unit (104, 106), a predetermined routine associated with an operation of an analyte monitoring device (1010);

The STS Guide is directed towards an analyte monitoring device. There are numerous routines disclosed but Dexcom focus on the measurement of the 3-day sensor session period. So the PDR is the routine which counts down to the expiry of the 3-day sensor session.

detecting a predefined alarm condition associated with the analyte monitoring device (1020);

The predefined alarm condition is the impending STS Sensor expiration. There is no question that this is one associated with the analyte monitoring device.

outputting, to a user interface of the receiver unit, a first indication associated with the detected predefined alarm condition during the execution of the predetermined routine (1030); and

The first indication is the 30-minute sensor expiry warning vibration.

outputting, to the user interface of the receiver unit, a second indication associated with the detected predefined alarm condition (1040);

wherein the second indication is output after the completion of the execution of the predetermined routine;

When the sensor session ends, a second indication is provided in the form of a 0 Hour notification.

the predetermined routine is executed without interruption during the outputting of the first indication;

The sensor session continues without interruption during the provision of the first indication.

the first indication includes a temporary indicator and,

The 30-minute warning vibration is temporary.

further, the second indication includes a predetermined alarm associated with the detected predefined alarm condition; and

On the basis that the predetermined alarm condition is the STS Sensor expiration both first and second indications relate to the same issue.

the predetermined routine includes one or more processes that interface with the user interface of the receiver unit.

It is self-evident that the PDR includes processes which interface with the user interface of the receiver unit. The user interface is both visual (on the screen) and tactile (the vibration) and amongst the relevant processes are the visual and tactile notifications.

I can deal with Abbott’s arguments relatively succinctly, because, on analysis, they resolve to issues of interpretation of claim 1, which I have dealt with and rejected above.

First, Abbott submit that the 3-day sensor session period is not a PDR, as I understood matters, for two reasons: first, because it is not something which the user can choose to begin or end but its countdown to expiry continues regardless of the user’s actions. They say this is nothing like reviewing historical glucose data or configuration of device settings. Abbott’s second argument is to the effect that the 3-day sensor session period counter does not interface with the user interface: but it does, via the four alerts. These arguments carry no weight at all. As I have held, the expression ‘predefined routine’ is deliberately broad. I find the 3-day sensor session falls within the meaning of that term.

Second, Abbott argue that each of the alerts takes over the entire screen and requires acknowledgement by the user to clear the screen. I think this argument depends on Abbott’s construction arguments that the first indication must be unobtrusive and the second more permanent. I have rejected both arguments. In any event, there is nothing in this second point.

Third, Abbott argue that each of the alerts relates to a different alarm condition – different times until expiry. This argument misunderstands the alarm condition on which Dexcom rely, which is sensor expiry. Abbott’s further argument is that at each alert, the sensor is in a different condition. But this again confuses the status of the sensor with the predefined alarm condition, which is sensor expiry.

Accordingly, for the reasons explained by reference to Dexcom’s case above, I find that EP627 lacks novelty over the STS Guide.

In relation to Bunte, Abbott reminded me that while the skilled person is deemed to read the prior art with interest, they are not deemed to read it with any notion that it may be of any relevance or utility to their work, and that is particularly so when the prior art is located in a distant and unrelated field. See Inhale v Quadrant [2002] RPC 21, [47] (Laddie J):

Bunte is a patent application from 2006 entitled ‘Method and Device for inhibiting interruption of a running application by an event’. Its abstract describes it as: “A methodology implementable in form of a hardware or software module for inhibiting interruption of a running application by an event according to a selected non-disturbance profile, said event occurring on a mobile device”. It describes the operation of various “Do Not Disturb Modes” (‘DDM’) for use on, for example, a mobile phone.

Dexcom summarised the disclosure of Bunte in the following way. Prof Oliver drew attention to Bunte’s identification of the state of the art it was addressing from line 26:

‘According to the state of the art, a mobile device interrupts or pauses a running application if an incoming call for instance occurs. This is done by a pop-up message or similar and the user has to handle said pop up message for continuing using of said application. There is no possibility to set up a "do not disturb" behavior (or mode) within the running application which makes it possible to run said application without interruption.’

Bunte then goes on to explain that if, for example, you are gaming on your phone the only way to stop an incoming call interrupting your game is to switch off the telecom connection, which may not be possible if, for example, you need to connect to a game server while playing. Bunte aims to solve this sort of problem:

“it is an object of the present invention to ensure proper continuation of running applications, especially games, even in case of incoming events.”

Bunte’s solution is to first detect an incoming event, check to see if a non-disturbance profile has been set and then interfere with the already running program according to the instructions given in the non-disturbance profile.

‘In a first operation detecting of an occurrence of said event is provided. Afterwards, a determining if said non-disturbance profile has been set is provided. Then, inhibiting interruption of said running application according to said determined non-disturbance profile follows.’

Bunte doesn’t just stop the incoming event taking over. It provides a “secondary indication” that doesn’t interrupt the running program (Bunte uses ‘intermitting’ in the sense of pausing):

“…said inhibiting is accompanied by a secondary indication without intermitting execution of said application if said non-disturbance profile is set. Thereby, a secondary indication to the user is provided, wherein said user realizes the occurrence of an event even if the application is not intermitted. The secondary indication may be in form of an audio notification for instance.

Bunte gives the example of an incoming MMS as the incoming event. It suggests that, in one scenario where CPU performance is at a premium, the MMS may not be fetched until after the running application is quit or paused:

‘According to another embodiment of the present invention, said MMS is not fetched while said application is active and said non-disturbance profile is set. Because of the CPU performance increasing while fetching an MMS, it is preferred that said SMS is fetched later after quitting or pausing the foreground application.^’

Prof Oliver compared the disclosure of Bunte to EP627. In his view, all the integers of EP627 claim 1 bar disclosure in relation to analyte monitoring devices is to be found in Bunte.

Dr Palerm read Bunte more restrictively. Although he accepted that the ‘secondary indication’ during DDM mode in Bunte was a first indication in the EP627 sense, he took the view that Bunte only disclosed two mutually exclusive options: either the secondary notification is provided to the user during DDM mode or the notification is suppressed entirely and a list of the supressed notifications is only provided to the user once the DDM mode has ended.

Dexcom submitted Dr Palerm was simply wrong on this point. Dexcom drew attention to the teaching in Bunte where the secondary indication concerns an MMS, but the message itself is not fetched until after the DDM mode has ended, to save impact on the GPRS bandwidth and the processing power of the device. I agree with Dexcom on this issue. Dr Palerm was reading Bunte too restrictively. There is a potential further point that simply fetching the message and putting it on screen is not a second indication, but, even assuming that was what was contemplated in Bunte, it would have been entirely obvious to present a banner notification (possibly one of several) of the message which would then have to be selected to be opened.

On this basis, the big issue on Bunte resolves to whether the unimaginative Skilled Team would, having read and considered Bunte, think it had application to the environment they were considering – the operation of an analyte monitoring system.

I have considered the arguments from both sides carefully on this central issue. However, I have reached the clear conclusion that Bunte can only be seen as applicable with a good dose of hindsight. This is because there is one fundamental point of distinction between what is disclosed in Bunte and the method in claim 1 of EP627.

EP627 involves the inter-relationship between one aspect of an analyte monitoring device (the PDR) with another aspect of the analyte monitoring device (the ‘alarm condition’ of integer 1.2). Both aspects are ‘associated with an/the analyte monitoring device’.

Bunte is concerned with suppressing notifications from one application (e.g. MMS/SMS messaging) in favour of a completely unrelated application (e.g. a game).

In this regard, it is notable that Bunte was introduced into the claim at a relatively late stage and well after Professor Oliver had seen and considered EP627.

I am inclined to conclude that Professor Oliver did not notice this distinction at all. In his first expert report, his reasoning was relatively brief:

‘Although this predetermined routine in Bunte is not associated with the operation of an analyte monitoring device, I believe the Skilled Engineer would have no problem with applying the concept of Bunte to analyte monitoring devices. Indeed, it appears to me that the concept of Bunte is the same as that of EP 627 (as far as I have understood it): both involve notifying the user (in a temporary manner) of an event without interrupting a routine or while a program is running. When the routine or program has ended, the user is then notified of the event again (in a more permanent manner).’

Abbott had further points of distinction between Bunte and EP627, also related to that fundamental distinction. For example, they contended that Bunte would be implemented in the operating system software of the device and therefore its teaching was directed at a person responsible for producing operating system software for mobile devices. I think this submission confuses EP627 with the alleged infringement. EP627 is written around a dedicated analyte monitoring system, although it is capable of reading onto an analyte monitoring system operating on a mobile phone. I consider a person writing software for a dedicated analyte monitoring device would have to have the ability to write elements of the operating system. He or she would not set Bunte on one side as of no interest on this ground.

Dr Palerm was unshaken in his view that the skilled team in 2007 would have seen nothing of interest in Bunte.Abbott also submitted that ultimately Prof Oliver did not really maintain his view. At the end of his cross-examination, he was asked to consider Palerm 1 ¶15.16, which said:

‘Furthermore, the DDM in Bunte is focused on the core functionality of a mobile phone, not interrupting a specific application. In that context, the DDM in Bunte suppresses incoming events from outside the application, such that the application in question (e.g., the gaming app) is not interrupted by those incoming events. As I mentioned in paragraph 7.42, at the priority date, the EP 627 Skilled Team would have contemplated that the receiver for a CGM would be a dedicated device only used to convey clinically important information to the patient about their glucose levels. It would, therefore, not be obvious to consider implementing the idea of Bunte in that context, namely in a dedicated receiver specifically designed to convey actual or potential safety critical information to the user. The same applies to claim 5.’

Prof Oliver was twice asked to consider that summary and identify whether there was anything that he disagreed with. As Abbott submitted, on neither occasion was he able to identify any points of substance.

The re-examination on the point was leading. Professor Oliver was specifically directed to the concluding statement and asked to consider “what he thought was unreasonable”. He was only able to say that Bunte “can be read on to CGM in a very straightforward way”, but that was nothing more than a reprise of his evidence in chief. He could not identify any reason why the skilled person would be motivated to adapt Bunte to fall within the claims nor any obvious route by which they might do so.

Therefore, in my view the Skilled Team of EP627 would simply set Bunte on one side as of no interest or application to their circumstances, particularly bearing in mind there is no specific defined problem facing that team. They are dealing with all the features of an analyte monitoring device, including records of readings and any alarms or alerts. The Skilled Team are not starting with any notion that an existing routine should not be interrupted by an alert or an alarm. Accordingly, they would read Bunte with interest to see what it disclosed but, in my judgment, they would conclude its teaching of not interrupting a game on a mobile phone, but giving a notification of e.g. an incoming message which would be fetched and displayed after the game play had finished, had no application to the operation of an analyte monitoring system.

Dexcom attempted to save the case of obviousness over Bunte by pointing to the fact that it not only taught external events (e.g. incoming calls or messages) but also mentioned internal events (a system alert, a clock alert, a low energy indication, a reminding task or the like). However, as Abbott pointed out, Professor Oliver did not rely on the teaching regarding internal events at all, and this seems to have been only picked up by the lawyers, possibly only after Dr Palerm mentioned the internal events in his second report. This focus on the teaching relating to internal events was itself the product of hindsight.

Accordingly, the allegation that EP627 was obvious over Bunte fails.

For the reasons explained above, I find EP627 anticipated by the STS Guide, but not obvious over Bunte. If valid, the Dexcom devices would have infringed.

After I had completed the above section of this judgment, I was provided with a translation of the preliminary opinion of the German Federal Patent Court in relation to EP627, in advance of the oral hearing which has been set for 7 February 2024. The Court is of the preliminary view that EP227 lacks novelty over the STS Guide (D1) and lacks an inventive step over Bunte (D11) when combined with D1. It is pleasing to note that the Court has the preliminary view which coincides with my conclusion that the STS Guide anticipates. However, their consideration of Bunte is different to what I have had to consider, and their reasoning provides no reason for me to question my conclusion on Bunte.

EP223 is entitled ‘Methods and articles of manufacture for hosting a safety critical application on an uncontrolled data processing device’. It claims a priority date of 08.09.2009, which was not challenged.

Abbott were very keen to emphasise their contentions as to the technical context of EP223 at its priority date. Abbott contended as follows.

At the priority date of EP223, all CGMs on the market were dedicated medical devices comprising a sensor/transmitter and a dedicated reader/receiver bespoke to the device. The software running on these devices was bespoke to the manufacturer. It was subject to rigorous testing and regulatory approval prior to release to ensure that it operated correctly on the device.

This remained the case for several years after the priority date. It was not for another six years, in 2015, that the first mobile apps providing CGM functionality were released (Abbott's FreeStyle LibreLink app and Dexcom's G4 app).

Smartphone technology was also at an early stage of development. The first iPhone was released in 2007 and Apple’s App Store, which first introduced the ability for users to download third party apps onto their phone, was launched just a year later in 2008, the year before the priority date of EP223. Although some mobile apps relating to health and wellbeing had started to appear by the EP223 priority date, these were effectively electronic diaries enabling a user to track by self-entry exercise, meals, sleep and so on. They did not provide a user with clinical data in real time on which actual treatment decisions would or could be made. They are a world away from medical devices intended to provide treatment for, or enable diagnosis and treatment of, potentially life-threatening conditions.

These contentions underpinned Abbott’s case on the composition of the Skilled Team, their CGK and the level of their interest in developing apps to run on smartphones. In this regard, Dexcom submitted that Dr Palerm’s written evidence contained only the scantest acknowledgment that the implementation of safety-critical medical device functionality in smartphone apps was something of interest to the Skilled Addressee in September 2009. What he said was:

‘… As smartphones gained popularity, the teams designing CGMs, or insulin pump systems, started thinking about how to make this happen. Although by 2009 this may have been contemplated as a theoretical possibility, the EP 223 Skilled Team would have known that doing so had the potential for serious consequences to the user if it turned out that other applications or a new operating system release could lead the medical application to fail or operate improperly. …’

I agree that Dr Palerm’s written evidence greatly understated the interest which real skilled teams would have had in transferring safety-critical functionality into smartphone apps. This was accompanied by an apparently conscious downplaying of the state of smartphone technology in September 2009: Dr Palerm asserted that “smartphone technology was in its infancy” and that the functionality and apps of the first iPhone (which did not have an app store) was “minimal” – but failed to mention anywhere in his evidence the iPhone 3G and 3GS (which were more advanced, had access to an App Store with more than 50,000 apps and had sold millions of units in a matter of days). In cross-examination, Dr Palerm agreed that the functionality of the apps available to the iPhone 3GS was not “minimal” in 2009.

It became quickly apparent from Dr Palerm’s cross-examination that regardless of whether the technology could have been said to be in its “infancy”, he agreed that the idea of hosting safety critical applications (SCAs) – and specifically CGM readers – on smartphone devices was widely viewed as attractive in September 2009. I refer to the following passages in his cross-examination:

‘Q. You do not suggest that people working on a CGM device before the priority date would not have thought of the idea of transferring the functionality of a dedicated CGM reader or an insulin pump controller into a smartphone app, do you?

A. No, not at all. In my context, working in this industry, we were thinking about it. The question was, “How? How do we keep the same level of control and certainty that the application is going to run predictably and reliably as in our self-contained ecosystem where we control everything?” … So the questions were really about not that we would not want to do, it but how would we be able to achieve it and be comfortable that it is going to continue to perform as expected.

…

Q. It takes up room in your pockets or bag; yes? The more things you have, the more you have to lose and so on. It is very frustrating if you leave them behind. So if you can cut down the number of different bits of equipment that a person with diabetes has to carry around with them, that is obviously a very desirable thing; yes?

A. Oh absolutely. In every single diabetes medical device company that I have worked at, we have an (indistinct) presentation [overrepresentation?] of people with type 1 diabetes. They want to work in the industry, because they have the disease and they want to be part of the solution of coming up with better devices that will help them and other people like them. So yes, it is definitely in their minds.

….

Q. Here , you are making the point that I think you have just made about the safety concerns, but you say in the middle of that paragraph, “although by 2009 this”, and by “this” you mean putting the software on a smartphone, “may have been contemplated as a theoretical possibility”, I think would it be fair to say it was a bit more than that? People were actively excited about it and would like to do it. You say they had concerns, but they were thinking about it actively; yes?

A. Yes.

….

Q. What this article demonstrates very clearly is that people were looking ahead in 2009 to a future in which diabetes equipment was integrated into the smartphone, yes?

A. Yes.

….

A. No. At this point in time, I am working on Medtronic diabetes. We are having these conversations precisely around how to port CGM into a mobile phone.

Q. You were actively engaged at the time?

A. Yes.

Q. Not as a theoretical possibility, but something you were really trying to do?

A. There were conversations of how could we make this happen? There were people at the company that went out and met with people at Apple and that is how I know that the answer from Apple was, “No, we will not share a pre-released version of our new operating them with you. You will get it at the same time as everybody else will get it”. Those type of questions are the main obstacle of how do we work around that?’

In this regard, as I indicate below, both Dr Palerm and Abbott significantly downplayed the level of interest and knowledge of the Skilled Team in writing apps for smartphones by the Priority Date of EP223. The fact that it took six more years for the first mobile apps providing CGM functionality to appear on the market is an indication of the long development times required to develop not just the software but also the complete CGM system. However, by the Priority Date of EP223, it is clear that the idea of putting the functionality which resided on the dedicated devices on the market into an app running on a smartphone was both obvious and well known in the field. That is not to say that there were not challenges which the Skilled Team had to overcome.

The arguments over the composition of the skilled team were reflected in the disputes over CGK. The experts agree that the skilled person/team in relation to EP223 would be – or include – a software engineer or software architect. However, there was some disagreement between the experts as to the software engineer’s experience and field of activity. Dr Palerm’s view is that the software engineer’s background would be in designing software for dedicated medical devices, CGMs in particular. In contrast Dr Stirbu assumed that the software engineer would be someone who worked on “health-related software applications including for mobile devices”. He considered that Dr Palerm’s focus on medical devices and CGMs in particular was overly narrow.

Abbott criticised Dr Stirbu for apparently ignoring the fact that the claims are specifically directed to a method for use with an analyte monitoring device and/or drug administration device, and that the paradigm examples of such devices described in EP223 are heavily regulated medical devices – CGMs and insulin delivery devices (see [0003]).

Abbott submitted that it was well established that the skilled person is the skilled person or team within the established field – which may be a field of research or of manufacture – within which the problem addressed by the patent is located (see the recent summary of Meade J in Optis v Apple (Trial C) [2021] EWHC 3121 (Pat)at [29] – [31]). The design of such devices was an established field of manufacture, and it is that field to which the patent is directed in this case. The skilled person/team is therefore a software engineer working on the design of analyte monitoring devices/insulin delivery devices, and their background and experience would be in the design of software for such devices. Abbott submitted that Dr Stirbu’s definition of a person working in “health related software devices including for mobile devices” was too broad.

Abbott acknowledged that this distinction did not appear to have given rise to any significant difference in the skilled person’s core skill set. The significance of the distinction, according to Abbott, lay in the skilled person’s understanding of the specific requirements of developing software for controlling analyte monitoring or drug administration devices. Conversely, Abbott submitted that the way in which Dr Stirbu understood the skilled person wrongly built in an assumption that their focus is on designing software applications for mobile phones or other UDPDs rather than methods for use for analyte monitoring devices. Thus, Abbott’s point was that Dr Stirbu’s definition of the skilled person built in an aspect of hindsight.

Dexcom’s response to all of Abbott’s points was straightforward. In essence, Dexcom submitted that Abbott had mixed together three separate issues:

It is clear, in my view, that Dr Palerm and Abbott sought to play down, to a significant extent, the interest which those in this field had in utilising smartphones to replace the dedicated devices in the market. In my judgment, EP223 was clearly addressed to a person or team which straddled both the pre-existing dedicated devices which required the writing of bespoke software and the more recent requirements of writing software for use in the smartphone environments which were, by the Priority Date, already well established and clearly predicted only to grow in significance. Although Abbott limited the claims by amendment such that the UDPD is a mobile phone, EP223 was also addressed to other UDPDs, not just dedicated devices but also tablets, laptops and PCs. This last point has consequences for the scope of the CGK.

With the dispute over the composition of the Skilled Team resolved, the resolution of many of the disputes over the CGK is straightforward. What follows in this section is largely agreed, but I have also resolved some of the minor disagreements.

The statements made in this section constitute part of the CGK of the skilled addressee of EP223 at the 2009 Priority Date.

In September 2009, the available CGM devices were supplied with dedicated readers/receivers upon which the bespoke manufacturer’s software was loaded. In this way, CGM and other medical device manufacturers ensured that the software used by patients for making critical decisions about their treatment or health was carefully controlled and tested prior to release.

As of September 2009, there were different kinds of devices on which mobile and web-based applications could be installed and used, one of which was the smartphone, which is a mobile phone which has computing and mobile communication functions in the same device.

The skilled addressee of EP223 would have been familiar with the general features and limitations of a smartphone at the time.

In terms of hardware and appearance, in the mid-2000s, a lot of the smartphones had a physical keyboard (like the Blackberry devices shown below), but from around 2007 there was a major shift away from physical keyboards to ones with large finger-operated touchscreens (like the LG and Samsung devices shown below).

Apple's iPhone was first introduced in early 2007 (shown below). It had a relatively large capacitive touchscreen (for that time), introduced multi-touch interaction to phones and in terms of the software its OS (iPhone OS, "iOS" 1.0) was capable of running Apple's web-browser that could easily open full websites which were not specifically designed for phones.

By 2008, Apple had released the iPhone 3G. This came with an updated version of iOS, the iOS2. With the iPhone 3G and iOS2 came Apple's ‘App Store’, which was built in on the device and allowed the user to download third-party software onto the iPhone.

By the 2009 Priority Date, the following mobile platforms (operating systems) were available:

The skilled addressee of EP223 would be aware of, or be able to obtain information on, the features and capabilities of the following mobile phones that were available before 8 September 2009. Accordingly, they would have known that each of the mobile phones below included the capability to download and install third party applications and would have been aware of the operation and features of the Apple App Store, Android Marketplace, Palm App Catalogue, Windows Marketplace and Ovi Store.

There was no disagreement that the skilled person would have a general knowledge of the mobile phones that were available at the 2009 Priority Date, their general features and limitations, and some familiarity with their operating systems.

By 2009, both the iOS (Apple) and Android (Google) were using digital signatures to verify the integrity of app installation packages and to confirm that the app had installed correctly on the mobile device.

Medical products are heavily regulated at several levels:

Medical software needs to be developed according to well defined practices that ensure that the device is safe and effective. Medical devices may also need to be validated through clinical trials. If the product is also operated by the manufacturer as part of a service, they need to ensure that the operations are compatible with the appropriate legislation (e.g., HIPAA in the US).

In order to ensure this, the device manufacturer needs to establish a quality management system compatible with IEC/ISO 13485 and perform risk analysis according to ISO 14971. Additionally, the manufacturer needs to establish working processes compatible with IEC/ISO 62304 that govern software development lifecycle.

The skilled addressee of EP223 would be directly familiar with the content of the standards or regulatory requirements relevant to medical devices, or would work closely with regulatory, risk management and clinical trials specialists who would have this knowledge.

Dexcom identified the following points on CGK which were in dispute:

Each of these issues stemmed from the differing views which Drs Stirbu and Palerm took as to the composition of the Skilled Team and their experience. In view of my conclusions on the context and the composition of the Skilled Team for EP223, I can resolve the remaining disputes on their CGK relatively succinctly.

Although Abbott disputed Dr Stirbu’s view that a range of health and wellness applications were available on mobile platforms in 2009 and would have been CGK, I find Dr Stirbu’s views properly represent the CGK. Dr Stirbu also said that the skilled person would have appreciated the potential for mobile phones to be connected with medical devices.

In general, I accept Dr Stirbu’s evidence on each of these issues. What follows is my edit of certain paragraphs taken from Dr Stirbu’s reports. All of the following was CGK.

Apple’s iPhone, the App Store and its SDK were considered revolutionary when they were released in 2008, the App Store and the SDK became the new exemplary standard for smartphone platforms, particularly in relation to software development, distribution, installation, security and payment. One of the most significant aspects of the iPhone SDK was that it provided a holistic developer experience with tight integration of the development environment (called XCode), a device simulator, and integration with the Apple’s AppStore servers. Installation and use of the development environment was as simple as for any Mac application. In contrast things were more complicated on some other platforms at the time. For example, in Dr Stirbu’s experience, configuration of the development environment for Nokia’s Symbian/S60 platform (discussed further below) could take about one day following the instructions provided.

Android (developed by Google) also had potential at the time, although it was not as widely adopted as iOS due to the limited availability of Android devices at the time.

Another area in which mobile platforms in 2009 were limited was support for multitasking. Multitasking refers to the ability of a platform (operating system and hardware) to run several applications simultaneously. This requires the system to allocate resources (e.g. processor time, memory and access to peripherals) between several applications simultaneously. In a true multitasking operating system, either several applications could be displayed on screen at once, or one application could be on-screen (in the foreground) while other applications continued to run (e.g. perform calculations, receive inputs/provide outputs) in the background. This was a feature of all common PC operating systems in 2009, but was not generally available in mobile devices.

iOS tried to give users the impression of multitasking, by taking a snapshot of an application when it was moved to the background. The app would be restored (i.e. restarted) from that snapshot when the user brought it back to the foreground (e.g. by selecting it in the app switcher view). This gave the impression of multitasking, but in reality, each third party application was terminated when it was moved to the background.

Android, as a Linux derivative, had the ability to run multiple applications at the same time although the contemporary devices’ hardware limitations would restrict the use of this capability. Although apps could in principle run in the background on an Android system, in practice they were liable to be forcibly closed by the operating system in order to save hardware resources.

Nokia also had its own mobile OS at the time, called Symbian, which was different from others in that it was advertising its ability to run multiple applications simultaneously. However, in practice Symbian was very difficult to develop applications for and was not widely used. Although the skilled person would have been generally aware of Symbian and its capabilities, a detailed knowledge of how to develop Symbian applications would not have been part of the CGK.

Health and wellness applications were also available for various mobile platforms in 2009. As for medical applications, smartphones were becoming more and more widespread in around 2009, and they came with various connectivity functions, like Bluetooth, which enabled them to be connected to other devices. As such the potential for medical applications for mobile phones and for mobile phones to be wirelessly connected with medical devices would have been appreciated by the skilled person at the time.Dr Stirbu recalled terms like “mHealth” being used at the time.

Despite the leaps made by Apple and others, developing mobile applications in 2009 was not necessarily a quick or easy process.

Troubleshooting was common in 2009 for numerous reasons. For instance, a company developing an app generally needed to have the physical device the app was being developed for, as often the mobile device emulators (or simulators) available at the time were not an exact match of the real hardware. As an example, an emulator running on a PC would not have access to certain hardware capabilities of the mobile device, such as Bluetooth. These features would have to be tested once the software was installed on the real hardware. Distributing apps to testers and collecting feedback from the field (e.g. the app running on user's devices) during beta or final releases was not easy. Large companies would have had their own testing departments or hired specialised test companies to test and collect the feedback. However, for smaller companies or even individual developers this would have been impossible. TestFlight fixed this in 2010 by providing a system that simplified tester enrolment and viewing feedback via an online dashboard. Prior to this development, teams would have to develop their own solutions which added to the complexity. The skilled person would have appreciated these kinds of issues.

Developers of web-based applications had access to a larger body of information. Simple object access protocol (“SOAP”) based applications have been developed for years and the representational state transfer (“REST”) APIs were gaining traction. Both approaches were well documented in literatureand good commercial and open-source implementations (e.g. Java, Python) were easily available, and therefore this would have formed the CGK of the skilled person.

Dr Stirbu was asked to comment on how, in 2009, the skilled person would ensure that a software application installs and operates correctly, both during the development process and when in use by the end user. He gave the following explanation.

For mobile applications, various techniques to verify the integrity and authenticity of apps were already known and being used in 2009. The most common examples at the time (and still are to this day) were digital signatures and certificates, which were routinely used, including by Apple and Google, to verify the integrity and authenticity of applications. Specifically, both the iOS (Apple) and Android (Google) were using digital signatures to verify the integrity of app installation packages and to confirm that the app had installed correctly on the mobile device – this feature was included in iOS since the release of iOS 2.0 in 2008 and in Android since its initial release in 2008.

The digital signature and certificate process used by both iOS (and Android) at the time worked as follows (and it continues to work in the same way to this day):

In essence, the digital signatures (from the developer and from Apple or Google) confirm that (i) the app has been verified by Apple (or Google), (ii) the app was created by a known sender (the developer), and (iii) that the files in the installation package have not been modified/altered in transit, before beginning installation. In effect, the digital signatures are a promise by Apple (or Google) that “yes, this person (the developer) is who they say they are, and we, Apple (or Google), certify that”.

In iOS, a similar digital signature check is performed each time a user launches an app. The same digital signatures described above are used to verify that the installed app files are correct and have not been modified, prior to launching the app.

The skilled person would have been familiar with the digital signature process used by iOS and Android in 2009, as described above. It is one of the reasons that allowed iOS (and later Android) and smartphones to become widespread, popular, and easy to use (from the user’s perspective). It is relatively simple yet effective, which is why the general principle has not changed since then and the process continues to be used in the same way on the modern-day versions of the iOS (App Store) and Android (Google Play).

Outside of the mobile phone context (e.g. in relation PCs), digital signatures had been in widespread commercial use since at least the 1990s. Similar principles to those discussed above were used to verify software with these types of digital signature. As such, the skilled person would be familiar with the general principles and application of digital signatures to verify software installation.

The checking of the integrity of the files referred to in (iii) above is a more sophisticated version of basic verification processes such as Cyclic Redundancy Checks (“CRCs”) and hash functions. CRC functions have been widely used for error detection since the 1960s. A CRC is a mathematical function in which a unique value is calculated based on the data in a file. This number, known as a checksum is then attached to the file. After the file is copied or transmitted, the checksum is re-calculated and compared to the checksum attached to the file. If the two checksum values differ, there is an error in the file.

CRCs are part of the broader group of ‘hash functions’ which are used to calculate a unique number (a hash value) of a fixed length (e.g. 32 bits) from a larger block of data, although the output length of a CRC is much shorter than the type of hash functions used in cryptography (e.g. 16-64 bits vs 96-512 bits). The process of calculating a hash value is one-way, in that the original data cannot be recreated from the hash value. Hash functions form the basis of many verification processes including digital signatures and certificates. CRCs are generally used to verify that files have not been corrupted by transmission/storage medium errors, while the cryptographic hash functions are used to prevent interference from active attackers in the landscape.

In addition to the signature checks described above, typically, the OS ensures that the applications are initially installed in secure sandboxes where third parties do not have access. ‘Sandboxing’ is a technique for separating programs by typically providing a highly controlled environment in which to execute an untested or untrusted program or a program which is being executed for the first time by the OS. This ensures that one application cannot modify the files of another application, possibly preventing the application from functioning correctly. As such it is frequently used to test programs that may contain a virus or malicious code without the risk of the software harming the host device/OS. The principle of sandboxing has been well known in the software development and IT security field since the 1990s. This approach has been a well-known feature of iOS since its initial release in 2007and has also been available in Linux (an operating system for personal computers) since at least 2000.As such, the skilled person would be well aware of these methods for ensuring an application is able to install and operate correctly.

Other techniques used in cybersecurity can also be integrated in the application, in addition to the capabilities provided by the OS. For example, on Android devices data created after installation that can be stored on memory cards can be secured using techniques like cryptographic hashing to ensure that it has not been changed by unauthorized parties.

Other general strategies used to detect and mitigate errors in software applications in 2009 (and now) included: (a) Installing software on multiple devices (e.g. the Android ecosystem consisted of multiple devices produced by different manufacturers, with differences in processor speeds, memory size (RAM or storage), screen size, and components that communicated with peripherals. These devices could behave slightly differently, so testing on actual hardware was needed); (b) If the application becomes corrupted after installation, the OS would have some capacity to monitor and mitigate any errors. For example, Symbian Platform Security, introduced in Symbian OS v9 (around 2006) provided a secure folder for each application installed on the internal memory. The secure folder was protected from other applications. For the apps installed on removable media, the operating system stored a reference hash in a tamper proof internal memory area and computed and compared the hash whenever the application was run. Overall, this mechanism is equivalent to the process used on iOS, discussed above.

The techniques described above to ensure applications installed correctly were also well known in PC systems prior to 2009. For example, Debian Linux had a distribution system for third party applications which mirrors the process described above. An application developer prepares an installation package, which is an archive comprising the application data and a control file. The control file includes details of the supported hardware and possible conflicts with other software packages as well as cryptographic signatures to verify the contents of the installation package.This installation package is submitted to a central repository (the Debian server), where users can subsequently download the application. The Debian OS checks the installation package and installs the application. Where the installation fails, an error is displayed, although it is possible for a user to override the error and launch the application anyway.

In addition to the methods described above to ensure applications installed correctly, there were a range of checks used to ensure software would run as intended. For example, Microsoft introduced the Windows Experience Index (“WEI”) in Windows Vista in 2007. WEI checked the hardware capabilities of a user’s PC and provided a score indicating how well Windows would run and which features should be enabled for best performance. There were also lots of applications (e.g. video/audio, media or gaming applications) that checked the length of time certain actions took to determine if the application could be run properly on the device depending on whether or not there was too much delay because the hardware was insufficiently powerful. Similarly, display checks were commonly used to ensure software for any kind of display device operated properly. An example of this is professional graphics applications where you need to calibrate the screen to get the proper tones, and ensure images are displayed correctly (e.g.to accurately match printing).

It was also common to check the hardware and software environment on a PC to determine (a) if the system met the minimum requirements to run an application (e.g. WEI discussed above) and (b) if the system had changed since installation in a way which might affect the performance of the application. An example of this process is the Microsoft Windows Genuine Advantage (“WGA”) program. WGA was an antipiracy program which applied to Microsoft Windows from July 2005. WGA validated the installed copy of Windows and its licence key to determine if it was licensed by Microsoft. The installed copy of Windows was then matched to the hardware configuration of device it was installed on. If WGA determined that the copy of Windows was not genuine (i.e. not licensed by Microsoft), or there had been a significant hardware change, a message would be displayed to the user and access to non-critical Windows update functionality was disabled.

In 2009, a range of techniques were available to developers to ensure software installed and operated correctly, depending on the type of medical device involved. All of the verification techniques described in paragraphs 286-300 above would equally apply to medical software being installed on mobile devices. In addition, as medical devices are purpose based, it is possible to clearly define the boundaries of how the application is intended to be used, which makes the testing process simpler. The general process for developing a medical software application is outlined below and includes the following steps:

(a)

Identifying user needs;

(b)

Converting user needs into system requirements, which establish the purpose of the device and serve as inputs for the software design process;

(c)

Transforming system requirements into high-level software requirements which set out the architectural design of the software;

(d)

Further refining the high-level software requirements to give low-level requirements and a detailed software design, which serves as the design input for implementation;

(e)

Developing the software application based on the detailed design. The resulting software code, test cases and documentation serve as design outputs; and

(f)

Validating the product against the intended use. This is performed at unit test, integration test, system test and acceptance test level.

The approach above, derived from the V-Modelintroduced in 1991, is a well established method for designing regulated products, such as medical devices, which ensures effective risk mitigation and compliance with regulatory requirements. This has been included in regulatory guidelines since at least 1997 and would have been familiar to the skilled person.

In summary, EP223 relates to methods for ensuring that “Safety Critical Applications” (‘SCAs’), can be installed and operate as intended on an “Uncontrolled Data Processing Device” (‘UDPD’). A UDPD is a device, such as a mobile phone, on which the user is permitted to make changes to software or hardware ([0005]).

EP223 is concerned with “safety critical” software applications. The Patent starts in [0001] with essentially a definition of safety critical systems. These are systems whose “failures or malfunctions may result in significantly detrimental consequences such as death or injury to persons, severe damage or loss to equipment or to environment”. Medical systems are identified in [0003] as an example of “safety critical systems”, including analyte monitoring devices, including glucose meters.

EP223 then focuses on safety critical applications (“SCAs”) and seeks to address problems which may arise when a SCA is installed on an “uncontrolled data processing devices” (“UDPD”). UDPDs are data processing devices which “permit the user to make hardware and/or software changes to the device – e.g., installing/removing software programs, installing/removing drivers, adding/removing hardware components, etc.” (see [0005]). Examples of UDPDs include “personal computers (e.g. desktop, notebook, etc.), mobile phones (e.g., iPhones®, Blackberry®, etc.), personal digital assistances (PDAs), etc.”

A UDPD is contrasted with a “controlled” safety critical system: “Once the entire safety critical system have [sic] been verified and validated, the entire system is released and is not expected to undergo software and/or hardware changes. This provides for a very controlled system environment. New software and/or hardware changes are not introduced into the market unless and until the new hardware and/or software have undergone a new validation process. Such a controlled system environment provides a certain level of confidence that the system will not be altered or changed and potentially affects the proper operation of the system” (see [0004]).

The crux of the problem which EP223 seeks to address is that “…the uncontrolled nature of the data processing devices compromises any assurance that the SCA will operate, or continue to operate, properly on the UDPD” (see [0005]). The way EP223 seeks to address this problem is by providing that: “[v]arious combinations of checks (e.g., installation check, functional check, host integrity check, coexistence check, environment check, etc) are executed at various times to determine if the SCA may operate properly on the device. The operation of the SCA on the UDPD may be controlled accordingly” (see [0006]).

EP223 provides a more detailed explanation of the kind of problems which may be encountered when an SCA is installed on a UDPD at [0022]:

‘When a SCA is installed on a UDPD, there are no assurances that the SCA will operate properly on the UDPD because there has been no verification or validation process performed after the SCA is installed on the UDPD. The environment of the UDPD is dynamic and can change in a way that effects the proper operation of the SCA on the UDPD. For example, various software programs and drivers may be installed and removed from the UDPD and not only change the processing environment of the UDPD, but also may consume processing bandwidth making the UDPD process other applications more slowly. Various software configurations may be changed as well, which may affect the processing environment of the UDPD. Furthermore, changes to hardware components (e.g., wireless cards/modems, etc.), or configurations thereof, may affect the proper operation of the SCA on the UDPD (e.g., prevent communication to an external device). Still further, activities of the user may lead to the system obtaining viruses or spyware that can change the environment of the UDPD or consume processing bandwidth and prevent the SCA from operating properly. Moreover, changes to the system may impact power consumption of the system which may compromise the SCA. Thus, the uncontrolled nature of the data processing devices compromises any assurance that the SCA will operate or continue to operate properly on the UDPD.’

The solution provided in EP223 is a method of performing tests or checks with a UDPD, to ensure the SCA continues to operate properly. These checks may be incorporated into a test module referred to as a “test harness”, although this appears to be a preferred embodiment and the claims do not require a test harness. The test harness and SCA may both be installed on the UDPD as part of the same program module, or they may be separate programs which are validated and installed separately ([0053] – [0054]) or the test harness may be included in the SCA [0055]. Thus, the “test harness” is distinct software responsible for performing the “various combinations of checks” with which EP223 is concerned. This is illustrated in the following part of Figure 4 (described at [0056] – [0063]):

This is a block diagram showing the way in which software is stored in the memory (220) of the UDPD. Note:

The description of EP223 is focussed on the seven kinds of check depicted as components of the test harness in Figure 4, of which those of principal relevance to the claimed subject matter are “an installation check”, a “functional check” and an “environment check”. Each kind of check is clearly envisaged as being different from the others and each is presented as having its own particular purpose.

Before discussing the individual checks, it is helpful to understand some general teaching in the specification (which comes before the detailed explanation of the individual checks). First, as to the way in which EP223 describes the outcomes of the various checks in [0047]-[0049] (emphasis added):

[0047] The terms "freely operational" and "operating freely" are used herein to refer to the SCA operating such that the user is able to use the SCA as intended and free of any restrictions implemented by the test harness. …

[0048] However, if the test harness restricts the use of the SCA, then the SCA is said to be prevented from operating freely. For example, in some instances, this may include disabling the SCA and preventing the SCA from being run on the UDPD. In some instances, this may include locking or disabling of one or more safety critical features of the SCA. In some instances, this may include permitting the SCA to run on the UDPD so that the user may still use non-safety critical features of the SCA but unable to use all safety critical features of the SCA. One or more checks on test harness 310 may be performed before SCA 304 is freely operational to provide a certain level of assurance that SCA 304 may operate properly on UDPD 200 before the user uses the safety critical features. Further, in some instances, one or more checks on test harness 310 may be performed during and/or after SCA is freely operational to provide a certain level of assurance that that SCA 304 continues to operate properly on UDPD 200.

[0049] It should be appreciated that the term "permitting" is used broadly herein and may include allowing, enabling, unlocking, etc., in some instances. Further, it should be appreciated that the term "preventing" is used broadly herein and may include restricting, disabling, locking, etc., in some instances.

This is general teaching which applies to all the checks. Thus, if any check fails, the SCA may be prevented from operating freely. Preventing the SCA from operating freely may include disabling the SCA entirely or disabling one or more safety critical features while enabling use of non-safety critical features ([0048]).

The second point relates to the interaction between checks and between the installation and functional checks in particular:

‘[0060] A determination that SCA 304 operates properly on UDPD 200 may require specific outcomes for each check that is implemented. For example, in some instances, a determination that SCA is operating properly on UDPD requires an installation check to indicate that SCA is installed properly and also requires a functional check to indicate that SCA is functioning properly on UDPD 200. In some instances, a determination that SCA is operating properly on UDPD requires only functional check to indicate that SCA is functioning properly on UDPD 200 (e.g., if a proper installation has already been determined). A determination that SCA 304 is not operating properly on UDPD 200 may result, for example, from either a determination that SCA is not installed properly or a determination that SCA is not functioning properly. It should be appreciated that additional checks (e.g. host integrity check, coexistence check, interoperability check, power management check, and/or other checks not necessarily discussed herein) may also be implemented, with their specific outcomes also required for a determination that SCA operates properly on UDPD.’

Installation Check. This is covered at [0064] – [0067]. An Installation Check may be executed “to determine whether SCA 304 is installed properly on UDPD 200”. This may involve, as an example, comparing (software) images of installed components of the SCA with reference installation data ([0065]). The reason for carrying out an Installation Check is, unsurprisingly, that “an improperly installed SCA compromises any assurance that the SCA is going to operate properly on UDPD”. Importantly, EP223 explains that a successful Installation Check is not a guarantee that the SCA will operate properly: “… additional checks may be required before determining that the SCA operates properly on the UDPD”. See [0064]. The specification continues:

[0065] Installation check 412 compares the data for each installed SCA component against expected data associated with a proper installation (e.g., as defined by the reference installation data) to determine whether a proper installation has occurred. For example, a filename, CRC value, and/or version number associated with the installed SCA component may be compared with corresponding expected filename, CRC value, and/or version number in the reference installation data.

[0066] If, for example, the image of one or more installed SCA components does not match the reference installation data, then installation check 412 indicates that SCA 304 failed to install properly on UDPD 200, which indicates that SCA 304 does not operate properly on UDPD 200. SCA 304 may then be prevented from operating freely on UDPD 200.

[0067] If, for example, the image of each installed SCA component matches the reference installation data, then the installation check indicates that SCA 304 installed properly on UDPD 200 and one or more other checks (e.g., functional check, host integrity check, coexistence check, interoperability check, power management check, etc.) may be executed if required.

[0067] goes on to make clear that in certain instances, an exact match may not be required, where parameters and requirements encompass ranges and/or tolerances which allow for some deviation from an exact match.

For reasons which will become apparent, Dexcom were very keen to emphasise the many indications in the description that a check of whether the SCA is installed properly can only take place after installation. They also drew attention to Fig 3 which depicts three steps in the following order:

Dexcom also drew attention to Figures 8 and 11 which are the flow diagrams illustrating the operation of installation checks in certain embodiments:

Figure 8’s process begins with “805 Identify image of installed SCA component”, and the first decision box asks the past tense question “815 Did it install OK?”, explained at [0136]: ‘… a determination is made as to whether the installed SCA component was installed properly or not”. The outcome of a failed installation check should also be noted: the SCA is prevented from operating freely.

To the same effect, Figure 11’s process begins with “1105 Install SCA & Test Harness on UDPD”. The next step is “1110 Initiate Installation Check (e.g. compare installed SCA components against reference data)”. The first decision box asks the same question as Figure 8: “1115 Did it install OK?” Fig 11 also shows the same outcome from a failed installation check.

Dexcom also draw attention to claim 2 which is dependent on claim 1, where it expressly refers to the installation of the SCA in the past tense: “…wherein the determining whether the safety critical application (304) installed properly on the uncontrolled data processing device (200) comprises…”.

Dexcom also submitted that claim 1 does not seek to limit the way in which the “determin[ation] … whether a safety critical application … is installed properly” is carried out (there is, for example, no requirement that any particular technique be used). Neither does it require that whatever approach is chosen by the skilled addressee must provide complete assurance (or, indeed, any particular level of assurance) that the SCA is installed properly – this is clear from [0067].

Functional Check. This is covered at [0068] – [0070]. The objective is to check that the SCA “functions properly” on the UDPD: e.g. whether it can perform “calculations, measurements, etc.” accurately, whether it “displays data properly”, “whether it communicates properly … with an external device”, and whether it performs safety critical activities “in a proper amount of time”. Various specific examples of functional checks are described in more detail ([0085] – [0109]), but a functional check is not said to be limited to these examples. It is suggested that one way to do this is to ‘challenge’ the SCA by getting it to perform calculations or measurements on ‘reference computational input’ – simulated data received from external devices such as external glucose monitoring devices is given as an example. You can then compare the results with reference data to see if the SCA is computing accurately on the UDPD [0089].

As Dexcom submitted, EP223 does not seek to limit the “functional checks” which may be performed, but it is clear that they must be checks which can identify defects in the ability of the SCA properly to perform its intended functions.

Dexcom also submitted that there is no limitation on the way in which the “determin[ation of] … whether a safety critical application … functions properly” in claim 1 is carried out, contending that it does not require that every aspect of the SCA’s operation is checked, and does not require that the functional check provides any particular level of assurance that the SCA functions properly. I consider this follows from [0060] and also from the references in [0069] to a delay in performing an activity.

Environment Check. This is covered in particular at [0061] – [0063] and [0071] – [0075].

Host Integrity Check. This is covered at [0076]. This checks whether the integrity of the SCA “has been corrupted”.

Coexistence Check. This is covered at [0077] – [0081]. It is intended to address the situation where the UDPD “hosts additional programs located on the device in addition to SCA 304”, and particularly what EP223 terms “nonrelated” programs – those which do not “work together with SCA 304 but may share resources with SCA 304”. The Coexistence Check seeks to identify nonrelated programs which “may not be able to coexist on UDPD 200 with SCA 304 without compromising a safety critical aspect of SCA 304, or operation thereof, on UDPD 200”.

Interoperability Check. See [0082]. This check anticipates the existence of programs which “may interoperate with SCA 304 to provide functionality and capabilities to SCA 304, referred to herein as related programs”. The idea is for the check to determine whether the “related programs” will interoperate properly with the SCA.

Power Management Check. This is covered at [0083] – [0084]. It seeks to determine that sufficient power is available for the SCA to operate properly on the UDPD.

A point arises on validity as to whether each type of check is separate and distinct: in other words, whether the same check can constitute both an installation check and a functional check or a functional check and an environment check. The categorisation of the various checks in EP223 is done by purpose, but I see no reason why a particular check might not fulfil more than one purpose. In my view, therefore, the Skilled Team would not read the various checks in EP223 as separate and distinct but instead, as capable of overlap.

As foreshadowed in the introductory paragraphs, EP223 seeks to implement various combinations of these checks in various specific ways with the objective of detecting and dealing with problems in the operation of the SCA. The rest of the description of EP223 is taken up with a more detailed description of various possible ways in which the checks can be deployed, with particular reference to the flowcharts in the figures. Some of these scenarios are the subject of the claims. These are discussed in more detail below in the context of claim construction.

Dexcom noted that EP223 contains very little (or no) information about how to actually implement the checks it describes. It is assumed that the reader will be familiar with the concept of performing checks on software and hardware and will know how to write code to do so. What is being presented to the reader as the invention is not the idea of performing software or hardware checks, but instead a variety of ways of combining and sequencing different kinds of checks together in order to address specific problems which may be encountered when running an SCA on a UDPD as illustrated in the various flowcharts contained in the figures.

Dr Palerm described the inventive concept of claim 1 of EP223 as having two aspects:

Claims 7 and 9 add a mechanism for ongoing monitoring of the UDPD environment, with further checks performed when changes in the environment are detected.

Claim 1 (including integer 1.5, which is proposed to be added by way of the conditional amendment) is as follows, in which I have underlined the expressions in issue:

The claim is to a method of hosting an SCA on a UDPD (integer 1.1), wherein the method is for use with an analyte monitoring device and/or a drug administration device (integer 1.4). The experts focussed their evidence on the case of the UDPD being a mobile phone.

It is common ground that the claim contemplates that both an installation check and a functional check may take place (integer 1.2(a)).

The consequence of a failed check is described in integers 1.2(c) and (d). It is that safety critical features of the SCA are disabled (integer 1.2(c)) while non-safety critical features of the SCA are enabled (integer 1.2(d)). Abbott characterised this as “selective enablement”.

The patent contemplates that selective enablement may take place in different ways. The claims however relate to the selective enablement of safety critical features of applications which are (taken as a whole) safety critical applications, but which include both safety critical and non-safety critical features.

The following construction issues arise, in which, in the usual way, the arguments were influenced by the parties’ positions on validity and infringement.

Dexcom submitted that the meaning of this term is apparent from [0001]: “[s]afety critical systems are systems whose failure or malfunction may result in significantly detrimental consequences such as death or injury to persons, severe damage or loss to equipment or to environment.” As further explained in [0003] “[m]edical systems are an example of safety critical systems that require a certain level of confidence that the system will operate and continue to operate properly. Medical systems may detrimentally affect a user’s health and well- being if not operating properly or not known to be operating properly. This is especially true for medical systems that provide user’s [sic] with health-related diagnostic or therapeutic information.”

Accordingly, Dexcom invited the conclusion that a “safety critical application” is a software application whose failure or malfunction may result in significantly detrimental consequences such as death or injury to persons, severe damage or loss to equipment or to environment.

Abbott’s argument on the interpretation of this term started from [0001], but then focused on some evidence from Dr Stirbu concerned with the Gejdos prior art (which I discuss below). Abbott were critical of Dr Stirbu’s evidence, saying he took too expansive a view. That segued into this submission:

‘The “consequences” referred to in the definition of SCA are clearly intended to be much more direct than that. An SCA is an application which is directly involved with monitoring and treating the patient or recommending that the patient take action, such that malfunction would have a direct effect on the patient, e.g. an application controlling an analyte monitoring device and/or a drug administration device, which are specifically referred to in integer 1.4.’

In this submission, Abbott are trying to write additional limitations into this expression. In my view, the proper interpretation of this term is straightforward, and I agree with the conclusion invited by Dexcom.

The final point to make concerns the breadth of the expression. EP223 speaks of safety critical systems (i.e. hardware and software) but the claim requires a safety critical application (expressed in software). However, in view of the way the claim is drafted, with much non-limiting language, I see no reason why an SCA should be limited to actual executable code. A purposive interpretation indicates that any software whose failure or malfunction may result in significantly detrimental consequences such as death or injury to persons etc. falls within this expression.

The dispute over the proper construction of integers 1.2(b) – (d) concerns infringement. Abbott chose to address these integers compendiously, whereas Dexcom addressed them in parts. I will examine the parts first and then consider Abbott’s compendious arguments. These integers (with 1.2(e)) comprise the steps in the method of claim 1. There are basically two steps: the determination/verification step which dictates the outcome: preventing or permitting.

Dexcom emphasised the use of the present tense in this integer, contending that a determination of whether the SCA is installed properly is expressly called for. They submit the purpose of this check is clear – the process of installing an application on a UDPD may not be executed correctly; and if the SCA is not installed properly then its operation may pose a risk to the user. A check of whether the SCA is installed properly can only happen after installation of the SCA has taken place.

For their part, Abbott pointed out the check is whether the SCA is installed properly, not ‘has been’. This, in my view, is meticulous verbal analysis which takes no account of the technical reality.

I agree that the description of EP223 contains numerous confirmations, express and implicit, that installation checks are checks performed after installation of the SCA has taken place, in order to verify that installation took place successfully. I also agree that it does not make technical sense to speak of an installation check carried out before installation. A check before installation may check the integrity of the software to be installed, but it cannot check whether the actual installation has occurred properly.

I agree this corresponds to EP223’s description of the functional check(s).

Dexcom argued that to constitute a ‘functional check’, the check must be a direct check of the SCA’s ability to perform its intended functions and not an indirect check. The arguments on this point were made by Dexcom in the context of infringement. Furthermore, it is one of those points which is really only comprehensible once the infringement issue is understood. For that reason I will deal with it under infringement, even though it seems to me the argument raises an issue of the proper interpretation of this integer and in particular, whether a time check constitutes a determination of whether a SCA functions properly.

The principal issue arose on this integer, but it is convenient to come back to it once I have addressed the remaining integers.

Although split into two integers, in fact this is a single integer concerned with the scope of the ‘preventing’. The “preventing” is a selective “preventing”, in which some features (safety critical) of the SCA are disabled (integer 1.2(c)) but other features (non-safety critical) are enabled (integer 1.2(d)).

Dexcom pointed to the view expressed by Dr Palerm to the effect that he considers that provided that failure of one of the installation or functional checks can result in the selective disablement of safety-critical features of the SCA, it will be sufficient to satisfy the requirements of the claim if failure of the other check can only ever result in total disablement of the SCA. Dexcom submitted that the claim is simply not concerned with any mechanism of triggering total disablement of the SCA; to the contrary, integer 1.2(d) makes expressly clear that the “preventing” referred to in integer 1.2(b) actually comprises enabling non-safety critical features of the SCA: it could not be clearer that the total disablement of the features of the SCA is not something which can satisfy integer 1.2(b)’s “preventing” requirement.

This argument arises in particular from this situation: what if the SCA has no non-safety critical features? Can the claimed method still be used if the preventing comprises disabling the SC features of the SCA but there are no non-safety features which can be enabled? I return to this issue in the compendious section below.

Dexcom submitted that the same points made in relation to integer 1.2(b) above apply. Here the importance of the two-input “verification” step is again highlighted – the system needs to be satisfied that neither the installation check nor the functional check referred to in integer 1.2(a) has failed before it will permit the SCA to operate freely.

Abbott stated their position as follows:

Abbott point to the argument presented by Dr Stirbu and Dexcom that the claims require that the outcome of a failed installation check is (and is always) that the SCA is selectively enabled – i.e. despite a failed installation, some features of the SCA must be enabled in all cases. Abbott submit that this makes no sense from a technical perspective. In particular, it would not make sense to require that the outcome of a failed installation check in every case is that at least some features of the SCA continue to be enabled. In many if not most cases, if the SCA does not install, then it will not be able to operate at all, as Dr Palerm said. Dr Stirbu agreed with this as a technical matter.

Abbott also contended that Dexcom’s approach would be inconsistent with [0137] of EP223, describing an embodiment (emphasis added):

Abbott suggested this passage describes two things which can be done when the installation check is failed: either disabling the SCA completely, or only partially (i.e. selective enablement). They say it would be perverse to construe claim 1 as covering only one of those options (especially if that is the latter option, which is not technically sensible/feasible in some cases, referencing their point recorded in paragraph 359 above).

Abbott’s final point was that claim 1 is a method claim. If (for example), the system performs an installation check (which is passed) and then a functional check (which is failed), and then selectively enables the SCA in consequence of the latter, then that would be a use of the claimed method. Abbott submitted that example is sufficient for their infringement case.

Dexcom attacked Abbott’s reliance on [0137], saying Abbott depended on a bizarre reading of that paragraph. However, [0137] is clear. The far better point made by Dexcom was that it could not be assumed that claim 1 covered everything described in the specification or [0137].

As for Abbott’s perverse argument, Dexcom made three responses:

Accordingly, there is nothing perverse about giving effect to explicit limitations in the claim.

Dexcom characterised part of Abbott’s argument in this way: Abbott says that it does not matter if only the failure of the functional test can ever have the consequence of selective disablement, provided that the failure of the installation will result in total disablement.

As Dexcom submitted, the reality is that, while the description of EP223 (and, particularly, [0137]) contemplates two options upon the failure of the installation check – total disablement, or partial disablement – claim 1 claims only one of those options. Dexcom submitted that this is an entirely unremarkable result: the disclosure of the specification of a patent is frequently broader than its claims – for example because the patent was amended during prosecution, which is, in fact, what happened here: claim 1 of EP223 as filed requires that the SCA is prevented from “operating freely” upon failure of the installation check. Claim 3 of EP223 as filed limits that prevention to selective disablement of safety critical features. Claim 1 of EP223 as granted corresponds to claim 3 as filed.

I return to Dexcom’s arguments on this integer. Dexcom submitted as follows:

In my judgment, although each side’s argument includes points with some merit, neither side’s argument is entirely correct.

As indicated above, Dexcom commended their OR gate logic. However, I am not at all sure they really meant OR gate logic. If the inputs are 1=pass and 0=fail and the outputs are 1=operates freely and 0=selective enablement, an OR gate would result in selective enablement only if both checks failed. In all the other three instances, the app would operate freely, which does not accord with reality or the claim.

It seems to me that the better analogy is an AND gate, where it is only if both checks pass that the app is permitted to operate freely. In the other three instances, selective enablement is the result i.e. if both checks fail or if one or the other fail.

Abbott argue that this would produce a perverse result i.e. that it would be perverse to construe the claim as requiring selective enablement if the app fails the installation check. But this argument, it seems to me, requires a hindsight approach to interpretation of the claim. The sleight of hand in this argument is to invite the claim to be viewed through the eyes of someone familiar with how smartphones operated in 2009. In that world, if an app failed an installation check then the app would either not be installed at all, or it would not be allowed to run. But that is plainly not the right approach to EP223 which does not acknowledge either the existence or functionality of 2009 smartphones. To the contrary, EP223 it seems to me explicitly contemplates SCAs which have both safety critical features and non-safety critical features. Once that is kept in mind, it is entirely logical to have selective enablement (of the non-safety critical features) whilst the safety critical features are disabled on the occasion of an app failing an installation check.

It also assists to have in mind the various possible routes through the steps contemplated in claim 1, where completion is signified by ‘End’ and a further step by :

With these complete routes in mind, it seems to me that the claimed method includes viii), vii), v) and ii) but not i), iv) or vi), since the claim requires either complete or selective enablement. I remind myself that to infringe, it is not necessary that the claimed method is used all the time – it is sufficient if it is used some of the time.

The key here is to focus on the distinction clearly drawn in the Patent and in claim 1 between:

The consequence is, in my view, that if this ‘selective enablement’ is not possible either because of i), iv) or vi) above, then the claimed method is not used.

One final issue remains and that is Abbott’s argument that this is a method claim (see their argument at paragraph 362 above). Taken to its logical conclusion, on this argument this claim would be infringed even if no selective enablement was possible at all e.g. if an app passed both an installation check and a functional check, and the app was permitted to operate freely. Thus, it seems to me that the only possible conclusion is that in an implementation of the claimed method, the implementation must be capable of selective enablement if an installation check fails OR if a functional check fails.

In case I am wrong in that conclusion, I will also proceed to consider infringement and validity on this alternative construction, where, if an implementation produces a result which matches at least one of the four outcomes contemplated in the claim (but not all of them), then that is a use of the claimed method. It may be noted that this makes the claim extremely broad.

Claims 7 and 9 go together because they claim the environment check (claim 7) and the ensuing functional check that is carried out if a change in environment is detected (claim 9). The integers of these two claims are as follows:

It is convenient to use the shorthand ‘environment check’ for integers 7.1-7.4 but it is necessary to keep the four steps in mind.

Although Dexcom presented a detailed analysis of all these integers in their opening, I did not detect that any issues of construction arose. However, in their closing, Dexcom raised an argument that what Abbott relied upon as constituting the environment check (repetition of the time check) could only result from an absurd construction of claim 7. The problem with this argument is that if repetition of the time check results in a determination within integer 7.4, then the four steps in claim 7 are present. What the infringement point (which I consider below) illustrates is the breadth of the claim.

Dexcom also relied on evidence from Dr Stirbu as to what would normally be understood as an environment check: that an environment check would only be carried out once a functional check had been passed, and would involve checking whether hardware, drivers, OS etc of the device met the minimum requirements to run the application and then monitoring for changes. However, ‘environment check’ is not a term of art and is not used in the claims in any event.

The structure of claims 7 and 9 make clear that, as mentioned above, a change in environment does not automatically lead to selective enablement. As claim 9 provides, a functional check is initiated upon a determination (in accordance with claim 7) that a change in environment has occurred. That functional check can lead to selective enablement (integers 9.2 and 9.3).

In combination, claims 7 and 9 thereby provide for ongoing monitoring on the SCA, whereby whenever a change in environment is detected (e.g. if the user updates the OS on their UDPD), the device will initiate a functional check to ensure the SCA can continue to operate correctly in that new environment.

The G6, G7 and D1 systems are all alleged to infringe EP223, but only when used with a smartphone app (not the dedicated reader). Dexcom acknowledged there are some differences between these three systems. Abbott addressed the G6 and Dexcom the G7, but by the time of closings, neither side contended that any of these differences were material.

Abbott contended that the disputes on infringement principally turn on claim construction, identifying three issues on claim 1:

The PPD makes clear that installation of the G6 App is subject to a digital signature check which is performed by the iOS and/or Android operating system when the G6 App is downloaded onto a user’s device. When the app is downloaded, iOS (or the Android Play Store in the case of an Android phone) checks the digital certificate of the app to confirm that it has been verified and that the downloaded file has not been modified. If the verification check fails, the app will not install.

Abbott contended that this verification step is part of the process of checking that the application is correctly installed. Thus it comprises “determining … whether the safety critical application is installed properly” as required by integer 1.2(a).

Abbott relied on the following parts of Dr Stirbu’s evidence: (footnotes omitted), in support of their submission that an installation check in accordance with the claim was carried out:

However, it is necessary to read [57] in combination with [59] in particular, where Dr Stirbu made it clear the digital signature check is performed before installation begins (emphasis added):

In my judgment this digital signature check is not an installation check within claim 1.

However, Abbott also sought to argue that the digital signature check which is performed in iOS each time an app is launched constitutes an installation check within claim 1. Dexcom objected on the basis that this argument nowhere appears in Abbott’s Statement of Case on Infringement (‘SOCI’) and no application was made to amend. Accordingly, Dexcom did not address this argument.

I agree that this point does not feature anywhere in Abbott’s (Amended) SOCI of EP223. If this point had been pleaded, I would have found that this constituted an ‘installation check’. Abbott were well aware of this pleading objection in opening and failed to do anything about it. Accordingly, Dexcom’s objection is valid.

The functional check relied on for the purposes of the infringement case is a check referred to in the evidence as the “time check”.

The G6 system performs several checks designed to “ensure that the G6 App is able to operate”. As set out at ¶45 of the PPD under the heading “Maintaining Operational State”, there are several requirements that the G6 App is required to meet (emphasis added):

These requirements are said to be “monitored continuously” by monitoring the status of critical elements of the G6 App and “managing any errors encountered”. (The same checks are performed by the D1 and G7 systems, with some additional checks performed on the G7).

The requirement in (d) that the app “maintain a valid reference to time” is what is referred to as the “time check” in the evidence. It is described in more detail at ¶50 of the PPD:

On this basis, Abbott submitted that the time check is therefore a “functional check” within integer 1.2(a), for the following reasons:

If the time check determines that the G6 App is not functioning properly in this respect, the result is that an error message is triggered and display of glucose data is prevented. Other functionality of the app can continue to be used, however (e.g. looking at historical glucose data). Thus the time check also satisfies the requirements of integer 1.2(b) – (d).

Dr Stirbu said in his written evidence that the time check cannot be a functional check because it does not check whether the app performs calculations correctly, displays data properly, communicates properly with an external device or performs safety critical functions in a proper amount of time. It only checks whether a change to the phone settings has affected the local time recorded on the phone when compared to a reference time server. In his view, the Time Check does not determine if the app functions properly. The Time Check responds to a user change to the phone settings (i.e. changing the phone clock), but assumes that the app is functioning correctly, as such it is not a functional check.

Abbott characterised Dr Stirbu’s evidence as him saying the time check is not one of the specific examples of functional checks mentioned in EP223. But, as Abbott submitted, these examples are not suggested to be limiting in the description, nor are the claims limited to specific kinds of functional check. The patentee has simply put forward several examples of the kinds of test that may be performed to determine if an SCA continues to function properly, but has not suggested that they are exhaustive.

These points notwithstanding, as mentioned above, Dexcom argued that to constitute a ‘functional check’, the check must be a direct check of the SCA’s ability to perform its intended functions and not an indirect check. Dexcom argue that EP223 deals with issues which may indirectly affect an SCA’s functionality by way of a host of checks which are quite distinct from the functional check: the installation check, the environmental check, the host integrity check, the coexistence check, the interoperability check, and the power management check.

In his written evidence, Dr Stirbu characterised the time check as most similar to an Environment Check of EP223, in that the purpose of the checks is similar – they determine whether the current environment has changed. He also pointed out that the Environment Check and the time check can only be performed when the app is functioning properly.

Dexcom also relied on [0068], but this just lists examples and is not limiting:

[0068] Functional Check – In some aspects of the present disclosure, a functional check 414 may be executed to determine whether SCA 304 functions properly on UDPD 200. For example, functional check 414 may check whether SCA 304 performs computations (e.g. calculations, measurements, etc.) accurately on UDPD 200; whether SCA 304 displays data properly on a display of UDPD 200; and/or whether SCA communicates properly via UDPD with an external device; and/or whether SCA 304 performs these and/or other safety critical activities in a proper amount of time.

Dexcom acknowledged that EP223 refers to ‘timing test routines’ in [0092-3] as possible functional checks, but they contend that these are direct tests of the SCA’s ability to perform “activities (e.g. computations, communications, etc.) on UDPD 200 in a timely manner-e.g. within times falling within predetermined parameters…”.

In his oral closing, Mr Brandreth KC submitted that a check on the system time is just that, but it is not a check on the functionality of the software. The software works exactly as designed if the time is wrong, but he was constrained to accept that the information the app outputs may not be accurate.

In my view, Dexcom’s argument is an attempt to write an additional limitation into the claim to the effect that the check must be a direct test of whether the SCA functions properly. It seems to me there is no support for this in the specification and this element of the claim (like many others) is expressed broadly. On this basis, the time check constitutes a functional check.

If the digital signature check fails, the app will be prevented from launching (or installing), so no part of the app is enabled. This is scenario i) above and not within the claimed method.

If the digital signature check passes and if the time check passes, the SCA is permitted to operate freely (in accordance with integer 1.2(e)). If the digital signature check passes, but if the time check determines that the G6 App is not functioning properly in this respect, the result is that an error message is triggered and display of glucose data is prevented. Other functionality of the app can continue to be used, however (e.g. looking at historical glucose data). Thus, assuming I am correct in my finding that the time check is a functional check, it results in selective enablement. This is scenario vii) above and prima facie within the claimed method.

However, if my conclusion on construction is correct (see paragraph 377 above), Dexcom do not infringe.

On the alternative construction (see paragraph 378 above), Dexcom would infringe.

Finally, Dexcom invited my attention to the way in which the Mannheim Court found no infringement. There were two points. The first was that the installation check relied upon took place prior to installation and therefore could not constitute an installation check. They pointed out that a successful (pre-)installation check would merely be a condition for the installation to be allowed to commence and would not preclude the possibility of errors occurring during the installation process itself or detect any errors if they did occur.

I have reached the same conclusion as the Mannheim Court, the result being that Abbott’s infringement case as pleaded, must fail.

However, I will briefly address the unpleaded allegation that digital signature checks which are carried out each time the app is launched occur post-installation and constitute installation checks within claim 1. As far as I can see, this further allegation was not considered by the Mannheim Court. Even if these are considered to be installation checks within claim 1, the infringement case still fails for the second reason identified by the Mannheim Court. This is that the installation check(s) relied upon did not result in selective disablement of safety-critical features of the SCA. Again, I have reached the same conclusion.

Abbott’s argument for infringement of these claims was as follows. They contended that the time check also comprises an environment check of claim 7. The time check necessarily involves a determination of whether there has been a change in the operating environment of the G6 App – namely that the device has lost time synchronisation. The consequence of this is a determination that the G6 App no longer functions properly (e.g. past glucose measurements will be associated with the wrong time), which fulfils the requirements of a functional check. So, although it is described in the PPD as if it were a single process, the time check in fact comprises the two checks required by claims 7 and 9.

Dr Stirbu agreed that the time check “if anything, is most similar” to the environment check of EP223, but gave two reasons why, in his view, it is not an environment check within the meaning of the claims, neither of which in my view carry any weight:

Dexcom took another pleading point on infringement of claim 7, contending in closing that it appeared (from Dr Palerm’s evidence in cross-examination) that Abbott’s case may actually be that the environment check is not the time check itself but the underlying process which triggers the repetition of the time check, a case which Dexcom contended was not open to Abbott.

This argument demonstrates the danger of relying too heavily on ‘environment check’ as a precis of the claim. Abbott’s SOCI makes it clear that Abbott rely on a time check for integer 7.1 and a time check for integer 7.2, a comparison between the two resulting in a determination of whether an environment change has occurred.

Dexcom also argued that a time check is just a time check and involves no identification of environments, no comparison and no action taken on the basis of any comparison. This argument carries no weight, in view of the pleaded case which in my view demonstrates that if the Dexcom devices infringed claim 1, they would also infringe claims 7 and 9.

In relation to the infringement arguments, Dexcom also raised a Gillette defence but consideration of this must await the validity analysis.

In closing, Dexcom made it clear that it maintained the novelty attack based on Gejdos as a squeeze on infringement. Dexcom accepts that the database integrity check in Gejdos is not a direct check of the functionality of the application. Therefore, on Dexcom’s construction of integer 1.2(a), Gejdos does not disclose a functional check. Since I have found against Dexcom on construction, I must assess whether Gejdos discloses a functional check and all the other elements of the claim.

Gejdos is a US patent application published on 11 June 2009 titled “System and Method for Database Integrity Checking”. It claims and discloses a method for checking the integrity of a database containing physiological information, the database being accessible by a healthcare management software system (‘HMSS’).

The database includes a patient’s (or patients’) healthcare related information – for example, blood glucose values [0027]. [0028] says:

[0028] Healthcare management software system 106 includes instructions which when executed by computing device 100 present physiological information 110 or information based on physiological information 110 to an output device 112. Exemplary information presented by healthcare management software system 106 to output device 112 include diaries of blood glucose values and reports showing a plurality of blood glucose values. Exemplary reports include standard day reports wherein the blood glucose values are grouped according to the time of day taken, standard week reports wherein the blood glucose values are grouped according to the day of the week taken, trend graphs to illustrate temporal trends in blood glucose values, and other suitable reports.

The HMSS can be run on e.g. a “cellular device” or “personal digital assistant ‘PDA’ such as BLACKBERRY brand devices” [0025].

The performance of “integrity checks” (which may be “any process whereby the accuracy of the patent database 104 may be affirmed or denied” [0043]) of the patient database in the HMSS at various times is described, for example when the HMSS is installed or when the HMSS is launched. This is clearly shown in Fig 4:

Dr Stirbu considered that all of the features of claim 1 of EP223 are disclosed by Gejdos (see Stirbu 1 ¶242 [D1/3/279]).

Dr Palerm identified two points of distinction between the disclosure of Gejdos and claim 1 of EP223:

Dr Stirbu did not agree. So these two points were fully explored at trial.

Dr Palerm had essentially two points as to why Gejdos does not disclose an SCA: first, because it was not a ‘live’ system and second, because malfunction would not have any significant adverse consequences. Both points were the consequence of him having formed an unreasonably narrow view of the disclosure of Gejdos. For example, in cross-examination he said this:

What Gejdos describes is, and it is in the context of a blood glucose meter, of patient comes into the clinic for their quarterly check-up. They connect their blood glucose meter to a computer. They download all of the data from the meter into the computer and then the physician can look at retrospective reports of what the glucose measurements were over the past month and then, based on their assessment, be able to make recommendations for the patient of, ‘We should change this or that in your treatment’, so it is completely a retrospective view.

It is quite clear from EP223 that the concept of an SCA is not limited to ‘live’ systems – see [0027] and [0028] and in particular:

[0028] In some aspects of the present disclosure, SCA 304 is an application associated with analyte monitoring and/or determination. Example features of SCA 304 may include, for example, one or more of the following: determining analyte amounts or concentrations from a sample (e.g., saliva, blood, other bodily fluid, etc.); receiving measurement data; managing and/or processing measurement data (e.g., logging measurements, providing warnings based on measurement values, providing alternative representations of data in the form of reports, graphs, charts, etc.);

In addition, as was demonstrated in cross-examination, it was unclear what Dr Palerm meant by a ‘live’ system. He was shown Fig 17 of EP223 which shows a mobile phone with an adapter which is used to take a glucose reading from a traditional fingerprick test, which required him to backtrack from his initial view that a live system ‘is one that is running constantly, even when the user is not engaged with it, like a CGM’, to ‘live… is the patient being affected immediately and directly by what is happening’. As Dexcom submitted, there was no basis in EP223 for either of these additional limitations.

As to Dr Palerm’s second point, as Dexcom pointed out:

Finally, even on Dr Palerm’s view that Gejdos would only be used for retrospective review of blood glucose data in the physician’s office, it is clear that failure or malfunction of the system could result in harm to the patient caused by misinformed insulin dosage adjustments.

In conclusion on this point, it is clear to me that Gejdos discloses a safety critical application.

In response to Dr Stirbu’s evidence on ‘installation check’, Dr Palerm stated in his second report that “Gejdos does not describe any checks on the healthcare management system application to ensure that it installs correctly”. As Dexcom submitted, he appears to understand that the installation check of claim 1 of EP223 must involve a check of the software executable, and not another component of the software package like a database.

However, EP223 is clear that the installation check can involve checking an image of an installed safety critical application component – see claim 2. An “installed safety critical application component” can include any file in a software installation package that is loaded onto the UDPD “in addition to a primary executable file”. Dr Palerm agreed:

Q. Each of the files that is included in an installation package can be seen as an SCA component; right?

A. Yes, different programmes that make up a larger system.

Q. It could be an image file for the graphical interface of the app, for example?

A. Yes.

Q. Audio file for an alarm sound?

A. Yes.

Q. Both of those could be directly safety-critical, could they not, if the system is supposed to play an alarm sound, but the audio file for that sound is corrupted and the alarm may not play and the patient may miss it, right?

A. Potentially.

Q. It could include, as one of the components, a database file?

A. Yes.

So EP223’s installation check is satisfied by checking an image of a single SCA component, including a database file – as Dr Palerm agreed:

Q. Just imagine for a moment that the component that you are checking is the database of information, and you discover that has not been installed correctly; that would be covered by the method of claim 2, would it not?

A. Yes.

Accordingly, Gejdos discloses an installation check as required by claim 1 of EP223.

Fig 4 of Gejdos suggests that the database integrity check will be triggered for example upon several events other than installation – e.g. “Launch of Healthcare Management Software System”, “Change Patient Databases”, “Restore Database”.

Gejdos’ database integrity check is ultimately a check on the database of patient information. As such, as I mentioned above, Dexcom accepted that on their primary construction it is not a direct check of whether an SCA functions properly. If, as I have held, functional checks can include indirect checks – particularly, the G6 / G7 / D1 Time Check – then Dexcom submitted that there is no obvious reason why Gejdos’ database integrity check should not be a functional check. Dexcom compared the two:

Another point made by Dr Palerm and put to Dr Stirbu in cross-examination was that Gejdos’ disclosure of integrity checks was limited to what it describes as “conversions” which focus on the units used for measurements stored in the database. He explained that his understanding, as a skilled person, was “that the database integrity information will catch any kind of errors that are at the database level”. His answer was fully consistent with the express direction at [0043] that “[t]he integrity test may be any process whereby the accuracy of patient database 104 may be affirmed or denied”. In any event – as I found above, the functional check in EP223 has a very broad scope: if Gejdos’ database integrity check is otherwise within that scope there is no reason why a “conversions”-only check – to ensure that the correct units are recorded / displayed – would not satisfy its requirements.

Dexcom also drew attention to the fact that Dr Palerm also asserted “… the single integrity check of the database is not a disclosure of both an installation and a functional check.” The point here seems to be that a functional check cannot also be an installation check. Dexcom agreed – which is why their primary construction requires the functional check to be a direct check of functionality. Dr Palerm’s point was not specifically tied to functional or installation checks, and Dexcom submitted that there is certainly good sense in the idea that EP223 has described several different kinds of checks and defined them differently because it thinks they are distinct and serve different purposes. (Dexcom’s emphasis).

Dexcom developed this point to create a squeeze on Abbott’s case on infringement of claims 7 & 9. So, they say, if it is right that a functional check cannot also be an installation check, then why – per Abbott’s positive case, in which the G6 / G7 / D1 Time Checks are relied upon for both – should a functional check also be capable of being an environment check?

In my view, the answer to this is as follows. EP223 describes a number of checks, categorising them by purpose. However, I see no reason why the same check cannot fulfil more than one purpose.

Gejdos at [0043] states that an error message may be presented in the event of a failed database integrity check. Dr Stirbu explained that the Skilled Addressee would understand that this includes disabling safety-critical database related functions when the database integrity check fails.

Dr Palerm’s evidence was that the consequence of a failed check would be that the database file will not be accessible, but that other functionality of the application would remain active.

Abbott submitted that if the check relied on by Dexcom is failed, then the database cannot be accessed, but acknowledged that other databases might be able to be accessed. Abbott submitted however that this is nothing like the selective enablement of the non-safety critical features while disabling safety critical features of an application, as required by claim 1.

On this point, I accept Dr Stirbu’s evidence. Accordingly, Gejdos discloses ‘selective enablement’ within integers 1.2(c) and (d).

For these reasons, I find that Gejdos anticipates claim 1 of EP223.

Dexcom also ran an alternative case that if Gejdos did not anticipate, claim 1 was nonetheless obvious over Gejdos. It is somewhat tricky to address this alternative case for two reasons: first, because neither side developed any arguments to this effect; second, because the reason why I have found that Gejdos discloses something within claim 1 is because of the very broad scope of claim 1.

Lebel is a US patent application published on 7 February 2002, entitled “Microprocessor controlled ambulatory medical apparatus with hand-held communication device”.

Lebel relates generally to ambulatory medical systems that include a microprocessor controlled ambulatory medical device and a separate control device that communicate via telemetry where the medical device has enhanced functionality, Safety features, failure detection, and/or alarming capabilities. Preferred embodiments relate to implantable infusion pumps and external devices for communicating therewith [0002].

Lebel discloses a system comprising two components: an implantable medical device (“MD”, such as the implantable insulin infusion pump of figure 1) and a handheld communication device (“CD”, or “External Subsystem” – depicted in Fig 2 and on the left-hand side of Figure 3), which is described as being configured to operate only with a specific implantable device.

The two components are shown schematically in figure 3, reproduced below.

The implantable device is described as including two processors – a main and a monitor processor. At [0140] Lebel describes a self-checking mechanism whereby the two processors within the implantable device separately perform calculations relating to insulin delivery and the results are compared to ensure the two processors agree on the quantity and timing of insulin delivery. If a problem is identified the implantable device may be placed in “protective mode” where insulin delivery is stopped (cut back to a medically insignificant rate).

The main processor software can initiate self-test functions, which may be requested via the external communication device or configured to run automatically ([0391]). If the self-test fails, a Watchdog circuit is tripped, which may result in a reset of a processor ([0325]).

The implantable device may run both application software and second stage bootloader software (“SSBS”). The bootloader software is described as incapable of operating the insulin pump but capable of performing limited telemetry and communication activity ([0320]). The SSBS can be used to download new application software, remaining in control of the device until the new software is downloaded and executed. It is described as enabling the implantable device to receive new or replacement application software, or allowing the system to reset itself after a system failure, by placing the implantable device in a safe state in which medical functionality (e.g. dispensing insulin) is not supported ([0321]).

Dr Stirbu considered that the only integer of claim 1 not disclosed in Lebel was integer 1.1 because there was no UDPD. By contrast Lebel disclosed a controlled dedicated medical device. From that starting point there were three main parts to Dr Stirbu’s evidence to the effect that an obvious development of Lebel was to replace the control device in Fig 3 with a mobile phone:

It is fair to acknowledge that Dr Stirbu explained (in both his reports) that there was a spectrum of devices which fall within the definition of a UDPD which allow a user varying amounts of freedom to make hardware and software changes. He pointed out that Apple iOS and Android operating systems strictly controlled what applications could be installed on a phone (due to the App Store verifications process he had described earlier) and the process of installation. He also pointed out that the types of checks characterised in EP223 as ‘installation checks’ and ‘functional checks’ were checks which were (and known to be) checks typically carried out by the operating systems and/or other programs on smartphones, such that many of them would be known by the Skilled Team to be redundant in the context of a smartphone.

As I mentioned above, Dr Palerm accepted that the idea of hosting an SCA on a UDPD was not part of the inventive concept of claim 1 of EP223. As such, Dexcom submitted that it is legitimate to approach each item of prior art on the basis that the skilled addressee has been tasked with implementing (say) CGM functionality in a smartphone app. I agree that there is no hindsight in posing the obviousness question in this way: see the judgment of Birss J (as he then was) in HTC Corp v Gemalto SA [2013] EWHC 1876 Pat at [267] – [276].

In his written evidence, although he considered the inventive concept of claim 1 of EP223 to be relevant to a person who has already had the idea of hosting an SCA (such as a CGM reader) on a UDPD and is thinking about how to make it happen safely, (Footnote: ²) Dr Palerm approached Lebel entirely in the abstract, asking himself about what the Skilled Addressee might do if the document was placed on their desk apropos of nothing:

18 Q. You have approached Lebel on the basis that the skilled addressee is not interested in putting a SCA on an UDPD when they read it and then asked if that would prompt them to do so; right?

A. Correct. The SCA in this case, this is one, even the hand-held device, you could not even put that on an uncontrolled mobile phone today, because the frequencies that it uses to communicate with implantable pump require a special radio set that a mobile phone does not have. ….

Thus, Dr Palerm’s primary and “fundamental” objection to the alleged obviousness of EP223 in light of Lebel – that it “does not concern an SCA installed on an uncontrolled data processing device of any kind” and “it would not … have been obvious to the EP223 Skilled Team to install such SCAs on UDPDs, nor specifically mobile phones, and there is nothing in Lebel to suggest doing that, nor [that] any aspect of the functionality that it describes might be useful in such a context. …” (Palerm 1 ¶¶19.4 – 19.5) – was misguided. Dr Palerm was looking for an express direction in the prior art to deploy its teaching in the context of SCAs hosted on UDPDs, but he did not need to look for one there since the idea was itself part of the CGK.

Abbott focussed on the suggestion that the Skilled Team would seek to implement the reader device (figure 2 and the left-hand side of figure 3) in a smartphone app, but (as Dr Stirbu acknowledged) they would not seek to take the software in the implantable infusion pump off the device and put it on an app.

Abbott contended that this case suffered from such insuperable problems that it could only have been constructed by Dexcom/Dr Stirbu working backwards from the invention. Abbott made the following points:

The technical points in that list were established by Abbott in their cross-examination of Dr Stirbu. As for point ix), Dr Stirbu did agree that point, but it was clear he was genuinely puzzled about the distinction being drawn by the cross-examiner between application software and firmware. I think this resulted from Abbott’s contention that the Skilled Person was a writer of application software and not firmware.

As Dexcom pointed out, Abbott’s list of points includes some repetition. Furthermore, they also include some misdirection and fail to address the actual case which Dexcom put forward.

A point made by Abbott in their Opening was that neither Dr Stirbu nor Dexcom had spelt out precisely how, in their obviousness case, the Skilled Team got from Lebel to something which fell within claim 1.

It became clear to me from Dr Stirbu’s evidence that he was envisaging a route at quite a high level of generality. The Skilled Team was presented in Lebel with a range of broadly applicable risk mitigation strategies, and I think his point was that the Skilled Team could select from that range those which suited their purpose. In contrast, his cross-examination entirely legitimately delved into the detail and did not engage at any higher level.

However, inherent in Dr Stirbu’s approach was his acknowledgement that the installation checks and functional checks in, for example, an iOS environment were already supplied by the operating system (see paragraph 459 above). He may have thought therefore that all that was required was to replace the dedicated reader with a UDPD in the shape of a smartphone. As he readily accepted in cross-examination, his Skilled Team were not moving any software from the implantable pump to the UDPD. However, I think his point was that the dedicated reader in Lebel had to contain software to analyse and display results sent to it from the implantable pump e.g. blood glucose levels, and that software would be placed on the UDPD, and it would undergo the standard iOS or Android ‘installation checks’ and ‘functional checks’ within the meaning of those broad expressions in claim 1 of EP223.

If this case had been spelled out, one final obstacle to it is the fact that it does not require the application of any of the risk mitigation strategies taught in Lebel. Instead, the Skilled Team would have to realise that the addition of any of those strategies was not needed.

Overall, I am unable to accept that EP223 was obvious over Lebel for two principal reasons. First, because the route taken in the obviousness attack was not spelled out (either at all or clearly enough). Second, because the attack seemed to me to be essentially an argument that it was obvious (from the CGK) to replace the dedicated reader unit in Lebel with a UDPD.

It is convenient at this point to address Dexcom’s Gillette arguments.

Dexcom’s Gillette argument is constructed from a number of discrete points, as follows.

First, the Signature Check relied upon by Abbott as satisfying the requirement of claim 1 to “determin[e] whether the SCA is installed properly” was inevitably carried out at the priority date of EP223 whenever any iOS or Android app – of any kind – was installed through the respective App Store (and, indeed Dr Palerm said that installation checks were “pretty much” known “from the beginning of software onwards”. Dr Palerm also agreed :

Q. Indeed, every single app available on the iOS or Android App Stores, whether it is Dexcom G6 app or Angry Birds, it undergoes the same signature verification process?

A. Yes.

Q. It is the same one that has been used in iOS and Android since before September 2009; right?

A. Yes and if not exactly the same, something very similar.

Second, partial disablement. On this, Dr Palerm made clear that the partial disablement aspect of claim 1 of EP223 was (i) a matter of user experience rather than safety; and (ii) obvious in the event of the detection of an app failure or malfunction as an alternative to total disablement – e.g. the SCA itself may retain the functionality necessary to display a message “cannot run right now” in the event a problem is detected:

Q. Sure, but what you are saying in [¶17.23(b) of Palerm 1] is about

them being allowed to continue to access non-safety-critical

aspects. That is about the user experience.

A. Yes.

Q. Not about the safety.

A. Correct.

Q. You could keep the user safe from harm caused by a software

malfunction simply by disabling the SCA altogether when a check

failed, yes?

A. That is a possibility.

Q. But that would be a worse user experience, less convenient, et

cetera?

A. Correct.

Q. If you totally disable the app so it will not run at all, the user will

find that a bit puzzling. They will not know why the app is not

opening?

A. I would expect at that point some sort of message would be given

to them or an error message of some sort notifying why it will not

run.

Q. Not from the app, because the app is not running.

A. It could be from the app itself, that you run the app and you simply

have a message, “Cannot run right now”.

The result is, so Dexcom submitted, that the only issue on obviousness, on Abbott’s construction, is whether it would be obvious to include within a SCA smartphone app (such as a CGM reader app) on a smartphone a functional check of some kind (which can include checking whether the system time is accurate). This is the third point.

When addressing this third point – the obviousness of implementing a functional check – Dexcom submitted that the language of claim 1 places no express limitation at all on the functional check required: just “determining ... whether a safety critical application … functions properly”. Accordingly, they submitted it seemed to be common ground that:

Accordingly, Dexcom submitted that in this respect the claim is exceptionally broad – any kind of functional check on a single aspect of the SCA’s functionality carried out by any software component will do (although on Dexcom’s construction the check needs to directly check the functionality concerned while Abbott says that an indirect check (e.g. checking the system clock) is sufficient).

Finally, Dexcom submitted that this analysis also applied to claims 7&9, since Dr Palerm agreed that checks on the time would be obvious when seeking to implement a CGK reader in a smartphone app.

For the moment, I leave claims 7 & 9 until later. As for the three discrete points pertaining to claim 1, I accept that Dexcom established all three points on an individual basis. However, the problem lies in identifying the starting point for the obviousness argument which utilises these three points. It seems to me there are only five possible options: i) Gejdos, ii) Lebel, iii) an unpleaded case of obviousness over CGK, iv) a contention (which was not made) that no starting point is required because it is a Gillette argument or v) an argument of lack of technical contribution/AgrEvo obviousness. Dealing with each in turn:

However, the reason why I thought it right to consider these five options is because Dexcom did not address lack of technical contribution directly in either their written or oral closings. Abbott did address it in their written closing, contending that they did not understand how such a plea could be sustained. That, of course, was a clear invitation to Dexcom to spell out how it could be sustained. Since that did not happen I decline to spend any more time on it. It would have been more helpful if the Gillette argument had either been explained properly or been dropped.

In his evidence, Dr Palerm dealt with the inventive concept of claims 7 and 9 together, a point which Abbott adopted in their written closing. In other words, there was no attempt to suggest that claim 7 was independently inventive. So I will deal with these two claims together.

Dexcom’s closing addressed these two claims on the alternative constructions:

Dexcom also submitted that Dr Palerm’s own evidence confirmed that there was nothing inventive about performing a check of the hardware or software environment (see [T/3/365₁₁ – 367₁₂]):

Q. The skilled person who is interested in hosting an SCA on an UDPD knows that the system environment is not controlled; yes?

A. Correct.

Q. They would foresee that some kind of system environment might change; yes?

A. Yes.

Q. I think that is what you said was your immediate concern in 2009?

A. Correct.

Q. They would be worried that the software might install and run perfectly well for a time but cease to do so if the user made a change to the environment on the UDPD; yes?

A. Correct.

Q. Changed the hardware, upgraded to a new version of iOS or something like that; yes?

A. Correct.

Q. The skilled person would know that they needed some kind of environment check, but with a SCA, they would be worried about whether that would be robust enough; yes?

A. Yes, and it is more than just – The environment check is definitely an important piece of this. It is the functional checks that you perform after that are the more important part, because one of the most common pieces of it would be: I perform an environment check; I have done all of my testing in the engineering bench top, if you will; and I know that it works; and I will just make numbers up, iOS 6, and the user has just upgraded to iOS 7; me, the manufacturer, I have not performed the testing on iOS 7, so I am going to prevent the application of running at all if they happen to upgrade to iOS 7 before I am able to whitelist that operating system as an acceptable environment to operate in. In this case the functional checks are about how do I still allow a certain level of functionality, even in the face of such changes? What type of functional checks can I perform on the device to prevent all of this, all or nothing type of response.

Q. They would anticipate they would need some environment check.

A. Yes.

Q. And they anticipate that they would need to have some consequence if the environment had changed; yes?

A. Yes.

Q. And then you are saying the devil would be in the details as to what they did afterwards; yes?

A. “Devil in the details” in what sense?

Q. I am using an idiom. They would have to decide how they responded to a detection that the environment had changed; yes?

A.

Correct, and the standard approach had been environment change, it has changed in a way that I have not been able to test, like the change in operating system and completely preventing the application from operating from that point.

Elsewhere in his cross-examination, Dr Palerm refused to accept that running an environment check was obvious, falling back on generalised safety concerns. This was not convincing at all. In the circumstances I find claims 7 /9 obvious over claim 1.

EP159 is entitled “Systems and Methods for Providing Sensitive and Specific Alarms” and EP539 is entitled “Systems for Providing Sensitive and Specific Alarms”. They share the same priority date (unchallenged) of 30 October 2012. They are related (EP539 is a divisional of EP159). The specifications of the two patents are virtually identical though there are some differences in paragraph numbering. I propose to refer to paragraph numbers of EP539.

Only one claim of each patent is in issue – claim 1 of EP159 and the unconditionally proposed amended claim 1 of EP539. Abbott admits infringement of both claims.

As Abbott submitted, the inventive concept of the claims of the Dexcom patents (which is effectively the same for EP159 and EP539 as proposed to be amended) is the provision of (at least) two hypoglycaemic alarms, one a current glucose alarm with a user settable threshold and the second a predictive alarm with a fixed threshold.

Abbott’s case is that combination of alarms was no more than one common-sense way to implement glucose alarms of a kind that were well known to the skilled team from the products on the market. For that reason, there was much focus on the CGK as to the available products on the market which the skilled person would be aware of and what the skilled team would have learned from them. Armed with the CGK, Abbott submit both claims were anticipated by Brauker 2007 and Shariati but if not anticipated obvious over those and two other citations, the STS-7 Guide and the Navigator Guide.

Dexcom’s case is that the claims were neither anticipated nor obvious, making the familiar accusation that Abbott’s case was infused with hindsight. Furthermore, it was plain from Professor Oliver’s evidence that Dexcom appeared to be running a mindset case against both fixed and predictive alerts. This was addressed in some detail in Abbott’s written opening, but hardly touched upon in Dexcom’s, the only references to mindset coming in some general citation of authority on the skilled team (Schlumberger [42] and Teva v Leo [2015] EWCA Civ 799 at [29]).

However, the mindset case seemed to be the cause or driver for disputes as to (a) the Skilled Addressee/Team of the Patents and (b) their CGK.

The status of the mindset evidence became more obscure when in their Closing Dexcom disclaimed any reliance on a mindset case. This was put at the very start of their written closing:

On reflection, it is perhaps not surprising that Dexcom disclaimed the second kind of non-obviousness argument because, if there was a technical prejudice, these Patents neither discuss it nor explain why it was unwarranted. Hence Dexcom had to argue that the invention simply would not occur to the Skilled Team, having read and considered each piece of prior art. So the focus switched from mindset to the context within which the Skilled Team would read each piece of prior art, which was also the backdrop for Dexcom’s accusations of hindsight. On context, Professor Oliver’s evidence remained relevant although I am bound to say that, on the facts here, the distinction between the two cases seemed to be very thin indeed.

For these Patents, it is convenient to deal with the identity of the Skilled Addressee and their CGK first, then to discuss the Patents and their claims. Since the EP539 claims are those in the proposed unconditional amendment, it is convenient to consider the objections to the proposed amendments before moving to the main validity attacks.

It is common ground that the Skilled Addressee is the same for EP159 and EP539.

Dr Palerm said that EP159 and EP539 are addressed to a team lead by an engineer who would consult with:

Prof Oliver took the view that EP159 and EP539 are addressed to a Skilled Clinician; but he says that to the extent that the addressee is a Skilled Engineer, it is a Skilled Engineer who works very closely with, and seeks advice from, a Skilled Clinician.

Each expert disagreed with the other in this regard:

I agree with Dr Palerm on this point in that an engineer working in this field would have sufficient knowledge of, in particular, the various clinical guidelines. It seemed to me that Professor Oliver’s insistence on a much greater role for the clinician was simply a foundation for his argument that the academic discussion and debate over trying to define an accepted glucose level to be used as a yardstick for use in clinical research studies concerning hypoglycaemia, so that research studies could be compared, was part of the CGK. It was not.

The agreed CGK is set out above. Here I deal with the CGK points in dispute on these Patents.

At the start of the trial I was presented with lists of CGK points in dispute – lists because the parties could not even agree what was in dispute. In relation to these Patents, Abbott suggested that the following matters were in dispute:

Although each of those issues featured (in one form or another) in Dexcom’s list of disputed CGK issues, Dexcom listed another 14 issues. Although I have reviewed this list again for the purposes of preparing this judgment, they do not seem to me to be material. It is sufficient to focus on the four issues identified by Abbott.

I have already touched on this. The academic debate over a definition for adoption in clinical research trials was not part of the CGK.

To the contrary, as Dr Palerm explained, there were two commonly accepted or recognised thresholds. First, it was commonly accepted that 70mg/dL (3.9mmol/L) was a threshold for biochemical hypoglycaemia. Second, it was commonly recognised that symptoms of cognitive impairment may be seen in most patients at or below about 50-54mg/dL (2.8-3.0 mmol/L) and this would be regarded as a potentially dangerous level of hypoglycaemia, and one, in Dr Palerm’s view, the CGM designer would have wanted to alert the patient.

These thresholds were consistent with the practical clinical guidance from (a) the 2005 American Diabetes Association Report, (b) the 2011 Oxford Textbook of Endocrinology and Diabetes, (c) the May 2012 EMA Guideline which describes the ADA classifications as a ‘well-accepted source’, as well as (d) the 2009 Position Statement from the ADA. These thresholds were also consistent with those used in actual devices.

Professor Oliver’s point was that glycaemic variability experienced between individual users would lead the Skilled Team to not include a fixed alarm in a CGM. Dr Palerm disagreed. He was of the view that the Skilled Team would consider the overall alarm system rather than each alarm in isolation and would understand that including a user-settable alarm would enable an alarm to be set according to a user’s preference. However, Dr Palerm considered it would remain attractive for the Skilled Team to include a fixed alarm at a clinically significant level (such as 3.0 mmol/L) to provide a safety net (cf the fixed alarm in the STS-7).

Whilst glycaemic variability was well-known, I agree with Dr Palerm on this point.

Alarm fatigue was a known issue, but Dr Palerm was of the view that it originated mainly from alarms for which corrective action was not needed (e.g. an alarm at 5.0 mmol/L). What he described as the ‘trade-off’ in a user-settable alarm between a lower threshold which would catch fewer actual instances of hypoglycaemia and an artificially high threshold which would risk alarm fatigue, would not have been a significant factor in the Skilled Team’s decision to include a fixed predictive alarm threshold.

Dr Palerm also made the point that the trend in CGM device design was to include more alarms rather than fewer. Alarm fatigue was not a concern because most alarms could be disabled. Understandably however, a low fixed alarm (such as 3.0 mmol/L) could not be disabled because it was safety critical. I agree with Dr Palerm on this point.

The experts were agreed that improving CGM device accuracy was a constant development objective of CGM manufacturers. Professor Oliver seemed to suggest this objective would so dominate the thinking in the Skilled Team (the Skilled Clinician in particular) that they would not arrive at the claimed invention of these Patents. Dr Palerm did not agree that improving accuracy would exclude development of other CGM features, such as alarms. Dr Palerm also made the point that the accuracy of the signal processing algorithms would be for the signal processing engineer, and the accuracy of the device a matter for the sensor design team. Thus, sensor accuracy would be a design parameter presented to the Skilled Team of these Patents.

Furthermore, all the CGM devices were adjunctive, providing warnings to be confirmed by fingerprick testing. Dr Palerm was of the view that potential inaccuracies in the CGM glucose measurements provided a positive reason to include a ‘safety net’ alarm (e.g. at 3.0mmol/L), and particularly a predictive alarm at that level to give the user advance notice. Once again, I accept Dr Palerm’s evidence on this point.

The descriptions cover many aspects of the functionality of a CGM device and there are other patents deriving from EP159. The claims in these two have picked out certain features and put them together in a particular combination. I have picked out the paragraphs most relevant to the claims. In summary:

Claim 1 of EP159 was broken down into integers as follows:

Although Dexcom’s Opening Skeleton included a detailed analysis of each integer, there seemed to be no dispute about the interpretation of the claim. Stripped of the verbiage, what is claimed is the provision of two types of hypoglycaemic indicators based on two thresholds, where the first threshold is configured to be settable and the second threshold is a fixed value.

Abbott submitted:

Accordingly, EP159 claim 1 can be summarised as claiming a system with a continuous analyte sensor including:

Claim 1 of EP539 as proposed to be amended is long, but it is worth setting out to show where integer 1(f), as proposed to be amended and which is the subject of controversy, sits in relation to 1(e), (g) and (i). The proposed amendments are shown in italics and underlined, for clarity:

The only issues of construction relate to the amendments to EP539 and I deal with them in the next section.

Abbott maintained two objections against the proposed amendment of EP539. The amendments are said to extend protection and to lack clarity and precision.

Dexcom drew my attention to the following passage from the judgment of Birss J in Hospira v Genentech [2014] EWHC 3857, where he addressed this objection:

“106.

This rarely comes up at trial in the UK, no doubt because the law is clear and usually easy to apply. The correct approach is to compare the scope of the claims as granted with the scope of the claims as proposed to be amended. In both cases the scope is that of the claims properly construed in accordance with the Protocol. If the proposed amended claim covers something that would not have been covered by the granted claims then the prohibition is engaged.

107.

Usually to make the argument good the person challenging the amendment needs to identify a concrete thing which did not fall within the scope as granted but which would fall within the scope after amendment if the amendment was allowed. If such a thing cannot be identified in concrete terms, that is usually an indication that there is no extension. Because the prohibition is absolute, the thing need not be commercially realistic.”

The allegation here concerns integer 1(f). However, Abbott contended the amendment needed to be considered against the backdrop of integers 1(e), (f) and (g), to which I add 1(i) and the fact that 1(f) sits in the pre-characterising portion of the claim.

The parties were agreed that the amendment is intended to introduce a reference to predictive alarms. The question is whether, on EP 539’s true construction, it introduces a restriction to predictive alarms, Dexcom’s case, or a change to predictive alarms, Abbott’s case.

Abbott’s argument is that the unamended claim did not require a predictive threshold but rather a real-time glucose threshold. On that basis, a system which had only a first real-time alarm and a second predictive alarm would not have infringed. The amendment changes the second threshold from a real-time glucose value to a predictive glucose value. Now that system with a first real-time alarm and a second predictive alarm would infringe.

Dexcom submit that the unamended version encompassed a variety of “thresholds” as the second threshold, whether real-time or predictive for, as I understood it, the following two reasons:

In their Opening, Dexcom acknowledged that the language in integer 1(f) as amended ‘is a little ungainly’ but submitted that it was ‘perfectly clear’: the ‘real time glucose value’ in question refers to a predicted future real time glucose value, and the claim requires determination, at a given time, of whether the user’s real-time glucose value is predicted to meet a second threshold level within the given ‘predetermined time frame or horizon’ following that given time.

There is no question that the specification of EP539 proposes various possibilities including current and predictive alerts, as, for example, in [0078]. But that does not assist in interpreting the claim which is directed to a specific combination and not to every possibility contemplated in the specification. In my view, the interpretation of the unamended claim, integer 1(f) is clear. That integer plainly refers to a current evaluation of the sensor data, giving rise, in integer 1(g) to a current alert or alarm.

Thus, EP539 claim 1 as granted is to a system with a continuous analyte sensor including two current alerts. One of the current alerts is settable (integer 1(e)) and the other is fixed (integers 1(f) & (j)).

The acknowledgment that the language in the proposed amended integer 1(f) ‘is a little ungainly’ is an understatement. To refer to a ‘predicted future real time glucose value’ is an oxymoron. The value must either be evaluated in real time (i.e. it is an evaluation of the current state of affairs) or, as I have pointed out at paragraph 512.xii) above, a predicted future value is calculated based on a number of glucose values (not simply or only the current value) and assessed against the relevant threshold.

For all these reasons, I conclude that the proposed amendment does extend the protection of EP539. Abbott’s argument, as set out in paragraph 523 above, is correct.

A patent claim must be “clear and concise”: §14(5)(b) of the Patents Act 1977. Abbott contend that the proposed amendments to claim 1 of EP539 result in a claim lacking in clarity for three reasons:

Dexcom argued that Abbott were able to admit infringement without struggling with the clarity of the claims when doing so. However, the fact that Abbott, in the circumstances of this action, were able to admit infringement does not mean that the Skilled Person, having read EP539, would not be left scratching his or her head as to what this claim meant. It is not difficult to specify whether a threshold is for a current value or for a predicted value. I conclude the proposed amended claim lacks clarity.

On validity, Abbott contended that there was a primary issue which arose on each attack and each piece of prior art namely the feature of claim 1 of both patents of a fixed predictive alert in combination with a current, user-settable alert. Abbott contended that feature is disclosed and/or obvious in light of all the prior art. In summary:

For their part Dexcom disputed the alleged lack of novelty and attacked the obviousness case as driven by hindsight. Hindsight also formed part of their resistance to the novelty attacks since on anticipation, Dexcom made the same point in relation to each citation:

‘The novelty attacks rely, in summary, on a cobbling together of bits and pieces from the disclosure supplemented by unjustified inference; there is no clear and unambiguous disclosure of all the features of the claims of EP159/539.’

For this reason, it is necessary to examine the disclosure in each document with care but before doing so, I must ensure I am oriented correctly.

The point I just referred to from Dexcom is, of course, the point made by the TBA in T/396/89 UNION CARBIDE/high tear strength polymers [1992] EPOR 312 at para 4.4 (as referred to by Lord Hoffmann’s speech in Synthon’s Patent [2005] UKHL 59 at [23]):

Dexcom also reminded me:

Brauker 2007 (or simply Brauker) is a US patent application published on 6 September 2007, entitled “Transcutaneous Analyte Sensor”. It is a long document and much of it is not relevant. Abbott identified a series of ‘key passages’ to which I refer below. To ensure that the Skilled Team would read all these various extracts together and as disclosing a single system, it is necessary to examine how the various aspects fit together.

After some brief introductory paragraphs, the ‘Summary of the Invention’ in Brauker covers many paragraphs from [0005] to [0103]. The invention is summarised in nine aspects, and each aspect is then described in individual paragraphs as ‘an embodiment of the [xth] aspect’.

Abbott relied on teaching from the first to fourth aspects, so I will summarise how these aspects are described, starting with the first aspect:

[0005] In a first aspect, a system for monitoring a glucose concentration in a host is provided, the system comprising a continuous glucose sensor configured to produce a signal indicative of a glucose concentration in a host; and a receiver operably connected to the sensor, wherein the receiver comprises a user interface, and wherein the receiver further comprises programming configured to calibrate the signal, to display a graphical representation of the calibrated signal on the user interface, and to display a directional arrow indicative of a direction and a rate of change of the calibrated signal on the user interface.

The second aspect concerns a device and the third aspect a method, for essentially the same purposes. Thus, the second and third aspects both conclude in the same way as the first aspect.

In a similar fashion, the fourth to sixth aspects are for a system, a device and a method all concerned with predictive alarms:

[0033] In a fourth aspect, a system is provided for monitoring glucose concentration in a host, the system comprising a continuous glucose sensor configured to produce a signal indicative of a glucose concentration in a host; and a receiver comprising an alarm, wherein the receiver is operably connected to the sensor, wherein the receiver further comprises programming configured to estimate glucose data for a future time, and wherein the receiver comprises programming further configured to trigger the alarm when the estimated glucose data for the future time is above or below at least one predetermined threshold.

I need not discuss the seventh to ninth aspects, because they are concerned with calibration.

Once each aspect has been stated, the ensuing paragraphs in the Summary then add additional features. Thus, as Abbott submitted, in relation to the “first aspect” (described at [0005] – [0018]), Brauker 2007 discloses an analyte monitoring system with a user-settable current glucose alarm at [0010] – [0012], and a predictive alarm “when the estimated glucose value for the future time is below a pre-determined threshold” (at [0013] - [0015]).

Abbott also correctly identified that the same current and predictive alarms are described in relation to a second and third aspect at [0021] – [0026] and [0028] – [0032], respectively.

Amongst the key passages which Abbott relied upon, they then moved to the fourth aspect. At [0035] Brauker 2007 states that “In an embodiment of the fourth aspect, the predetermined threshold [for the predictive alarm] is user-configurable” ([0035]).

The Detailed Description starts at [0182], divided by various headings. The first heading is ‘Definitions’ and it suffices to note the definition of ‘clinical risk’ in [0234]. In common with the other definitions, it is defined as a broad term, but concludes with an example: ‘In one exemplary embodiment, clinical risk is determined by a measured glucose concentration above or below a threshold (for example, 80-200 mg/dL) and/or its rate of change.’ This exemplary range appears many times and is often accompanied by the alternative range of 55-220 mg/dL.

I can skip over many of the following headings until ‘Dynamic and Intelligent Analyte Value Estimation’. The paragraphs under this heading (which run from [0610]-[0688]) describe various methods/algorithms for estimating predicted glucose values. The next section is headed ‘Input and Output’ and is mostly concerned with the presentation of the output from the previously described algorithms. As Abbott submitted, at [0689] – [0694] Brauker 2007 provides further detail on predictive alarms. It describes “clinical risk alarms” which involve an alert provided to a patient during a time of existing or approaching clinical risk ([0691-2]) or if there is minimal or no possibility of avoiding the clinical risk ([0694]).

[0696] then introduces Fig 41, which looks like this:

FIG. 41 is stated to be an illustration of the receiver in one embodiment showing an analyte trend graph, including measured analyte values, estimated analyte values, and a zone of clinical risk, in which 500 is a high threshold, 502 the low threshold ‘which represent boundaries between clinically safe and clinically risky conditions for patients’. The clinical risk zones 504 ‘are illustrated outside of these thresholds’. [0697] continues:

In one exemplary embodiment, a normal glucose threshold for a glucose sensor is set between about 100 and 160 mg/dL, and the clinical risk zones 504 are illustrated outside of these thresholds. In alternative embodiments, the normal glucose threshold is between about 80 and about 200 mg/dL, between about 55 and about 220 mg/dL, or other threshold that can be set by the manufacturer, physician, patient, computer program, or the like.

Similarly the clinical risk zones outside those thresholds can be “set by a manufacturer, customized by a doctor, and/or set by a user via buttons” ([0698]).

Abbott acknowledge that Brauker does not explicitly state that the thresholds for the clinical risk zones are the same as those used for the clinical risk alarms but submit that would be the skilled reader’s understanding. I agree.

The central dispute was over the meaning of ‘set by the/a manufacturer’ in [0697-8].

In his written reports, Dr Palerm set out his view that the Skilled Team would read the words ‘set by a manufacturer’ in those paragraphs to refer to the option that the threshold was fixed and not adjustable, in contrast to the option of customisation by a doctor or user.

In cross-examination, Dr Palerm was first asked about the passage in [0035] where it is stated the predetermined threshold is user-configurable. It was put to him that ‘you infer that there is an embodiment that is not user-configurable. That’s your point, right?’ To which Dr Palerm agreed. Later, he was challenged on his view of [0687-8], on which he maintained his view that ‘set by the manufacturer’ means/implies fixed.

In relation to the word ‘set’, Professor Oliver took the view that it does not necessarily mean the threshold cannot be set again, pointing to the fact that it does not say ‘fixed’. He maintained this view in cross-examination, which showed he made the same point on both Shariati and Brauker. He was not deterred by being reminded of the CGK that there were CGM devices which had a combination of user-settable alerts and alerts that were set/fixed by the manufacturer, as in the STS-7.

The issue of what a piece of prior art discloses to the Skilled Person/Team is one for the Court and not the experts. Nonetheless, the issue was well tested in the evidence.

For the same reasons as I give in relation to Shariati (see paragraph 569 below), I do not agree that the Skilled Team would read Brauker as Prof Oliver did. In fact, I consider the Skilled Team would see that Brauker was covering every possible option: set by the manufacturer, physician, patient, computer program and/or user includes ‘fixed by the manufacturer or physician’ but also those situations where the manufacturer sets a default value which can be changed by the physician or user, or even where no default value is provided and the physician or user are forced to set a threshold. I cannot see any reason why Brauker would have wanted to exclude any of the possibilities.

Therefore, I consider Prof Oliver’s reading that Brauker is limited to his ‘set, with the option to reset’ meaning requires a strained reading of the document.

It therefore follows, in my judgment that, Brauker discloses user-settable current alarms and fixed-threshold predictive alarms, and the two types of alarms in combination. As Abbott submitted, it therefore discloses the inventive concept of the Dexcom patents.

As Abbott submitted, claim 1 of each patent has one or two additional features. As to those:

I did not understand Dexcom to identify any other features of claim 1 of either Patent which were not disclosed in Brauker. I therefore find that Brauker anticipates both EP159 and EP539 (as amended).

Shariati is a US patent application published on 30 July 2009, entitled “Systems and Methods for Processing Sensor Data”. It is written in the same style as, and much of the disclosure is similar to, Brauker 2007 (including much that is not relevant to this case). Dexcom is identified as the assignee. Abbott identified the key passages they relied upon as follows, along with their submissions:

This is where the main dispute arose. Abbott submitted this presents two options to the skilled team: either fixing the threshold (by programming it into the computer), or making it user selectable. Language such as “programmed into the computer or user selectable” can only be referring to the two options of fixed and user-settable thresholds respectively, because there is only one alternative to “user selectable”, namely “fixed”. Abbott’s position was supported by Dr Palerm’s evidence. As on Brauker, his view was not shaken in cross-examination.

Professor Oliver interpreted the expression differently, in effect that both options were user selectable.

In cross-examination, Prof Oliver accepted that Shariati was referring to two alternative approaches. But it became clear that two matters underpinned Prof Oliver’s view:

Abbott submitted that Prof Oliver’s interpretation is completely untenable, contending it ignores the fact that Shariati is self-evidently referring to these two well-known options: (i) fixed by the manufacturer, (ii) settable by the user. There is no reason why a skilled team would treat what is there said in any other way. It makes no sense to read “programmed into the computer” as referring to a user selecting a desired threshold when “user selectable” is provided as the alternative.

In his written evidence, Dr Palerm considered the two options to be true alternatives. The challenge in cross-examination was based on the STS-7 Users Guide (2007) which, by way of example, talks of ‘your programmed alert levels. Your default high and low glucose alerts are set at 80mg/dL and 200mg/dL but can be changed to fit your personal diabetes goals (see Section 7.1).’ Dr Palerm said that any user-settable glucose alert has a default value which can then be changed by the user if necessary.

Having listened carefully to Professor Oliver’s answers in cross-examination, at the conclusion of his evidence I asked him about a passage in Shariati at [0363]. My question was posed in the context of Shariati’s abstract identifying that Shariati claimed systems and methods for calibrating a continuous analyte sensor. I asked him whether he could identify any reason why Shariati would have wanted to exclude fixed [predictive] alarms as working with their calibration method (since that was the point in dispute). In answer, he referred to what he had already said about anxieties about where the fixed threshold would be and what that would mean in terms of risk-benefit for the user, but agreed there was no explicit exclusion in Shariati.

I am entirely satisfied that the Skilled Team reading Shariati would not have the use of ‘programmed’ in the FreeStyle Navigator Guide or STS-7 Guide in mind. Instead, they would read the ordinary language and conclude Shariati was presenting two alternatives: either the threshold is programmed into the computer (fixed) or user selectable (from a range of values). This covers all the possibilities, and I am unable to find any reason why Shariati would have wanted to exclude the possibility of a fixed threshold (whether for a current or a predictive alarm).

In summary, in my view, Shariati discloses (inter alia) user-settable current alarms and fixed-threshold predictive alarms, and the two types of alarms in combination. It therefore discloses the inventive concept of the Dexcom patents.

Dr Palerm also explained that Shariati discloses the temperature correction feature claimed in EP159, and his evidence on that point was not challenged.

Dexcom did not identify any other points of distinction. Accordingly, I conclude that Shariati anticipates both EP159 and EP539 (as amended).

In case I am wrong on Brauker and Shariati, I proceed to determine Abbott’s case of obviousness.

Dexcom characterised obviousness as the central dispute on these patents. They accept that the inventions are relatively simple and straightforward to implement once they have been described. Their answer to the obviousness attacks is that the unimaginative skilled team reading Shariati, Brauker, the Navigator Guide, or the STS-7 Guide in October 2012 simply would not have arrived at a CGM system with a user settable current hypoglycaemia alarm and a fixed-threshold predictive hypoglycaemia alarm.

Dexcom reminded me of the following points in the authorities, none of which were disputed and I accept them.

The approach is that set out in the decision of the Supreme Court in Actavis v. ICOS [2019] UKSC 15 at [52] – [73], with its endorsement at [62] of the statement of Kitchin J as he then was in Generics v. Lundbeck [2007] EWHC 1040 (Pat) at [72]. Obviousness should be addressed at the level of the generality of the claims, see Shenzehn Carku v NOCO [2022] EWHC 2034, [78].

Dexcom drew particular attention to the following points from Actavis:

There is a difference between cases in which expectation of success is in issue and cases where the question is simply whether the idea is obvious. In Schering-Plough v Norbrook Laboratories [2006] FSR 18 at [35], Floyd J:

“An invention may simply consist in an idea which, once it has been conceived, is one which will obviously work. For those cases a party attacking the patent only needs to show that the idea was an obvious one. But there are other cases where the invention involves something more than the bare idea, because it is not immediately apparent that the idea could be made to work. In these cases the attacking party needs to show something more: that it was obvious to have the idea and to try it to see whether it would work.”

In cases where it is obvious that an idea will work, the invention resides in the idea alone, not in any perceived difficulty of enablement (see also Rovi Guides, Inc v Virgin Media Limited [2015] EWCA Civ 781 per Floyd LJ at [18]).

The Court of Appeal in Teva v Leo [2015] EWCA Civ 779 at [29] emphasised the importance of assessing the question of obviousness by reference to what real-life skilled people would think and do.

When considering that question the presence of uncertainty and unfamiliarity is relevant. That is because it can be, not so much the presence of challenges that puts people off trying but the absence of firm knowledge and experience that means the conception of modifying a piece of prior art would not come readily to mind. See Lord Justice Jacob in Unilever v Chefaro [1994] R.P.C. 567 at 587; applied by Meade J. In Fisher and Paykel Healthcare Ltd v Flexicare Medical Ltd [2020] EWHC 3282 (Pat) at [47].

Expanding on that point, Dexcom submitted that an idea is inherently more likely to suggest itself to the skilled addressee if his or her mind is already “primed” to appreciate the benefits which it may deliver; conversely, if the skilled addressee’s mind is not “primed” – or is actually attuned to problems with which the idea might be associated – then it is less likely that the idea will occur at all. In Unilever Plc v Chefaro Proprietaries Ltd [1994] RPC 567, Jacob J (as he then was) considered at p.587 three technical reasons put forward by the patentee as to why a particular step had not been taken before, all of which were dismissed by the defendant as “paper tigers”. The Judge held:

‘I think there is something in these points. It is not so much that they would put people off trying: it is that without firm knowledge and experience that particulate labels will travel, will not agglomerate or stick, the conception of their use does not come readily to mind.’

When seeking to avoid hindsight it is important not to allow it to infiltrate the problem which the skilled addressee is deemed to be dealing with when they consider the prior art. While, as discussed above in relation to EP223, it is perfectly acceptable to proceed on the basis that the skilled addressee picks up the prior art with a problem which is part of the CGK in mind (and when it is not suggested that identifying that problem forms any part of the inventive concept of the patent), it is important that the skilled addressee is not given artificial pointers to specific aspects of the prior art’s disclosure.

The CIPA Guide gives further a useful illustration of way that “signal” becomes deceptively easy to extract from “noise” when the circumstances which led up to an event are viewed with hindsight at §3.40:

‘A classic warning against unintended but inevitable hindsight appears in a book by Diane Vaughan, The Challenger Launch Decision (University of Chicago Press, 1996) at 69-71. It is referred to, inter alia, by Roy Marsh, “The Continuing PSA debate” [2010] CIPA 59. Professor Vaughan explains that a problem that was ill-structured becomes well-structured after an event (in that instance a disaster, but equally the making of an invention), as people look back and reinterpret information ignored or minimised prior to the event that afterward takes on new significance. Information strung together in post-event accounts can present a coherent set of signals that was not characteristic of the situation as it existed prior to the event. The result can be a systematic distortion of history that obscures the meaning of events and actions as it existed and changed for the participants in the situation at the time the events and actions occurred. (Professor Vaughan’s emphasis) Making an invention is by definition an ill-structured problem whereas the task of examination of a patent application or deciding on an objection of lack of inventive step against a granted patent is a well-structured problem because the invention has become known. There is the same risk of deriving a coherent set of signals where none existed prior to the invention. Even the selection of a primary reference may be a product of hindsight and risks distorting history in the manner suggested by Professor Vaughan.’

I accept all these points, and the point made by Professor Vaughan in relation to the Challenger disaster is a useful addition to ensure we guard against hindsight creeping into an obviousness analysis.

Dexcom’s final point was that where an idea is said to be obvious the question of why it has not been done before is a relevant consideration, see Jacob LJ in Technip France SA’s Patent [2004] EWCA Civ 381, [2004] RPC 46 at [122]:

“The question ‘why was it not done before’ is always a powerful consideration when considering obviousness, particularly when all the components of a combination have been long and widely known.”

Abbott made no particular submissions on the legal principles, contending these patents called for a straightforward application of the well-known principles.

Thus, a critical aspect of this case so far as Dexcom was concerned, was establishing the correct context against which the unimaginative Skilled Team read and considered the prior art.

Dexcom developed what at first sight appeared to be a powerful hindsight attack on Dr Palerm’s approach to these Patents. Since it applies across the board, it is convenient to summarise this attack here.

Dexcom submitted that Dr Palerm’s evidence in chief effectively boiled the options available to the Skilled Team down to a 2x2 grid:

It was common ground that all but one of the boxes in this grid (blue) were notionally “ticked” – i.e. present in CGK commercial devices – at the priority date. Dr Palerm’s argument was essentially that it was obvious to tick the fourth (red) box.

Dexcom submitted that hindsight infected this approach in several ways:

Dexcom criticised Dr Palerm for not acknowledging in his written evidence the risk of hindsight. They also submitted that he had taken as his starting point the particular combination of alarms and thresholds disclosed in the Patents (cf. the 2x2 grid). Counsel put to him and he agreed, a variety of other options. He said he did not discuss all these other options in his report because to have done so would have added a lot of material not directly relevant to these Patents.

The force of all Dexcom’s criticisms of course depend on the particular circumstances. If the invention involved a significant departure from the prior art, and if hindsight has to be used to get to the invention, that is determinative. But the hindsight card can also be played in situations where the invention was obvious.

As already noted, the STS-7 Guide is the user guide for Dexcom’s STS-7 device, published in 2007, and it is common ground that the STS-7 device itself and the user guide would be CGK.

As Abbott submitted, the STS-7 Guide is very similar to the STS Guide which I have analysed in the context of EP627. The key points of relevance to the Dexcom patents are the high and low glucose alarms and alerts:

The only difference between the STS-7 and the alleged inventive concept of these Patents is the fact that this product did not have a predictive alarm. As noted above, Dexcom was a bit behind others in actually introducing predictive alarms (of any kind) into its products. However, Abbott submitted that any skilled person looking at the STS-7 device as described in the STS-7 Guide would appreciate at once the usefulness of adding this feature to it, for the following reasons:

The only reason Prof Oliver advanced to suggest that this would not be an obvious way of proceeding is his insistence on a “mindset” on the part of his “Skilled Clinician” that would set them against the use of fixed, rather than user-settable thresholds, against the use of predictive alarms due to concerns over accuracy, and against adding additional alarms due to concerns over alarm fatigue.I agree with Abbott that there was no evidence to support the existence of such a mindset within real skilled teams at the priority date. Prof Oliver’s views were directly at odds with the evidence of what real teams and real devices were doing at the priority date:

Professor Oliver’s evidence on mindset fell apart in cross-examination. All he could say of his supposed “mindset” was that it “may” or “would” lead the clinician to advise the team to focus on accuracy rather than a fixed predictive alarm as a first priority. Even then, the lack of conviction was clear when he said that it “is not necessarily entirely obvious that it is the next important step”.

No-one who was an actual product designer could say that there was a “mindset” against fixed threshold alarms when these featured in some of the leading products in the market.

The position is no different in relation to Brauker/Shariati even if I am wrong that they explicitly disclose a fixed predictive alarm.

This is the user guide for Abbott’s FreeStyle Navigator CGM device, published in 2007. As with the STS-7, it is common ground that both the Navigator device and the user guide would be CGK.

Abbott argued that the key points were as follows:

Thus the only difference between the Navigator and the inventive concept of the Dexcom patents is that the Navigator does not include a predictive alarm with a fixed, rather than a user-settable, threshold. Abbott submitted it would be obvious for the skilled team to include a fixed threshold predictive alert in a CGM device, in light of the Navigator Guide:

As Abbott pointed out, Prof Oliver accepted that adding a fixed predictive alarm would be entirely straightforward to implement, but that his only answer to the case that it would be entirely obvious to do so was his reliance on a “mindset” against using a fixed threshold for hypoglycaemia.

Again, since I have found there to be no mindset, I accept Abbott’s analysis.

The use of a conversion function to correct for the effect of temperature on glucose sensor readings was CGK at the priority date. It is disclosed in Brauker and Shariati. Prof Oliver accepted that including such a function would have been standard practice for CGM devices at the priority date.

This integer simply requires that the indicator for the predictive alert is different from the indicator for the current alert. It is obvious, if not inevitable, that a device with both alerts in operation would indicate to the user which of them had been triggered. Prof Oliver did not suggest otherwise.

Dexcom’s amendment to claim 1 would add the following integers at the end:

This requires the device to display upper and lower boundaries delimiting a target range, which are different from upper and lower thresholds used for high and low glucose alarms. This was done in the Navigator in the following way (see p119 of the Navigator Guide):

The target range is shown by the shaded region, displayed alongside a user’s glucose trend data. The boundaries for the target region were different from the thresholds of the Low and High Glucose Alerts. Prof Oliver acknowledged that this feature in the Navigator satisfies the requirements of integers 1(k) and (l) of EP539.

Dr Palerm’s view is that this feature is also disclosed by Brauker. Prof Oliver disputed this and quibbled over Dr Palerm’s interpretation of the relevant passages in the prior art (although as noted at paragraph 560.ii) above he accepted that the embodiment shown in figure 45 of Brauker does show a target zone). Prof Oliver did not suggest that the visual display features conferred any inventiveness or offer any challenge to Dr Palerm’s view that they do not.

In any event, this was a feature of a CGK device. On that basis, Abbott submitted there can be no invention at all in adopting it for a device developed from any of the pleaded prior art starting points. I agree.

As mentioned above, one of Dexcom’s points was to pose the question: if the particular combination of alarms claimed in these Patents was obvious, why did no one use that combination before? Dexcom pointed out that in the 12 commercial CGM systems marketed over the more than 13 years between the first such product and the priority date, not one used the claimed combination of alarms. Dexcom sought to reinforce the point by pointing out that this combination first appeared in the Freestyle Libre 1 (although a flash glucose monitor and not a ‘true’ CGM device), but the first true CGM device to use the combination was the Dexcom G6 in 2018.

However, the evidence made it clear that designers in this field operated under a number of constraints. As well as the regulatory constraints, designers had to keep in mind that the users of their existing systems could be put off adopting a new device if radically different to the one they were used to. Developments were preferably incremental. Furthermore, different companies followed different design tracks. Yet further, the evidence established that the time between design idea and marketing of a new CGM system featuring that idea could be lengthy.

In my view, all these points robbed the question of any significance in the particular circumstances of this case.

Dexcom also relied on:

However, the underlying point is that I was persuaded that the Skilled Team effectively had a wide range of options for alarms from which they could choose their particular selection. The selection might well be influenced by existing and previous products from their Team/their employer; the features of competitive products; the desire to have points of distinction, as well as all the other influences – regulatory, ease of use, etc. The wide range of choice did not, however, result in the claimed combination being inventive, in my view.

It is appropriate to return also to mention Dexcom’s other arguments against obviousness, including in particular the hindsight attack on Dr Palerm’s evidence. I kept all these in mind when assessing the allegation of lack of novelty and obviousness of these Patents and reaching provisional conclusions on each allegation over each piece of prior art. The conclusions stated above are no longer provisional but final. Notwithstanding Dexcom’s hindsight attack (which on its own appears powerful, provided CGK matters are ignored), I have concluded it has no force in the circumstances of these Patents.

This was pleaded as a conventional squeeze on obviousness. Abbott pointed out that in so far as Dexcom were running a ‘mindset’ case, EP159 and EP539 offer the skilled reader no reason why a fixed predictive alert is appropriate (or more appropriate than a user-settable one) despite the supposed thinking of the skilled reader. The supposed drawbacks are not addressed at all (let alone solved). Nor is any assistance given in selecting what threshold to use, or for making a more accurate CGM, nor any reasoning as to why a predictive alert is appropriate despite the achievable level of accuracy. If (as Dexcom contended) the skilled person would not contemplate a fixed predictive alert, prior to reading the patents, they would not do so after reading the patents either – with the result, so Abbott contended, that the patents would make no technical contribution and would be insufficient. I think it is fair to say that the insufficiency plea has served its purpose and I need say no more about it.

Here I summarise the result on each Patent.

For the reasons explained above, I find EP627 anticipated by the STS Guide, but not obvious over Bunte. If valid, the Dexcom devices would have infringed.

Claim 1 of EP223 is anticipated by Gejdos but is not obvious over Lebel. Dexcom’s Gillette argument fails. If Claim 1 is invalid, claims 7/9 are obvious. If EP223 were valid, then on my construction, Dexcom would not infringe but on the alternative construction, Dexcom would have infringed.

On EP539 I find the proposed unconditional amendments not allowable because they extend the protection and also on the ground of lack of clarity.

EP539 as amended and EP159 are anticipated by each of Brauker and Shariati. Even if I am wrong about that, those Patents were obvious over each of Brauker, Shariati, STS-7 Guide and the Navigator Guide. If either Patent had been valid, infringement was admitted.