For the automotive industry, 2016 saw a tremendous amount of activity regarding self-driving cars. CES 2016 was dominated by autonomous vehicles from NVIDIA’s car chip to BMW. The Ford Motor company also successfully tested its vehicle in snowy conditions and Google suggested that it would spin off its self-driving car project as a separate company. With all of this activity centered in the US, Asia and Germany, many have questioned whether the UK can compete in this evermore- competitive industry. The answer is a resounding yes. The legal and economic platforms in the UK are well-suited for the development, deployment and on-going investment in this ever-evolving field. UK Business Secretary Sajid Javid said: “Making driverless cars a reality is going to revolutionse our roads and travel, making journeys safer, faster, and more environmentally-friendly. Very few countries can match our engineering excellence in the automotive sector or our record on innovative research, and this announcement shows we are already becoming one of the world’s leading centres for driverless cars technology.”

Recently, the Vehicle Technology and Aviation Bill was introduced in the UK Parliament. In introducing the Bill, Transport Secretary Chris Grayling said, “Automated vehicles have the potential to transform our roads in the future and make them even safer and easier to use, as well as promising new mobility for those who cannot drive. In addition to various insurance provisions, the Bill includes measures to increase the number of charging stations, requirements on providing access to information regarding their location, hours of operation, fuelling options, cost (and methods of payment), charging methods (Tesla uses a different connector to Nissan, for example) and whether they are in use. The government hopes that the issues in the Bill will be addressed quickly in order to position the UK as a leader in autonomous transportation.

To be sure, however, there are challenging issues to address. At the top of the list are the various regulatory and cybersecurity issues surrounding Vehicle-to-Vehicle (“V2V”) communications – one of the key technologies required to achieve the various safety goals expected of this new technology. The legal landscape of the autonomous vehicles in the UK, including the product liability, cyber-security, and intellectual property issues, are of paramount concern and are the focus of the below.

A. Product liability

1. Introduction

As with the other jurisdictions discussed in this Paper, in the UK, vehicle manufacturers may be liable to those injured by their vehicles. This includes strict liability for defective products under the Consumer Protection Act 1987 (the “CPA”), liability for the tort of negligence and even, in limited circumstances, liability for breach of statutory duty.

Liability depends on determining what caused any particular injury and thereby allocating fault. This already is potentially complex in vehicles with sophisticated technologies, such as anti-lock braking, given that many different parties may be involved in a particular accident, including the driver, the manufacturer, a component manufacturer and other drivers. It will become far more complex when an autonomous vehicle (“AV”) is involved as the definition of driver is less clear and both hardware and software may be responsible. The UK government currently proposes to rely on a fault-based approach combined with existing product liability law as the basis for liability of AVs. This reflects a pragmatic, step-by-step approach relying on the ability of English law to adapt to new circumstances. Accordingly, in this paper, we set out how existing English law would apply to AVs and how it may evolve to meet changing requirements.

DSRC is a set of protocols and standards for dedicated vehicle to vehicle and vehicle to roadside communications using wireless technology. DSRC has many advantages for the operation of AVs, but also creates additional risks and sources of liability. In this Paper, we also consider the application of English product liability law to DSRC.

2. Sources of liability

AVs contain technology that are not found in other vehicles. Although these innovations are meant to allow us to enjoy the benefits of a driverless or nearby-driverless vehicle, they also could be the source of new liability:

• a “bug” in the software running the AV. These bugs can be divided into the following categories:

Logic Error: the code does not do what the programmer intended it to do; this is perhaps the type of error that is most associated with a software bug and is most clearly characterised as a defect in the product;

Implementation Error: the code does not correspond to the intended specification for that piece of the software; that is, it works as the programmer meant it to work, but this is not what the programmer was meant to implement. This may also be a defect in the specification and finding it requires analysing not only the code but also the written design parameters. An error in the parameters of the design often occurs where those parameters are set by legislation or regulation.

Corner Case: the code (and the underlying specification) fails to address a particular situation encountered by the AV and the resulting behaviour in that situation is inappropriate. This is a bug particularly apposite for AVs that will face unpredictable, real world situations. It may be unclear whether a Corner Case constitutes a defect.

• a deliberate choice by the software. For instance, it chooses to swerve into another car in order to avoid a pedestrian who stepped into the road.
• a defect in the specialist equipment used by the AV, such as its sensors, so that the software receives incorrect or inadequate information about the real world or its commands are not put into effect accurately by the vehicle.
• a fault in the handover of control between the AV and the driver: this is only an issue for AVs that are not fully automated.

In addition, there are a number of different entities that may be responsible or partly responsible for the cause of any injury or damage involving an AV:

• manufacturer
• driver
• owner
• seller
• repairer
• component manufacturer/supplier
• data provider

Owing to the additional complexities around AVs, it is possible that in the UK new laws will allocate responsibility for injury when an AV is involved. For instance, manufacturers may be liable irrespective of what caused the accident – effectively, a form of no-fault insurance. This solution may speed acceptance of AVs but has obvious risks for manufacturers.

At present, the UK government is not proposing to make any wholesale changes to the laws on product liability and negligence to accommodate AVs. Limited changes to the vehicle insurance regime are the subject of consultation by the government, including:

• extending compulsory insurance to cover manufacturers’ and other entities’ product liability.
• requiring this additional insurance to cover injuries to the driver as well as passengers and third parties.
• developing a system to classify AVs to which this additional insurance requirement will apply.

These changes are intended to close gaps in the existing car insurance regime and to reduce the likelihood of compensation being delayed by complex product liability litigation. However, they also demonstrate that the underlying allocation of liability is likely to remain unchanged. They are discussed more fully below.

3. Strict liability for defective products

Under the Consumer Protection Act 1987, manufacturers are strictly liable for damage caused by “defective products.” A product is defective if “the safety of the product is not such as persons generally are entitled to expect.” In determining this, the courts will take into account instructions and warnings that accompany the product and “what might reasonably be expected to be done with the product.” There are various defences, including compliance with UK or EU law, and a ‘state of the art’ defence: “that the state of scientific and technical knowledge at the relevant time was not such that a producer of products of the same description as the product in question might be expected to have discovered the defect.”

A preliminary question is what level of safety people are entitled to expect from today’s AVs. One point of comparison is the average level of safety attributable to a human driver – that is, the level of driving ability that would not be negligent for a human driver. In fact, public opinion appears to demand a much higher level of safety from an AV – little short of perfection. The highest possible standard is to demand zero accidents subject only to the ‘state of the art’ exception. Of course, no AV will be perfect and accidents and injuries will inevitably occur. Where on the spectrum between a human driver and a perfect driver the standard is set and how well defined that standard is could affect the feasibility of AV production by manufacturers.

Most Logic Errors and Implementation Errors will fall within the definition of defects, to the extent that they compromise safety. However, given the extremely complex nature of AV software, manufacturers could argue that a particular Logic Error or Implementation Error was not discoverable – the ‘state of the art’ defence. This is most relevant for software based on self-learning algorithms, such as artificial neural networks, where the bug is not expressly implanted by a programmer but arises endogenously from the operation of the learning algorithm. In that case, the manufacturer could argue that the AV behaved correctly through extensive testing and it was effectively impossible to predict the particular circumstance that led to injury. This amounts to an argument that the learning algorithm was the “state of the art” and so not defective, even if it failed in a particular situation. The success of this argument is likely to turn on expert evidence about the algorithms underlying the AV software and the statistical robustness of tests.

A Corner Case, the failure to program for the particular situation that gave risk to the accident, will be a “defect” if the following can be shown. Firstly, the failure of the AV software must compromise safety in a way that would not be anticipated. For instance, a sudden puncture while driving on the motorway is a rare occurrence, but if it is not dealt with appropriately by the AV software it may likely be found to be a Corner Case defect. But a simultaneous puncture of two tyres while driving on the motorway might be so rare that a failure of the AV software to react appropriately does not compromise the general expectation of safety.

Secondly, the Corner Case must fall within what might reasonably be expected to be done with the product. A failure to cope with unanticipated off-road conditions, for instance, may not be a defect unless the AV was designed for off-road use.

Thirdly, warnings or instructions given with the AV may limit liability for Corner Cases – although, in a fully automated AV, it is unclear what a passenger is supposed to do if an unanticipated situation arises, and so any warning that applies to normal operation of the AV may not be effective in limiting liability.

Where the AV is not fully automated, the transition between control by the software and the human driver is another potential source of defects. The limitation of strict liability for appropriate “instructions and warnings” may be relevant here. Specific training may be needed for human drivers interacting with partially automated AVs.

Finally, there is the novel case of a deliberate choice by the AV software to inflict injury or damage – presumably, in order to avoid inflicting worse injury or damage. One possible example is swerving into a car to avoid a pedestrian. Whether this is classed as a defect may be a complex question, dependent on questions of ethics and morality as well as law. It may also be studied empirically – MIT’s Moral Machine is a website that aims to build an understanding of practical ethics by asking users how they would decide when faced with a variety of moral dilemmas.

Some situations may clearly suggest a defect: the AV software chooses to swerve into a pedestrian in order to avoid damage to the car. Others will be more nuanced. There is no comparison with the actions of a human driver: an instantaneous reaction by a human is a matter of judgment that is not easily found to be negligent; the same reaction by AV software follows from a deliberate decision by a programmer to have the software react in that way to that situation. Therefore, if it does not conform to general expectations of “safety,” it may be defective.

4. Negligence

A manufacturer of goods has a duty of reasonable care owed to those who might foreseeably use those goods. In the case of AVs, this duty is likely to extend to passengers in the AV as well as other road users. A manufacturer will be liable in negligence if a person in one of those categories suffers damage as a result of its breach of this duty to take reasonable care.

Showing that the breach by the manufacturer caused the loss may involve allocating responsibility between the different entities listed in the Introduction. In particular, where a hardware component, such as a sensor, may be at fault, the cause of an accident may be the defective sensor, negligence in the incorporation of the sensor into the AV, a negligent repair or maintenance of the sensor, or insufficiently robust AV software that fails to anticipate possible sensor failure and transition into appropriate fail-safe modes.

These questions of causation already arise with existing semi-autonomous systems. Normally, the vehicle can be driven safely with these systems in a failed state – they will switch themselves off and ensure no adverse effects on the vehicle. This is a simple solution to avoid any negligence in the implementation of those systems causing an accident, but it is not available to a fully autonomous AV. Therefore, determining whether an AV is in breach of a duty to take reasonable care – or, to put it another way, what is the standard of reasonable care for an AV – is a novel question.

There appear to be two approaches. The manufacturer may argue that its extensive testing of the AV showed that the software reached an appropriate standard of driving ability and that this constitutes reasonable care by the manufacturer. The advantage of this approach is that it does not require extensive analysis of the software itself, only observation of how the software operates. The cost is in the time taken for extensive testing, although this may be a feature of AV software development in any case.

The second approach is an analysis of the software itself to verify that its behaviour is as desired and that it does not contain any errors. A manufacturer may argue that its extensive analysis of the software as well as the resources devoted to writing the software fulfil its requirement to take reasonable care.

In practice, a combination of both of these approaches may be needed to satisfy the standard of reasonable care. A logic error or implementation error that causes an accident may be sufficient to show negligence even if the error did not manifest during real-world testing and could only have been found by analysis of the code. Conversely, the only realistic way to discover Corner Cases in complex code is by extensive real-world testing.

Even with extensive testing and analysis, an AV will sometimes be faced with a novel situation requiring a split-second response. This is where any analogy with a human driver breaks down. A human driver will make a judgment in that split-second and the duty of reasonable care applied to that judgment will make allowances for the lack of reaction time. AV software will operate according to its programming. There will be no allowance for reaction time (other than the mechanical limits of the vehicle). The duty of reasonable care will apply to determine whether the novel situation was actually a Corner Case that should have been anticipated or whether the failure mode of the software when dealing with an unanticipated input was appropriate, i.e., was it fail-safe to a reasonable standard.

In other words, the burden of avoiding negligence largely shifts from the actions of the driver while driving to the process used for creation and testing of the AV software. This will involve a combination of the two approaches. To satisfy their duty to take reasonable care, manufacturers will need to develop expertise both in methodologies for creation and verification of real-time software and in statistical proofs of robustness of testing procedures. Inevitably, the outcome of this process will not always be successful – that is, there will always be accidents – but if manufacturers can show that the process itself was undertaken with reasonable care, they may still avoid liability for negligence. The path to risk mitigation for AV manufacturers may be to demonstrate a comprehensive audit of the development and testing process.

Once again, a key determinant of liability will be whether the overall outcome should be similar to that of the average non-negligent driver or set at some higher level. A standard of reasonable care implicitly accepts that the manufacturer is not liable for some accidents that are caused by the AV software falling below a higher absolute standard of care. It is not clear that this is consistent with public acceptance of widespread AV deployment.

5. Statutory liability

Manufacturers may be liable for breach of statutory duty, where a statute imposes a duty on the manufacturer and breach of that duty is actionable by an individual who has suffered damage as a result of that breach.

A product is not necessarily defective within the meaning of the Consumer Protection Act 1987 if it is in breach of a statutory or regulatory requirement. For instance, in Tesco v Pollard [2006] EWCA Civ 393, a child resistant cap was not defective because it was harder to open than a non-resistant cap, which was what people would generally expect, even though it was not hard enough to open to comply with the relevant statutory regulations on child resistant caps. Accordingly, breach of statutory duty may be a wider source of liability than a failure to comply with the Consumer Protection Act 1987.

A person who suffers damage as a result of a breach of a statutory or regulatory requirement will not always have a right of action against the person in breach of that duty. It will depend on the scope of the duty and whether courts determine that the legislation is intended to give a private cause of action to individuals. The use of AVs will doubtlessly lead to further regulations and these may be used to argue for private causes of action.

6. Liability for DSRC

As set out above, DSRC is a set of protocols and standards for dedicated vehicle to vehicle and vehicle to roadside communications using wireless technology. There are various implementations of DSRC in different jurisdictions and wide variation in their compatibility. Within the European Union, the European Committee for Standardisation (“CEN”) and the European Telecommunications Standards Institute (“ETSI”) have produced a number of standards on the operation of DSRC, including frequencies and bandwidths, but these also allow for optional frequencies covered by national regulation.

DSRC offers many potential advantages:

• platooning: organising vehicles into closely spaced formations with synchronised controls;
• warnings: from other vehicles or roadside transmitters, such as the presence of an obstruction around a hidden bend;
• efficient traffic flow: communication with other vehicles and traffic lights allows more efficient traffic flow through junctions.

A corollary of these advantages is that an AV be able to take action in reliance on communication received through DSRC. Where an AV reacts inappropriately to a DSRC message, this raises all the issues discussed above as to liability. However, there are other situations that only arise in the context of DSRC:

• Misunderstanding: An AV does not understand, or misunderstands, a message received from another AV, due to a failure of interoperability. For instance, an AV in a platoon receives a message to apply the brake but understands it as a message to apply the accelerator.
• Misinformation: An AV receives data that is incorrect. For instance, an AV receives a message that a traffic light is green when it is red.
• Malice: a hacker attempts to use DSRC as a vector to compromise an AV’s software.

In cases of Misunderstanding, it may be difficult to determine liability unless there are clear and unambiguous protocols for DSRC. Take the case where there are two rival protocols and a message sent using one is interpreted using the other. It could be argued that the fault is that of the receiving AV for not being cautious in interpreting an ambiguous message; it could be argued that the fault is the sending AV for sending a message that could be misinterpreted. It might even be argued that the author of the DSRC protocol or the operator of the DSRC system is at fault for enabling the transmission of ambiguous messages. Presumably, an AV would aim to be as cautious as possible when receiving messages to minimise any misunderstandings, but the nature of DSRC messages may make this difficult. For instance, if an AV receives a DSRC warning that there is a danger around the corner the cautious option may be to react to the message and apply the brakes, even if the message was sent using an ambiguous protocol.

Where there is Misinformation, the sender may be liable for negligent misstatement or negligent or fraudulent misrepresentation. The exact factual circumstances will determine whether liability may accrue. First, the receiver – or any other person injured or object damaged by the message – must be within the class of entities to which the sender owes a duty of care. Road users of all types are likely to be owed a duty of care by senders of DSRC messages. Secondly, it must be reasonable for the receiver to rely on the message. This may depend on the status of the sender, the content of the message and whether it is consistent with other sensor inputs to the AV.

For instance, a traffic light using an approved protocol is a reliable sender and a message that it is green is exactly the sort of message that might be relied upon. But if the AV can see the traffic light itself, it may still not be reasonable for it to rely on the message alone when it is inconsistent with the colour shown on the traffic light. Thirdly, action taken in reliance on the message must have caused the relevant damage.

In cases of both Misunderstanding and Misinformation, a further investigation may be needed to determine which legal entity is responsible for any liability that may accrue. Where the sender is itself an automated system, this may raise complex issues.

Finally, there is the case of Malice: the sending of a message topurposefully hack the AV. Cybersecurity is a concern for AVs generally, but is a particular problem for DSRC.

The need for very low latency and simple communication reduces the scope to impose security measures. In fact, DSRC generally allows messages to be accepted even without the basic handshaking protocols to verify identity of the other party. Accordingly, DSRC is a high risk channel of communication and the standard of care for AV manufacturers in dealing with DSRC messages may be correspondingly high.

Overall, while DSRC may bring benefits, it also adds a layer of complexity in determining liability for actions of AVs.

7. Conclusion

The operation of AV software will introduce a variety of novel and complex fact situations where manufacturers of AVs may be liable to road users. The current approach of the UK government is to allow the innate flexibility of English law to develop an appropriate response based on the existing principles of product liability.

The relevant principles include duties under the Consumer Protection Act 1987, a duty to take reasonable care to avoid liability for negligence and possible liability for breach of statutory duty arising from new regulations. We have set out here how these principles may evolve for AVs generally, also looking specifically at issues raised by DSRC. While the existing law is not inconsistent with the use of AVs, manufacturers will need to examine their development and testing regimes to mitigate product liability risk before widespread adoption.

B. Cybersecurity/Data protection

1. Introduction

At the EU level, the collection and use of personal data by manufacturers and other actors in the service chain of autonomous and connected vehicles is subject to the Data Protection Directive 95/46/EC (as amended) (“DP Directive”) and Directive 2002/58/EC on Privacy and Electronic Communications (as amended) (“E-privacy Directive” and together with the DP Directive, the “Directives”), by way of the local Member State regulations which implement them. Manufacturers of vehicles should already be complying with the Directives in relation to any personal data that they currently and are continuing to process. In general, they should use personal data fairly and lawfully for limited and specified purposes in a way that is relevant and not excessive. Personal data should be kept accurate, safe and secure, for only as long as is absolutely necessary and not exported outside the European Economic Area (“EEA”) without legal protection.

The above obligations are not new. The gathering and use of personal data in relation to driver-controlled vehicles however has often been limited and relatively uncomplicated. The development of autonomous and connected vehicles changes this. Such vehicles collect large amounts of personal data through various echnological means, including smart infotainment systems, data recorders, location tracking and vehicle to vehicle communication. Given the nature of autonomous and connected vehicles, this personal data will be passed on to a number of other parties. This increase in the collection and use of personal data means manufacturers will need to (i) take their obligations under the Directives more seriously; and (ii) engage with new data protection challenges presented by autonomous connected vehicles. We consider both of these points in further detail below.

2. Obligations and challenges

a. Privacy by design

Data protection and privacy considerations will need to be at the forefront of manufacturers’ and other service providers’ minds at each developmental stage. Such a “privacy first” approach is referred to as “privacy by design,” and will become much more important in order to avoid reputational damage, costly recalls or regulatory fines.

A critical part of “privacy by design” is the “privacy impact assessment.” This is a process that is used to identify the flows of personal information and track how it is obtained, used, retained and transferred by the autonomous connected vehicle. Based on this, potential data protection risks to the vehicle owner, the individual drivers, their passengers and other road users can be identified and assessed, allowing for appropriate solutions to be built in to the actual data collection, storage and sharing architecture and for user interfaces to alert users to the use of this data. This allows unnecessary data collection to be eliminated and privacy impacts to be assessed from as many angles as possible, including user consultations, so costly reworks or breaches can be avoided.

b. Transparency

Transparency is a key element of the DP Directive as it allows users to control how personal data is used. Manufacturers and other service providers will need to ensure that drivers are informed of and understand what personal data is being collected, how it is being used and who it is being disclosed to. This will need to be presented clearly and accurately – meaning that manufacturers will need to fully understand the flows of personal data.

This information is usually presented to individuals through a privacy policy. In general, if it is reasonable to expect that a driver or passenger (if the vehicle is automated collectively, a vehicle “user”) will understand how their personal data is used, it should be sufficient for manufacturers to simply make the privacy policy available for users to access, should they wish to do so. However, given the lack of familiarity users will have with automated connected vehicles and related technology, it will also be unrealistic to assume they understand how their personal data is being collected and used.

Manufacturers will therefore need to actively communicate and explain to users what is being done with their personal data. An effective method of communication will need to be deployed, especially given that it has been reported that only 16 percent of internet users read privacy policies and of that, only 20 percent actually understand them. Manufacturers will need to consider alternative methods to sufficiently inform users of this information, rather than using lengthy privacy policies. Some features in automated connected vehicles could assist with this. For example, the privacy policy could be presented on the infotainment screen with an interactive and layered approach, and “just in time” notices could be communicated to the user during the journey prior to the point at which certain personal data is collected.

c. Apportioning liability

Automated connected vehicles will also likely bring about further issues concerning contractual arrangements and apportioning of data protection responsibilities. Manufacturers will be partnering with developers (both hardware and software network providers), suppliers and business partners. For each arrangement, the data protection implications will need to be considered in detail. Robust data processor obligations will need to be employed given the increased risk that comes with the high volume of personal data collected. Joint or co-data controller arrangements will likely become more common, for example, during vehicle-to-vehicle communications. The manufacturer of the automated connected vehicle that is providing location data to another automated connected vehicle will be the primary data controller of that location data. The manufacturer of the automated connected vehicle receiving that personal data could, however, also be a co-controller of the personal data received. This is because the recipient would use that personal data for its own purposes, such as judging its own location in relation to the other automated connected vehicle.

Where such arrangements exist, data protection roles, responsibilities and liabilities will need to be clearly allocated to avoid joint and several liability for the other data controller’s breaches.

d. Export of personal data

Novel implications around the export of personal data should also be considered. Vehicles often cross international borders. An autonomous and connected vehicle originating in the EEA will be generating personal data relating to EEA individuals. Should this vehicle enter non-EEA jurisdictions and share this personal data by way of communicating with other autonomous and connected vehicles or local third parties, this will be an international transfer of personal data. Manufacturers will need to ensure that adequate export mechanisms are put in place to legitimise the transfer of such personal data.

e. Location data

In order to operate, autonomous connected vehicles need to collect location data. Amongst other functions, location data is used to identify the autonomous connected vehicle’s location in relation to other vehicles and for route planning (including saving a location, setting route preferences and identifying local points of interest). It is likely that the user will be able to be identified from such location data, either by itself or in conjunction with other personal data that the manufacturer holds. As such, location data will be subject to the DP Directive and the other implications discussed in this chapter.

The E-privacy Directive imposes additional requirements for the use and collection of certain types of location data. If the location data falls within the remit of the E-privacy Directive, specific consent to collect and use the location data will be required from the individual. The individual will also need to be informed about the type of location data processed (including the level of granularity, frequency that their location will be captured and how long that information will be kept for), the use and purpose of collecting the location data and which third parties it is passed to.

Currently however, the E-privacy Directive’s definition of location data is rather limited, and does not actually include GPS-based location data, which is what autonomous and connected vehicles are likely to use. Despite this, various regulators are increasingly viewing all types of location data as a sensitive subset of non-sensitive personal data. This is because location data can be particularly intrusive and revealing and can therefore allow for very specific targeting (see section (f) below for further considerations on this point).

As a result, regulators are beginning to expect that organisations treat all types of location data with the same safeguards and stringency as described in the E-privacy Directive. In relation to this and understanding the nature of all types of location data, a number of organisations are beginning to seek consent from users in relation to location data that does not fall within the E-privacy Directive. Manufacturers should be aware that while this is only best practice and not currently legally required in Europe (and that manufacturers should be able to rely on the fact that the use and collection of location data is required for them to perform their contractual obligations to the user), any secondary use of location data is likely to oblige manufacturers to seek consents from users. This is looked at further in section (f) below.

f. Consents

Consents from users will be required where the manufacturers are using and collecting certain types of personal data, or using personal data for certain activities.

Amongst other things, consent is required to process sensitive personal data (relating to race/ethnicity, criminal convictions, health, religious beliefs, political opinions, sex life and union memberships) and to send users unsolicited marketing materials. Manufacturers will need to consider this as part of their “privacy by design” approach and “privacy impact assessments.”

As mentioned above, location data can reveal intimate information about users. The history of trips made can provide private sensitive data about individuals , trips to certain places of worship or medical facilities. In order for the manufacturer to provide a complete service the collection of such data may be unavoidable.

In relation to marketing opportunities, the types of personal data collected by autonomous and connected vehicles is particularly valuable. For example, certain sensors may be able to tell whether a child is on board. Other sensors could potentially collect data about a user’s stress levels and general wellness. Businesses might seek to utilise this type of data, for example, to suggest parents pull off the road for local children-friendly offers or to stop over at the local spa to de-stress. Furthermore, location data could be used as a means to target the type of marketing provided to users: for example, local businesses transmitting advertisements to the autonomous connected vehicle when it is in within a five-mile radius.

It is no surprise that McKinsey & Company estimate that vehicle generated data may become a US$450-750 billion market by 2030.

Therefore, it is in the manufacturer’s interest to have as many users as possible consenting to the above. Under the DP Directive, consent must be freely given – specific, and informed. Manufacturers will need to create, trial and test their consent wordings and mechanisms to ensure that they are presented in a way that is not only transparent and comprehensible to the driver, but that will maximise the number of users that provide their consent. However, consent will only be given to trusted actors.

g. Necessary disclosure of personal information

Whilst carrying commercial benefits (as mentioned in section (e) above), personal data collected by autonomous and connected vehicles can also be valuable to legal/regulatory enforcement agencies. Regulation 2015/758 of the European Parliament (the “eCall Regulation”) must be complied with by April 2018 and requires new cars to be fitted with the “eCall” system. This system dials the European emergency number 112 and communicates the vehicle’s location to the emergency services as soon as invehicle sensors and/or processes (e.g., an airbag) detect a crash. This is an example of obligatory data sharing.

Manufacturers or other parties may be compelled by legal/regulatory enforcement agencies to disclose personal data that they are holding about users. For example, such agencies may demand the location history or travel patterns of a user over a certain period to establish their whereabouts. Such agencies may also demand access to a user’s personal data in order to track them if they were suspicious that the user may be involved in criminal activities. Manufacturers will need to communicate such possibilities to users as part of their transparency obligations (described at section (a) above).

h. Security of personal data

Given the volume of personal data being collected, data security will be critical and manufacturers will need to ensure that the technological components are built with regard to appropriate security levels. Given that automated connected vehicles are made up of a number of technological components and deploy a number of communication methods (Wi-Fi, Bluetooth, radio, GPS etc.), the potential for security breaches or hacking is high. It has recently been reported that the software in a number of Nissan’s electric ‘Leaf’ cars could be hacked, allowing the hacker to alter heating controls and see details of the driver’s journey.

From a data protection perspective, unauthorised access to and use of users’ personal data can cause real harm and distress to the individuals. A hacker could, for example, use details of a user’s journey history to determine when and what times they are away from home to plan a theft. Identity theft, credit card fraud, exposure of vulnerable or protected people are just some of the other potential scenarios of such access to personal data.

The DP Directive states that manufacturers must ensure that they employ appropriate technical and organisational measures against unauthorised or unlawful processing of personal data. This element will be an important factor in the “privacy by design” process. Manufacturers should note that such security measures are not limited to the automated connected vehicles themselves. For example, personal data of drivers will likely be held on the manufacturer’s systems. Therefore, manufacturers will need to ensure that data security is implemented at a much broader organisational level.  Physical and computer security, managerial measures and staff training are all key elements to minimise the threats and the subsequent fines, enforcements and reputational damage that could be suffered by the manufacturer.

3. Conclusion

The autonomous connected vehicle is an exciting reality. The collection of personal data is interweaved within each of its moving parts and is fundamental to its functions. Whilst access to this personal data presents new and great opportunities for manufacturers and other actors, the corresponding risks involved with its use must also be considered and addressed if users are to give manufacturers and other actors the permission they need for monetising secondary uses of personal data. A balance must be struck between providing users with the most personalised and bespoke service, and respecting their fundamental right to privacy.

C. Intellectual property

1. Introduction

The excitement surrounding the realisation of autonomous vehicles in the relatively near future has been felt in the UK for some time, and the UK considers itself one of the leading countries in this respect. The UK government predicts that the intelligent mobility market will be worth £900 billion by 2025 and is ramping up its investments to ensure it becomes a global centre in this space. In February 2016, eight projects were granted £20 million funding to develop the next generation of autonomous vehicles. Rewards from this investment can already be seen in the driverless car being tested among members of the public on a one kilometre loop of the pavement in Milton Keynes. Other projects include 40 miles of road being fitted with communications technologies to assist autonomous vehicles in Coventry and autonomous shuttles being tested at Heathrow Airport.

A sign of the gathering momentum in the UK for investment in autonomous vehicles is evident in the 2016 Autumn Statement. In the 2013 Autumn Statement, £10 million was invested to support driverless vehicle technology. But by the 2016 Autumn Statement the government announced £390 million to be invested in future transport technology, including £100 million investment in testing infrastructure for driverless cars. This theme seemed to continue on into the government’s 2017 Budget statement, in which it was announced that £270m million would be invested in 2017-2018 “to keep the UK at the forefront of disruptive technologies like biotech, robotic systems and driverless vehicles” – although for the automotive area, the fund seems to be initially intended for electric vehicles and clean technology, rather than core autonomous vehicle research.

Alongside government funded research programmes, which is led by the Centre for Connect and Autonomous Vehicles (“CCAV”), industry have invested heavily into research and development to create the initial technologies of autonomous vehicles, with continued efforts leading to improved technologies, new functionalities, better integrated systems and higher degree of automation. Off the back of this investment, companies naturally seek to protect their ideas and innovations. Intellectual property is an obvious tool. Through intellectual property rights, companies can enjoy a monopoly or receive royalty income with respect to a particular functionality. We describe the range of intellectual property rights and how they may be relevant in this nascent technical area.

2. Patent rights

Of the relevant types of intellectual property rights, patent rights may be the most obvious. At the heart of autonomous vehicles is new technology, and patent rights are designed to protect just that. Patent rights are also most visible and easy to enforce – being the only registered right that protects technology – with patent claims expressly setting out the ambit of the monopoly. The same cannot be said of unregistered rights, as described further below.

The opportunities for innovation in the autonomous vehicles space is vast, spanning multiple disciplines extending to a myriad of areas outside the autonomous driving infrastructure and technology as well. By way of example, with the ultimate vision that autonomous vehicles will be virtually accident-proof, research is underway to develop pedestrian friendly springy bumpers, cornerless car made of soft silicone, and bonnets with adhesive qualities. Those ideas, provided they are novel and inventive, should be patentable.

However, at its core, autonomous vehicle concerns include the automatic command of the steering wheel, based on deep learning and historical, past and present information captured by the radars/sensors and cameras of the vehicle, other such vehicles and the local infrastructure. In short, the technology at stake is the handling of a complex junction between cloud computing, networks, software, data and algorithms.

On the face of it, this spells dark clouds for those wishing to protect these types of innovation by way of patents. This is because patent law concerns the protection of products or processes, not abstract theories or ways of organizing human activities. For this reason, European Patent Convention (“EPC”), which governs the law on patent eligibility applied in the European Patent Office (“EPO”) prohibits the granting of patents for among other things, “mathematical methods,” “methods for doing business,” “programs for computers” and “presentation of information” in so far as the patent relates to those subject matters “as such.” However, there is a silver lining arising from this wording in that it leaves open the possibility of protecting inventions relating to such categories of inventions, provided they do not purely concern those categories. Although the substantive patent laws are not legally harmonised across the European Union (“EU”), they are all based on the EPC and the Courts of Member States often look to the case law of the EPO. The soon to be implemented Unified Patent Court (“UPC”) will also apply the law enshrined in the EPC.

In order to assess whether the invention is patent eligible, the EPO considers whether the invention solves a technical problem with the result that the invention falls outside the exception if it does. Determining patent eligibility in this regard is not easy, not least because the term “technical” is not mentioned in the EPC let alone defined, but because it is a notion that can have different meanings to different people.

Realising that such an obscure and vague concept fails to provide certainty, the UK Court has given “sign-posts” in an attempt to more concretely define what is required to satisfy “technical contribution” where inventions relating to computers are concerned:

• whether the claimed technical effect has a technical effect on a process which is carried on outside the computer.
• whether the claimed technical effect operates at the level of architecture of the computer; that is to say whether the effect is produced irrespective of the data being processed or the applications being run.
• whether the claimed technical effect results in the computer being made to operate in a new way.
• whether a program makes a computer a better computer in the sense of running more efficiently and effectively as a computer.
• whether the perceived problem is overcome by the claimed invention as opposed to merely being circumvented.

There is less guidance on how technicality can be found in patents relating to presentations of information, with the UK Court merely stating “what achieves patentability is some real world technical achievement outside the information itself.” For example, in assessing the patentability of Apple’s swipe to unlock invention, the court concluded that the invention was more than a mere presentation because it provided a technical effect outside the computer, namely an improved switch. As Human Machine Interface increases its importance for user experience of autonomous cars, “presentation of information” type patents may end up at the centre of a number of disputes, both in the form of EPO oppositions and litigation in the future.

All in all, inventions which lead to a better technical system, for example, the reduction of latency, efficient energy consumption, non-distracting and timely display of highway hazards could all be patent eligible depending on how the claim is scoped, even if this is facilitated by computer architecture, software, data structure, algorithm or presentation of information.

3. Standards

What drivers are to traditional vehicles, the digital network will become to autonomous vehicles in the future. This is because, as described above, autonomous vehicles are controlled by the interaction between its algorithms, software and the information it receives.

Much of the communication processes of autonomous vehicles will be based on existing and future telecommunications and transmission technologies. These technologies operate in compliance with a common set of standards that apply across Europe, to ensure interoperability between devices and to guarantee that such technologies work smoothly and reliably together. Thus, the same standards that are relevant in telecommunication networks will also be relevant in this context, and so too would the same Standard Essential Patents (“SEPs”) – the patents which will be infringed as a result of players having to comply with those standards.

Any company that owns patents that are declared to be SEPs, must licence them to others on Fair, Reasonable and Non-Discriminatory (“FRAND”) terms.

A new set of standards specific to connectivity of autonomous vehicles would also need to be established. These standards are needed to enable connected cars from different manufacturers, to communicate with each other and with road infrastructures. For this purpose, the European Commission has invited the development of technical standards and specifications for ITS within the European Standards Organisations in order to ensure the interoperability of ITS systems based on V2V, V2I, I2V and infrastructure-toinfrastructure (“I2I”) communications for the exchange of information (collectively referred to as Co-operative systems or “C-ITS”). Work on the Release 2 standardisation of C-ITS is underway which aims to extend to more complex uses and making improvements to Release 1 set of minimum standards which was completed in 2014.

The standard setting process is extremely complex, involving the contribution and input of a number of stakeholders, including of course, the industry and the consortia to which they belong. The European Standards Organisations need to take their contributions and opinions and co-ordinate the process. At the same time, international co-operation is being managed to achieve global harmonisation of standards in this area, in particular the USA and Japan, including their relevant Standards Organisations. The whole harmonisation process is also assisted at the international level by the International Telecommunication Union (“ITU”), the United Nations specialised agency for information and communication technologies.

As with the telecommunications space, relevant SEPs will follow from the standard development processes. Those in the automotive and tech space are currently active in the standard setting and negotiating procedure to ensure that their research and patents are captured by the standards. The size and quality of a car manufacturer’s SEP portfolio are likely to be crucial for future cross-licensing of SEPs. At the same time they would need to either make an alliance with, or seek a licence from entities which hold relevant SEPs for existing, established technologies outside their space, such as telecommunications.

4. Database right

The size of data gathered by autonomous vehicles will be gargantuan. Multiple numbers of radars/sensors, and cameras take in information to form a detailed picture of the vehicle’s surroundings on a constant basis. All this data will be pruned down (in accordance with say, an algorithm) to only the meaningful bits for storage and further processing, which, if arranged in some form of database, could attract database right.

For the purposes of database rights in Europe, the Directive defines “database” as “a collection of independent works, data or other materials arranged in a systematic or methodical way and individually accessible by electronic or other means.” A database right subsists if there has been “substantial investment in either the obtaining, verification or presentation of the contents” of the database. It is infringed if a third party extracts or re-utilises all or a substantial part of the contents without consent.

A number of cases have before failed to substantiate database right because the intellectual effort and skill in creating the data are not relevant in order to assess the eligibility of that database for protection by that right, but these cases concerned creating and determining a fixture list or list of runners and riders. It has been said that the distinction between ‘creating’ and ‘obtaining’ data, is not always so easy to make. However, it is more likely that, if data obtained from autonomous vehicles were arranged in a database as defined above, such a database would attract database right because the data would be comprised of records of pre-existing facts (such as images of the local environment at a certain time), just as the collection of data over a course of a football match was considered to be obtaining rather than creating data. This approach would accord with the objective of the Directive, which is “to promote and protect the investment in data ‘storage’ and ‘processing’ systems which contribute to the development of an information market against a background of exponential growth in the amount of information generated and processed annually in all sectors of activity.”

As described above, autonomous vehicles not only rely on data generated by itself to control that particular vehicle from moment to moment, but also utilise data from other vehicles past and present to influence its onward path. One obvious e.g for the use of this data is congestion avoidance; the more data points the vehicles receive, the better able they are to navigate traffic. This could result in the best-selling car companies having superior commands of their vehicles than rarer brands. If so, performance variation may arise depending on the location. A popular car in France which is capable of zipping across rush hour traffic in Paris could find itself struggling in London – unless some sort of data sharing is brokered among car manufacturers/data providers for autonomous vehicles. Even though this is just one example of many possible uses, it can be appreciated that data from autonomous vehicles could be extremely valuable. If that data is arranged in a database (as defined by the Directive), companies should be able to protect them under database right. The definition of database is not confined to typical arrangements of data provided the requirements are met. Previously, and relevantly for this area, topographic maps have been held to constitute a database.

5. Copyright

a. Copyright in a database

Carrying on with the database theme, the structure (as opposed to its contents) of a database or compilations of data can attract copyright independently from any database right if it “by reason of the selection or arrangement of their contents, constitute[s] the author’s own intellectual creation,” meaning originality. The CJEU has previously clarified that originality is satisfied when, “through the selection or arrangement of the data which it contains, its author expresses his creative ability in an original manner by making free and creative choices…By contrast, that criterion is not satisfied when the setting up of the database is dictated by technical considerations, rules or constraints which leave no room for creative freedom.”

In an altogether new “industry” like autonomous vehicles, there is scope to build a database which can attract copyright, because nothing is yet common place and the types of data available for collection are so vast. If there is sufficient intellectual effort into selecting and arranging that data into a database, copyright could subsist in it.

Copying all or a substantial part of such a database structure would constitute infringement.

For completeness’ sake, copyright protection provided under the Database Directive does not extend to their contents but this does not prejudice any rights subsisting in the contents themselves. Thus, contents such as images within a database can be protected by copyright, if, as in the case of databases, they are original in the sense that they are the author’s own intellectual creation. In a case concerning a portrait photograph, CJEU held that the requirement of intellectual creation meant that the author of the work had stamped the work created with his/her “personal touch.” Put this way, it is doubtful that images and video streams automatically captured by the autonomous vehicles and infrastructure (of surrounding environment, traffic, etc.) would qualify for copyright protection.

b. Computer programs

Computer programs and their source codes and object codes can be protected by copyright. This is harmonised in the EU by the 2009/24 Software Directive. Copyright protects the expression of the program (the code) from being copied – it does not protect aspects of computer programs such as the functionality, computer language or the format of the data files.

Interoperability can give rise to copyright issues because  achieving interoperability can involve copying the code that deals with the interface with another device (called Application Programming Interfaces, or “APIs”). However, the same Directive provides for exceptions to copyright infringement in relation to interoperability – allowing legitimate users of a computer program to reproduce and translate its code in order to make an independently created computer program to become interoperable with it, so that the different components can work together. This does not mean an API cannot attract copyright; a third party cannot copy and use the same API unless it is for the purposes of making its computer program interoperable with the device which uses the API.

6. Topography rights

Topography of a semiconductor product is defined as “a series of related images, however fixed or encoded; (i) representing the three-dimensional pattern of the layers of which a semiconductor product is composed; and (ii) in which series, each image has the pattern or part of the pattern of a surface of the semiconductor product at any stage of its manufacture. In accordance with EU law, topographies of semiconductor products are protected insofar as it is the “result of its creator’s own intellectual effort and is not commonplace in the semiconductor industry.” Some Member States may require the right to be registered. It is an infringement of the right to reproduce the topography or commercially exploit semiconductor products which uses the topography. In most cases, the term of protection is ten years.

There may also be qualifying provisions depending on the Member State. In the UK, topography right can subsist if the company which owns the right is formed under the law of, and has substantial business activity in the EEA or other territories including the US, Australia and Japan.

Separately, in the UK it is possible to protect under the unregistered design right system any designs of the shape or configuration of the whole or part of an article, which would include semiconductor products. Unlike the provisions of EU law, the UK unregistered design right is wider in scope as the design need not be three dimensional. It is worth noting however that UK unregistered design right system has narrower qualification provisions; for example, it does not generally extend to companies which are formed in the US, Australia or Japan.

In practice however, topography rights are seldom asserted. Industry is capable of designing semiconductors which achieve a particular function independently without copying the original topography. Such rights though may be deployed in conjunction with a claim for trade secret misappropriation.

For example, if the trade secret misappropriation dispute between Waymo and Uber were to happen in Europe, Waymo could include a claim for topography rights infringement by Uber’s alleged copying and use of printed circuit board designs.

7. Confidential information

The protection trade secrets currently received across the EU is inconsistent with a number of Member States having ineffective protection. However, in July 2016, the Trade Secrets Directive came into force, which sets a minimum level of protection across the EU. Although it will not have direct effect in the Member States, it mandates Member States to ensure its laws comply with the European legislation. In short, undisclosed information which is commercially valuable must be protectable, provided reasonable steps have been taken to keep that information secret.

The coming into force of the Directive is timely for global and digitally dependent enterprise such as autonomous vehicles. Conscious that weak trade secret protection within the EU presents easy entry points, the Directive has specifically striven to plug this gap by mandating member states to restrain the importation of “infringing goods,” which is defined broadly as “goods, the design, characteristics, functioning, production process or marketing of which significantly benefits from” misappropriated trade secrets. Although how the Directive will be implemented in the Member States and interpreted by the Courts is unclear. Under this Directive, at least insofar as the UK is concerned, owners of Trade Secrets should be able to prevent the importation of infringing goods into the UK if they can prove that the UK is the appropriate forum to try the case, and that detriment was suffered, or will be suffered, within the country.

In the autonomous vehicle space, the most relevant types of information would include confidential technical information, computer programs, algorithms and data sets. As described above, the eligibility of patenting these types of information can be questionable, and for this reason, proprietors may make a calculated decision to keep these types of information a secret, rather than risk disclosing it in a patent application only for it to be denied protection for want of the requisite technical contribution. Some innovations may depend on other technologies to develop and are liable to take longer than the 20 years’ protection period offered by patents to become commercially relevant. Those will be better held back as a secret.

8. Design rights

The scope for protecting designs in the EU is wide. It protects “the appearance of the whole or a part of a product resulting from the features of, in particular, the lines, contours, colours, shape, texture and/or materials of the product itself and/or its ornamentation,” there being emphasis on 2-D and 3-D visual appearance, which extends to features which are borderline between shape and surface decoration such as texture, provided it is new and has individual character. There are exceptions to this, which is not within the scope of this paper. It is possible to register a Community design which will give the proprietor 25 years of monopoly. If it is not registered, it is possible to claim unregistered Community design right, which lasts for three years. Infringement will be established if the third party product does not produce on the informed user a different overall impression, with the added requirement to show copying in the case of unregistered Community design right; this should be easy to establish if the design right in question is known in the industry.

In addition to the Community design rights, it is also possible to claim for UK unregistered designs which cover similar features provided that the proprietor qualifies, as described above briefly – though it should be noted that surface decoration does not qualify (unlike under the Community designs regime).

A completely autonomous vehicle would obviate the need for steering wheels or dashboards, handbrakes, gears and the pedals. Furthermore, if the development of technology is so far-reaching that safety can be almost guaranteed, then the designs of external and internal features, and ways in which information is presented its passengers would no longer need to be dictated by safety regulations. Such changes would liberate the design freedom for car designers – which may not necessarily be human, but could even be generated by AI. No longer do the seats need to face the direction of travel; a screen may hang behind the windshield to enable passengers to enjoy films; and cars could even be made out of stained glass. Then there are also the in-between designs, for example, a design in which the steering wheel can be stowed away to free up space when human intervention is not required.

9. Open source

Companies may be naturally inclined to protect their ideas and innovations to reap a return on their investment into research and maximally generate profit. Intellectual property is one way, but it may not be the answer in all contexts. Tesla made shock-waves in 2014 when it announced that it was opening up its electric vehicle patents to the world in order to speed up the evolution of the electric vehicles (EV) platform. No such catalyst is needed it seems, when it comes to the progress of the autonomous vehicle project with reliance on intellectual property seemingly the order of the day for corporate strategy. A fact borne out by the substantial increase in the number of patent filings in this field.

That does not mean to say that there are no open-source projects running in parallel. For example, the online education company Udacity founded by Sebastian Thrun (who had previously founded Google X which was responsible for, among other things, Google’s driverless car project), is building an open source self-driving car, touting for similar minded tech developers to contribute. In line with this, it has made available its self-driving simulator on an open source basis. George Hotz, famed for his hacking prowess, has turned to opening up his self-driving software.

There are also other open source projects including those for in-vehicle infotainment software, such as MirrorLink. The in-vehicle infotainment field is an area which is more prone to be dictated by proprietary standards (such as Apple’s CarPlay, Google’s Android Auto), and lesser by industry standards. For this reason, an open source platform for in-vehicle systems could present an important ramp for new tech entrants into the autonomous vehicle space. Of course, the use of open-source material does not equate to non-infringement. As explained above, software, algorithms and the like can attract patent protection if they bring about a technical solution, and so a freedom to operate analysis would still be necessary. Terms of the licence would also need to be heeded.

10. Planning the journey to a driverless world

The continual race to launch an ever more automated vehicle is underway, with each new automobile surpassing the functionalities of those before it. But none of this development is realisable without well-funded and carefully orchestrated research, which must go hand-in-hand with strategizing intellectual property protection, given the fierce competition. The last modern digital revolution of this scale was mobile telephony. Judging by the volume of telecom SEP wars of the past in Europe, but also by the already emerging number of skirmishes in the United States concerning patents covering autonomous vehicle technology, one can easily see that setting aside budget to weather the likely patent litigation storm would be paramount. However, at the same time, compared to the telecoms world, the landscape is rockier owing to the multidisciplinary nature of autonomous vehicles. It is much more difficult to predict from which angle a lawsuit might hit them.

For this reason, it is vital to exploit the full range of intellectual property systems that are available. One must take a considered decision every step of the way. Questions must be asked such as should that technology be patented, or should it be kept secret? Is it a standard essential patent? What data would be useful to collect? Can the database be arranged in a way to attract copyright? Should that shape of an article be registered? How will designs of autonomous vehicles develop, and should there be defensive registrations of those? All of the decisions to these questions and more, would need to be steered by information gathered from trade shows, news, social media, analysis of competitor IP strategy, standards development and new laws and regulations.

The rapid evolution we are seeing before our very eyes is set to present a game-changer to the automotive industry, leading to prosperity for some whilst others may find themselves struggling to survive. The fate of any business could well depend on the richness intellectual property assets built along the way.