A legal and practical guide to developing mobile medical applications (‘‘apps’’): navigating a potential minefield

Megan Emma Smith¹

19 Meynell Gardens, E9 7AT 07525 432915, London

Corresponding Author: megan.smith@doctors.org.uk

Journal MTM 5:1:52–61, 2016

doi:10.7309/jmtm.5.1.8

---

---

 

A legal and practical guide to mobile medical application (“app”) development in the United Kingdom, and the United States Europe: navigating a potential minefield

Overview

Apple opened its App Store in July 2008. In the intervening years over 30 billion applications, or “apps”, have been downloaded. Apple hosts more than 30,000 “Medical and Healthcare & Fitness” apps ranging from those that are purely fitness and exercise related to those that are tantamount to medical devices. Whilst the overall percentage of medical apps available for download is relatively small, they are, due to the sheer size of the market, quite high in number. In addition to the rise in fitness and health technology use on smartphones and other devices, the advent of a wave of wearable devices has given rise to myriad opportunities for people to manage their own health and share their information in real time with their own healthcare professionals.

So what is the rub? Relatively little information about safety, quality control and regulatory compliance is provided by app developers. They often make claims of medical or quasi-medical functionality but then seek to disclaim liability for such functionality in the small print of their user conditions. In addition to app development by non-healthcare professionals, today’s health workers are designing their own apps for in-house use and wider circulation by fellow professionals and by their patients. These innovations will surely be a major method of delivering healthcare in the coming century and beyond. We must embrace and encourage their development but we must do so with open eyes and an awareness of the practical, legal and regulatory responsibilities that arise. This article seeks to address those issues in an accessible manner suitable for those with a non-legal background.

Is your app a medical device?

In the European Union the Medical Device Directive² (the “MDD”) provides guidance about whether an app is a medical device and, if it is, the implications that has for you as an app developer.

What is the definition of a medical device?

A medical device includes any software that is intended to be used for diagnostic and/or therapeutic purposes.³ This includes the diagnosis, prevention, monitoring or treatment of any disease, injury or handicap. It also extends to anything that is involved in the control of conception or the investigation, replacement or modification of anatomy or of a physiological process

There was debate for a time about whether computer code alone (such as that used to produce apps) could possibly amount to a medical device. The European Commission has since made clear that standalone software (which would include apps) with a “medical purpose” may qualify as a medical device.⁴

The Medicines Health and Regulatory Authority (the “MHRA”) is the body which governs the regulation of medical devices, including medical apps, in the UK. Its role is to ensure compliance with the MDD and it has issued additional guidance to help developers decide whether their app amounts to a medical device.⁵ The main points of this guidance are:

• • If software is purely a record archiving and retrieval system it is unlikely to be considered a medical device.

• • If software includes a module that interprets data or performs a calculation, then it is likely that this module will be considered a medical device.

• • Decision support software will generally not be considered a medical device if it exists to provide already existing information to enable a healthcare professional to make a clinical decision. However, if it performs a calculation or the software interprets or interpolates data and the healthcare professional does not review the raw data, then this software may be considered a medical device.

• • The MHRA also states that if an app contains the following words or phrases in the description of its intended use then it is likely that it will be considered a medical device: amplifies, analyses, interprets, alarms, calculates, controls, converts, detects, diagnoses, measures or monitors.

Standards to be met if the MDD applies to your app

The standards to be met essentially depend on the risk that an app that constitutes a medical device poses to health.⁶ Class I includes most non-invasive, relatively low risk devices and is likely to cover most apps. Class IIa devices are low to medium risk devices such as hearing aids, ECG machines and so on. Class IIb devices are medium to high risk devices such as infusion pumps and ventilators. Class III devices are high risk and include devices such as intravascular catheters, stents and prosthetic heart valves.

Safety requirements

Unsurprisingly, the MDD requires devices to be designed and manufactured in such a way that they do not compromise the clinical condition, health or safety of patients, users or others.⁷

Risk reduction/elimination requirements

App manufacturers must eliminate or reduce risks to patients and users insofar as is possible and, insofar as it is not, must take protective measures (e.g. by incorporating alarms) and inform users of residual risks that they have not been able to deal with.⁸

Performance requirements

Devices must achieve the level of performance intended by the manufacturer and must be designed and manufactured in such a way that they are suitable for the functions of the device as specified by the manufacturer.⁹

Quality requirements

The manufacturer must ensure that their device is robust enough to withstand the normal stresses of use. More specifically, the manufacturer must apply the criteria in the prescribed quality system and evidence in writing that this has been done.¹⁰ The manufacturer must also affix the “CE” marking to indicate quality standard compliance.¹¹ The main part of this process involves lodging an application for assessment of the device with a “notified body” (the MHRA in the UK).

What if someone uses the app for a purpose for which it was not designed or intended?

The MDD states that the intended purpose of a medical device means the use intended “according to the data supplied by the manufacturer on the labelling, in the instructions and/or in promotional materials”.¹² You must, therefore, be extremely clear about this in the information that you supply for prospective users on whichever app store(s) you elect to use.

What if the app is provided free of charge?

Whether or not you charge for your app, the MDD is clear that if you make it available for download and it is a medical device then you must comply with its terms.

The United States’ position on apps as medical devices

What is a medical device in US law?

In the US, medical devices are governed by the Federal Food, Drug, and Cosmetic Act (“FFDCA”)¹³. The definition of a medical device is contained in section 201(h) and includes:

“..an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is–
(1) recognized in the official National Formulary, or the United States Pharmacopeia…,
(2) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
(3) intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.”

If the device is intended to be used as an accessory to an already regulated medical device or will transform a mobile platform into a regulated medical device then it will be considered to be a medical device. The Food and Drug Administration (“FDA”) will only enforce the FFDCA in relation to apps that are medical devices which pose a risk to a patient’s safety if the mobile app were to fail to function as intended. The FDA categorises these apps as “mobile medical apps”.

Most medical mobile apps do not fall within this definition and the FDA does not regulate them. Apps that do meet the definition are stratified according to the risk that they pose to the public.

There are three categories:

• (i) Class 1 (low risk devices)–only the “general controls” referred to below apply and the FDA will exercise “enforcement discretion” which means, in effect, that it will not enforce the requirements of the FFDCA.
• (ii) Class 2 (intermediate risk) – the “special controls” referred to below will apply.
• (iii) Class 3 (high risk)–these apps must meet the requirements of the FFDCA and will require pre-market approval by the FDA.

What is a mobile app?

This is defined as a software application that can be run on a mobile platform or a web-based software application that is tailored to a mobile platform but is executed on a server.

Who is a manufacturer?

Anyone who initiates specifications, designs, labels, or creates a software system or application for a regulated medical device is considered to be an app manufacturer. Those who exclusively distribute apps, for example Google Play and the Apple iTunes App Store, are not manufacturers.

Where a person prepares specifications or procures product development services from other individuals or entities (e.g. from a third party app developer or, in theory, an app incubator though these are not specifically mentioned) who then create an app, the person who initiated and developed the original specifications is considered to be the manufacturer.

Software/app developers who simply transform the author’s specifications into a mobile medical app are not manufacturers. Similarly, mobile platform manufacturers (e.g. smartphone producers) are not considered to be medical device manufacturers simply because their platform can be used to run a regulated app.

It is important to note that a creator of a mobile medical app that provides access to the medical device’s function through a website subscription or other similar means is considered a mobile medical app manufacturer.

Licensed healthcare professionals who manufacture a mobile medical app for use in their professional practice and do not promote it to be generally used by others outside their practice are not manufacturers.

The FDA recommends that manufacturers of all mobile apps that might meet the definition of a device follow the “Quality System” in the design and development of their app and initiate prompt corrections to their mobile medical apps, when appropriate, to prevent patient and user harm.

Types of regulated apps

Apps that are an extension of a medical device

Apps that connect to existing medical devices in order to control them or to use them to monitor a patient or to analyse or display the device’s data will be considered to be devices and must comply with the controls applicable to the connected device. Examples include:

• • apps that control the inflation and deflation of a blood pressure cuff through a mobile platform;

• • apps that control the delivery of insulin by a pump by transmitting signals to the pump from the mobile platform.

Mobile medical apps of this type are considered an accessory to the connected device.

Attachments, display screens or sensors that transform a mobile platform into a device

Apps like these may transform the mobile platform into a regulated medical device and are required to comply with the device classification associated with the transformed platform. The connection can be direct (wired) or indirect (wireless). Examples given by the FDA include:

• • attachment of a blood glucose strip reader to a mobile platform to function as a glucose meter;

• • attachment of ECG electrodes to a mobile platform to measure, store, and display ECG signals;

• • a mobile app that uses the built-in accelerometer to collect motion information for monitoring sleep apnoea; and

• • a mobile app that uses the sensors on a mobile platform for creating electronic stethoscope function.

Apps that become a regulated device by performing patient-specific analysis, diagnosis or providing treatment recommendations

Mobile apps that analyse or interpret data sourced from another medical device must meet the FDA’s requirements as they are considered to present the same level of risk to patients whichever platform they run on. Such apps include those that use patient-specific parameters to calculate a drug dose or create a dosage plan for radiation therapy.

Mobile Apps for which the FDA intends to exercise “enforcement discretion”

The FDA will not enforce FFDCA requirements in relation to mobile apps that:

• • Help patients manage their disease themselves without providing specific treatment or treatment suggestions;

• • Provide patients with tools to organise and track their health information;

• • Provide easy access to information related to the patient’s health condition(s) or treatment(s); or

• • Automate simple tasks for health care providers.

Regulatory requirements

Class I devices

The US Code of Federal Regulations (“CFR”) General Controls apply to Class I devices. These include:

• • Establishment Registration¹⁴ – provides for formal registration of the entity (company, individual, partnership, etc.) that produces a device;

• • Medical Device Listing¹⁵ – various pieces of information relating to those responsible for the device must be registered, for example: name, address, web address, contact details;

• • Quality System Regulations¹⁶ – these require device manufacturers to establish and maintain a quality system that is appropriate for the specific medical device(s) designed or manufactured. They do not prescribe how a manufacturer must produce a device, rather they provide a framework for manufacturers to develop to help to ensure that their products consistently meet applicable requirements and specifications. In addition, app manufacturers must verify and validate their apps and the mobile platform they plan to use to ensure safe and effective distribution, installation, and operation;

• • Labelling Requirements¹⁷;

• • Medical Device Reporting¹⁸ – these provisions require manufacturers and importers of medical devices to submit reports to the FDA whenever they receive or become aware of information that suggests that a device they market may have caused or contributed to a death or serious injury (or has malfunctioned in a way that would be likely to cause or contribute to a reportable death or serious injury if the malfunction were to recur);

• • Premarket Notification¹⁹ – any entity that is required to register its establishment (see above) must submit a premarket notification submission to the FDA at least 90 days before the introduction, or delivery for introduction, into interstate commerce for commercial distribution of a device intended for human use²⁰; and

• • Reporting Corrections and Removals²¹ – if a device manufacturer or importer has to correct a device or remove it from circulation then they must submit a written report to the FDA.

Class II devices

Class II devices must comply with the General Controls above as well as a set of Special Controls. Special controls are usually device-specific and include:

• • Performance standards;

• • Postmarket surveillance;

• • Patient registries;

• • Special labelling requirements;

• • Premarket data requirements; and

• • Guidelines.

In some cases Class II devices also require premarket approval.

Class III devices

Class III devices must comply with the General Controls and gain premarket approval from the FDA.

App ownership and intellectual property rights

Intellectual property rights fall into one of four main categories: copyright, patents, trademarks and trade secrets. In relation to apps, copyright is the primary right of relevance though the others may also come into play at some point in the lifetime of an app.

Copyright

Copyright exists in the expression of an idea rather than in the idea itself. In the context of software and apps this means that copyright exists in the written source code (the “human readable” computer programming language) and in the object code (the “computer readable” string of binary numbers into which the source code is translated). Copyright is owned by the author of the code and it arises as soon as the code is written: it does not have to be claimed or registered. There are a number of special situations that need be considered in the context of copyright in apps relating to the rights and obligations of:

• • Employees;

• • Third party contractors (i.e. app developers); and

• • Company founders and shareholders.

Employees

There is an exception to the general “copyright ownership by author” rule already described which relates to employees: if programme code is written by an employee in the course of his or her employment then, subject to any specific agreement to the contrary, the employer will be the owner of the copyright. Employee-created works of this nature are sometimes known as works “made for hire”.²²

It is important to note that the works “made for hire” presumption only applies to copyright. It does not apply to other intellectual property rights that might exist in the work (trademark rights, patents and so on). It is therefore crucial to ensure that each employee signs an agreement that assigns to you ownership of all other intellectual property in work that s/he creates whilst employed by you.

Third party developers

The question of ownership is less clear when app development is not conducted in house but is outsourced to a third party contractor such as an app developer. In these circumstances the usual position is that the developer who has been commissioned to produce the app will own the copyright in the programme code notwithstanding the fact that the commissioner of the work has paid for it to be done. This position can be altered by contract and it is vitally important that this issue is considered and addressed before the developer is engaged.

You should enter into a written agreement with the developer which assigns ownership of the intellectual property rights in the app to you.²³ If you do not then the developer will own those portions of the app which s/he developed on your behalf. You would simply have an implied licence to use the end product which may result in restrictions that are unacceptable to you.

Sometimes a third party developer may want to retain ownership of some of the code that it creates in the course of developing your app. This is usually code that is not specific to your app and could be used by the developer in the future to develop its own apps or to develop apps for others (sometimes referred to as “generic” code). You should approach any such requests with caution. The developer should provide you with a clear written description of code that it considers to be generic. It can be difficult for those who are not fluent in the language of programmer’s code to determine whether code is generic or essential so you may need to take expert technical advice in such circumstances.

A slightly different scenario occurs if the developer includes any of its own existing code in your app. If it does then it should grant you a broad and irrevocable licence so that you can market your app with their code included in it.

If the developer intends to use any code that belongs to another party in your app (for example, code that it has developed for someone else), you must obtain written assurances from them in relation to the following: first, the third party developer must give you a clear description of the code it plans to use and obtain your permission to include it; and second, it must obtain the written permission of the owner of the code to utilise it in your app.

Finally, there is a legal obligation on you under the MDD to exercise sufficient control over the developer to implement post market surveillance and take corrective action where necessary (e.g. bug reporting and resolution). The contract between you and your developer should therefore consider these issues, and the design of the app may need to include the ability to notify users or even terminate use if corrective action is required.

Founders: avoiding the Facebook problem

Often more than one person is involved in the idea, design and/or development of an app. This may relate to the underlying concept, the coding of the app or the architecture and interface of it. It is wise to ensure that an express agreement is concluded which states clearly the expectations, obligations and entitlements of all of those who have been involved. These provisions may range from matters such as the right to use, distribute and/or modify the code for the app through to the right to remuneration from its proceeds. The clearer all parties are at the outset about app ownership, the sharing of revenue and the decision making process going forward the better.

Copyright in open source software

Many app developers now use varying amounts of open source software (“OSS”) in the development of apps. OSS is source code that is made generally available and can be used by anyone subject to the terms of a licence determined by the copyright holder (usually the original author or, more often, authors since much OSS is the result of collaborative work). The terms of each licence vary between OSS developers.²⁴ It is important to ensure that if your developer plans to utilise OSS in your app that it is aware of the licence terms which apply to the particular OSS and that they and you comply with them.

The terms of the most frequently used OSS licence²⁵ allow app developers to modify, copy and redistribute the licensed work or any derivative version of it. Those using the OSS can charge a fee for their app but cannot impose further restrictions on the rights granted by the OSS licence. This is a significant problem for iOS apps, as Apple’s App Store terms prohibit modification and redistribution of apps by those who have downloaded them. Apple’s restrictions effectively mean that if you use OSS that is covered by the GNU General Public Licence (“GPL”) then it impossible for you to comply with their open use terms whilst at the same time observing the terms of the GPL.

Given the potential problems associated with using OSS, it is vital that any third party app developer you use is clear with you about their use of OSS. They must keep detailed records of the OSS components used in the production of your app and the licence terms which apply to them.

Trademarks

An app can infringe the trademark of another in a number of ways. First, the name of your app might be similar to an existing trademark. Second, the “look and feel” of your app might be very similar to that of a recognised trademarked app. Finally, you may have included an existing trademark in the marketing or description of your app such that the end user is likely to be confused about which is which.

It is worth considering trademark registration²⁶ in order to protect intellectual property rights in your app further. It is also wise to search the register of trademarks²⁷ before launching your own app to ensure that you are not inadvertently infringing the trademark rights of another.

Patents

App developers should also consider whether their app warrants an application for patent protection²⁸. There are a number of requirements that must be satisfied in order that patent protection be granted and full consideration of them is beyond the scope of this article. However, if your app performs a new process or carries out a known process in a novel way then it is worth seeking expert advice. In addition, app developers should take care to ensure that they have not themselves infringed the patent rights of another party in developing and marketing of their own app.

Infringing the intellectual property rights of others

If your app uses copyright protected material belonging to another (e.g. images, video or sound) then it is vital to ensure that appropriate permissions and licences have been obtained prior to its launch.

End user license agreements and default App Store terms and conditions

The agreement that governs the terms of use of your app by those who download it is called the End User License Agreement (“EULA”). Apple’s App Store terms and conditions contain a standardised EULA which will apply to your app by default if you do not use your own EULA²⁹ (which is fine provided that it accords with the other terms and conditions contained in Apple’s standard terms and conditions). If you elect to go down this route (and there are good reasons for doing so) then Apple has a set of “minimum terms” that you must include.³⁰ Other platforms advise you to draft a EULA though they do not include default terms in the way that Apple does. The standard approach for both Google Play and the Amazon App Store is for the developer to include a link to their EULA in the purchase information for the app.

Personal liability and ways to avoid or reduce it

The primary way of reducing and/or avoiding personal liability for anything that may go wrong with your app is to form a limited liability company through which to conduct your app development. The advantage in this approach is that it can help to shield the personal assets of the individuals involved from any liability that the company incurs.

Usually when a company is formed each of its founding members assigns whatever rights s/he has in the app to the company. Shares of ownership in the company would then be issued and an agreement concluded that all future work carried out on the app would be the property of the company in return for a salary and/or profit share.

Anyone involved in the development of the app who is not to be a shareholder should be treated either as an employee or an independent third party contractor.

Whatever the status of an individual involved in the development of your app, you should include a non-disclosure clause in their contract to ensure that they maintain strict confidentiality while your app is being developed.

Data protection and security requirements

App developers and their apps are subject to the same regulations as any other business from a data protection perspective. If an app involves the processing of personal information then the app developer must ensure that it complies with relevant data protection legislation in the UK.³¹ As a bare minimum this means that you must be open with users of your app about how their personal data will be used and for what purpose.

The security of patient related information is critical. Some organisations address this by supplying employees with pre-configured devices that have been designed to meet their institutional security requirements. Alternatively, an institution may only permit access to local wireless network and may prevent any additional software from being installed on the device beyond that approved and/or maintained by the organisation.

UK consumer protection law: the Sale of Goods Act 1979

In 2009 the government commissioned a report which addressed the question of consumer rights in digital products³². The remit of the report specifically included apps. The key rights of consumers who purchase goods are contained in sections 12 to 15 of the Sale of Goods Act 1979 (the “SGA”).

These provisions automatically imply terms into contracts for the sale of goods whether or not they are expressed in the contract itself. These terms cannot be excluded at all including by disclaimers contained in the agreement for download of an app or in the “front page” of the app itself.³³ Whether this statutory framework applies to computer software and, more specifically, apps has given rise to a great deal of legal debate.

One argument is that “goods” for the purposes of the SGA must be physical, tangible items. As such, any purely digital product does not qualify unless it is supplied on a physical, tangible medium such as a disk or a memory stick. Whilst this is the position in law in England at Wales at present,³⁴ the Scottish, American and New Zealand courts have adopted a different approach. In addition, the UK government has laid a draft Consumer Protection Bill before Parliament which specifically extends the SGA rights to digital content which would include apps.

If passed this bill will require digital content to be:

• • Of satisfactory quality;

• • Fit for purpose;

• • As described by the provider of the content; and

• • Supplied by someone who has the right to supply such content.

All of these terms will arise automatically (i.e. they do not have to be written into a contract or be the subject of any discussion between the parties). Breach of these contractual conditions will give rise to a wide range of remedies including monetary damages. Again, the proposed new provisions cannot be excluded, limited, disclaimed or waived.³⁵

Operating system licence terms

The providers of most operating system platforms require app developers to agree to the terms of a licence prior to making their app available for download by the public. Examples are Apple’s iOS Developer Program License Agreement and Google’s Google Play Developer Program Policies³⁶ These agreements are detailed and contain provisions which relate to the operation and marketing of the app coupled with obligations relating to content, privacy and post-download support.

How to manage app use within your organisation

There are different ways of promoting app use within an organisation. Some healthcare institutions have established a private app store for distribution of apps developed or approved by it.

If your aim is to promote and market your app through Apple’s App Store (i.e. to make it available to run on an Apple device running Apple’s iOS operating system) then it must be approved by Apple. This can take some time. One way that private organisations rather than individual app developers can work around this requirement is to enter into an “Enterprise Agreement” with Apple.

Other options are available for non-Apple based apps. For example, Google, Blackberry, Nokia and Microsoft app stores offer terms which are not as stringent in terms of app approval.

Jurisdictional issues

This article has examined the regulatory and legal issues from the standpoint of the law of England and Wales and, more broadly, from the perspective of European Union law. If your app is marketed, sold or simply made available in other countries then you will need to consider and comply with the relevant laws of those other jurisdictions.

The trans-national, cross-border nature of today’s technology means that an app which is lawfully developed in one country could easily infringe a third party’s intellectual property, consumer protection and/or data protection related rights in another.

Conclusion

Innovation in medicine should be encouraged and nurtured. The future of healthcare is likely to continue to be revolutionised by the rapid pace of technological change and advancement. Healthcare professionals should be an integral part of this progress and development. It is hoped that this article will help those interested in these developing apps for use by their patients and colleagues to proceed on a surer footing.

References

1. Megan Smith is an anaesthetist based at the Royal Free London NHS Foundation Trust (Pond Street, London, NW3 2QG) and is a former practising barrister. She was called to the Bar of England and Wales in 1993 and is a member of The Honourable Society of Lincoln’s Inn. The author has had no support from any organisation for this work, has no financial relationship with any organisations that might have an interest in this work and has no relationships and is not engaged in any other activities that might have, or have the appearance of, influencing this work.

2. 93/42/EEC

3. For the MDD to apply the device must not achieve its “principal intended action” in or on the human body by pharmacological, immunological or metabolic means

4. It should be noted that only the purpose as described by the manufacturer of the product is relevant here. The actual name of the device has no bearing on the intended purpose of the device.

5. http://www.mhra.gov.uk/Howweregulate/Devices/Software/index.htm

6. Guidelines Relating to the Application of the Council Directive 93/42/EEC on Medical Devices MEDDEV 2. 4/1 Rev. 9 June 2010.

7. Annex I, paragraph 1 of the MDD

8. Annex I, paragraph 2 of the MDD

9. Annex I, paragraph 3 of the MDD

10. Annex II to the MDD.

11. Details of what must be included in the application are contained in paragraph 3 of Annex II. guidance relating to this process can be obtained from the MHRA at http://www.mhra.gov.uk/Howweregulate/Devices/Registrationofmedicaldevices/index.htm

12. Article 1(2)(g) of the MDD

13. Section 201 [21 U.S.C. 321].

14. 21 CFR Part 807

15. 21 CFR Part 807

16. 21 CFR Part 820

17. 21 CFR Part 801

18. 21 CFR Part 803

19. 21 CFR Part 807.

20. See also http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/HowtoMarketYourDevice/RegistrationandListing/default.htm.

21. 21 CFR Part 806

22. This term has a formal legal definition in US law but the principle applies equally in the UK.

23. The agreement needs to specify that the developer assigns ownership of the work (not simply a right to use it) with immediate effect. Statements that are not as clear as this have been interpreted in the US as a (probably unenforceable) promise to assign ownership at some future date.

24. The Open Source Initiative currently lists over 50 licences on its web site http://www.opensource.org/licenses

25. The GNU General Public License https://www.gnu.org/licenses/gpl.txt.

26. http://www.ipo.gov.uk/types/tm/t-applying/t-apply.htm

27. http://www.ipo.gov.uk/types/tm/t-os/t-find/tmtext.htm

28. http://www.ipo.gov.uk/types/patent/p-applying.htm

29. See for example http://www.clickfree.com/software/clickfree/eula/

30. https://www.apple.com/legal/internet-services/itunes/appstore/dev/minterms/

31. http://ico.org.uk/for_organisations/data_protection/the_guide/the_principles

32. Consumer rights in digital products A research report prepared for the UK Department for Business, Innovation and Skills by Professor Robert Bradgate, Institute for Commercial Law Studies, University of Sheffield.

33. Unfair Contract Terms Act 1977 section 6 and SGA 1979.

34. International Computers Ltd v St Albans District Council [1996] 4 All ER 481

35. Unfair Contract Terms Act 1977 section 6 and SGA 1979. Draft Consumer Rights Bill 2013 sections 1(6) and 49.

36. https://www.eff.org/files/20100302_iphone_dev_agr.pdf. http://www.apple.com/legal/sla/docs/xcode.pdf.