Competition Law And Venture Capital Ecosystem Concentration .

Competition Law and Vehicle Operating System Competition Issues

1. Introduction

A Vehicle Operating System (Vehicle OS) is the software layer that manages or coordinates important vehicle functions and provides the platform through which drivers, passengers, vehicle manufacturers, application developers, service providers, and connected devices interact.

Examples of functions increasingly mediated through a Vehicle OS include:

  • infotainment and navigation;
  • vehicle diagnostics;
  • charging and battery management;
  • connected-car services;
  • voice assistants;
  • app stores;
  • payment systems;
  • driver-assistance interfaces;
  • telematics and vehicle data;
  • smartphone integration;
  • fleet-management services; and
  • third-party applications.

The competition-law significance of Vehicle OS arises because the operating system can become a platform or bottleneck between several neighbouring markets. A vehicle manufacturer or technology company controlling the OS may potentially influence access to apps, data, navigation, charging, advertising, payments, repair services and other connected-car services.

The principal competition concerns are therefore market power, tying and bundling, refusal of interoperability, self-preferencing, exclusionary technical design, data advantages, discriminatory access, switching costs and ecosystem lock-in.

2. Meaning of Vehicle Operating System Competition

Competition in Vehicle OS markets can occur at several levels.

A. Competition between Vehicle OS providers

Different operating systems may compete to become the software platform used by automobile manufacturers.

B. Competition between OEM-developed and third-party operating systems

A manufacturer may develop its own OS or adopt an external platform.

C. Competition between applications operating on the OS

Navigation, music, charging, payment, insurance and other applications may compete for access to users.

D. Competition between complementary services

The OS provider may itself offer services that compete with applications dependent upon the OS.

This creates a particularly important vertical competition problem where the OS provider simultaneously acts as:

platform operator + application provider + data controller + gatekeeper.

3. Relevant Competition-Law Issues

3.1 Market Definition

The first question is whether a Vehicle OS constitutes a separate relevant product market.

Possible markets include:

  1. Vehicle OS software;
  2. infotainment operating systems;
  3. connected-car platforms;
  4. navigation services;
  5. automotive app distribution;
  6. vehicle-data services;
  7. charging-management software;
  8. automotive payment platforms; and
  9. fleet-management platforms.

Market definition may depend upon demand-side substitutability, supply-side substitutability, multi-homing and technological characteristics.

For example, an OS designed specifically for vehicle systems may not necessarily be interchangeable with an ordinary smartphone OS because vehicles have different safety, hardware, lifecycle and regulatory requirements.

4. Market Power and Vehicle OS

A Vehicle OS may acquire substantial market power because of:

  • high development costs;
  • long vehicle replacement cycles;
  • network effects;
  • accumulated vehicle data;
  • developer ecosystems;
  • integration with hardware;
  • proprietary APIs;
  • technical standards;
  • app-store control;
  • switching costs; and
  • contractual arrangements with automobile manufacturers.

A powerful OS does not automatically constitute an antitrust violation. Competition law generally becomes concerned when market power is used to exclude competitors, exploit users, restrict access or distort neighbouring markets.

5. Network Effects

Vehicle OS markets can exhibit strong network effects.

More users → more developers → more applications → greater attractiveness of the OS → more manufacturers/users → still more developers.

This can produce a reinforcing ecosystem.

There may also be cross-side network effects:

More vehicles using OS → more developers create applications → better consumer experience → more vehicles adopt OS.

Consequently, an incumbent Vehicle OS may become difficult for competitors to challenge even if an alternative OS is technologically viable.

6. Tying and Bundling

A Vehicle OS provider could potentially require manufacturers to adopt several related products together.

For example:

Vehicle OS + navigation + payment + voice assistant + app store + advertising platform.

Competition concerns become stronger where the provider has substantial power in one product and uses that power to strengthen its position in another market.

Potential examples

A manufacturer might be required to:

  • install the OS together with the provider's navigation service;
  • make the provider's payment system the default;
  • use its voice assistant;
  • distribute only its app store;
  • give preferential placement to its own applications.

The legal analysis would consider whether the products are separate, whether there is coercion, whether the undertaking has market power and whether the practice can foreclose competitors.

7. Self-Preferencing

A Vehicle OS provider may operate its own competing services.

For example, an OS provider might operate:

  • its own navigation application;
  • its own music service;
  • its own charging application;
  • its own insurance platform; or
  • its own payment service.

The provider could theoretically give its own services:

  • preferential search ranking;
  • better API access;
  • superior technical functionality;
  • privileged access to vehicle data;
  • default status;
  • faster approval; or
  • exclusive advertising placement.

This creates a vertical foreclosure/self-preferencing issue.

8. Interoperability

Interoperability is one of the most important competition issues.

A Vehicle OS controls technical interfaces through which third parties interact with the vehicle.

The OS operator may control:

  • APIs;
  • SDKs;
  • communication protocols;
  • application permissions;
  • vehicle-data interfaces;
  • screen access;
  • voice-control functionality;
  • navigation integration;
  • charging information;
  • diagnostic information.

A dominant OS provider that unnecessarily prevents competing applications from interoperating with the vehicle may make market entry substantially more difficult.

However, interoperability restrictions may sometimes have legitimate reasons, particularly:

  • cybersecurity;
  • vehicle safety;
  • privacy;
  • reliability;
  • regulatory compliance.

Therefore, competition law must distinguish legitimate technical restrictions from exclusionary restrictions.

9. Refusal to Provide Access

A Vehicle OS may constitute an important gateway to consumers.

Suppose an application provider needs access to a particular API to provide its service, but the OS operator refuses access.

The issue may be analysed under principles governing refusal to deal or access to an essential facility.

The central questions include:

  1. Is the facility/platform indispensable?
  2. Can competitors realistically reproduce it?
  3. Does refusal eliminate effective competition?
  4. Is access technically possible?
  5. Is there an objective justification?
  6. Does access involve safety or security risks?

The mere fact that access would be commercially useful does not ordinarily establish an antitrust obligation to deal.

10. Default Settings

Defaults can be extremely important in Vehicle OS competition.

Examples include:

  • default navigation;
  • default voice assistant;
  • default music application;
  • default payment method;
  • default charging network;
  • default search engine.

Drivers may rarely change defaults because doing so involves time, inconvenience or unfamiliarity.

Therefore, a dominant OS provider can potentially use defaults to reinforce market power.

The competition analysis should examine:

  • ease of changing the default;
  • user awareness;
  • technical restrictions;
  • prominence;
  • duration of default arrangements; and
  • effects on rival applications.

11. Switching Costs and Lock-In

Vehicle OS ecosystems may create substantial switching costs.

A consumer may accumulate:

  • navigation history;
  • vehicle settings;
  • subscriptions;
  • connected devices;
  • applications;
  • payment credentials;
  • charging preferences;
  • vehicle data;
  • cloud accounts.

A manufacturer may similarly invest heavily in one OS ecosystem.

Consequently, switching to another OS may involve substantial:

financial + technical + contractual + informational costs.

High switching costs can make an otherwise competitive market less contestable.

12. Vehicle Data and Competition

Vehicle OS providers can obtain large quantities of commercially valuable data.

Potential categories include:

  • location;
  • driving patterns;
  • charging behaviour;
  • vehicle performance;
  • maintenance information;
  • consumer preferences;
  • application usage;
  • traffic information;
  • battery performance;
  • fleet information.

Data may create competitive advantages in adjacent markets.

For example:

Vehicle OS → unique data → superior navigation/insurance/charging service → stronger market position → more vehicles → more data.

This can create a data-driven feedback loop.

Competition authorities may therefore examine whether a dominant undertaking:

  • denies data access to competitors;
  • provides inferior data to rivals;
  • combines data across markets;
  • uses data to discriminate;
  • imposes unreasonable access conditions; or
  • uses exclusive data advantages to foreclose competitors.

13. App Store Competition

A Vehicle OS may operate an automotive application marketplace.

The operator can control:

  • admission;
  • ranking;
  • commissions;
  • payment systems;
  • technical requirements;
  • advertising;
  • updates;
  • data access.

Competition concerns may arise if the platform:

  • excludes rival applications without objective justification;
  • imposes discriminatory conditions;
  • forces developers to use its payment system;
  • gives its own applications preferential treatment;
  • prohibits alternative payment mechanisms; or
  • uses app-store power to expand into neighbouring markets.

14. Exclusive Contracts

Vehicle manufacturers may enter long-term agreements with Vehicle OS providers.

Exclusive arrangements can potentially create foreclosure where:

dominant OS provider + long-term exclusivity + high switching costs + substantial market coverage

makes it difficult for competing OS providers to obtain sufficient scale.

The analysis should consider:

  • duration;
  • market coverage;
  • exclusivity obligations;
  • termination rights;
  • switching costs;
  • technological compatibility;
  • availability of alternative manufacturers.

15. Technical Degradation

Another potential issue is technical discrimination.

A platform may provide its own application with:

  • faster access;
  • additional APIs;
  • more vehicle controls;
  • better display placement;
  • lower latency;
  • superior data;
  • privileged notifications.

A rival application may technically remain available but be disadvantaged through inferior functionality.

This may constitute an important form of exclusionary conduct where the OS provider has substantial market power.

16. Competition Between OEMs and Technology Companies

Vehicle manufacturers may face an important strategic choice:

Model 1 — OEM-controlled OS

The manufacturer controls the software ecosystem.

Model 2 — Third-party OS

A technology company controls the software layer.

Model 3 — Hybrid model

The OEM controls safety-critical functions while an external provider operates infotainment and connected services.

The competition question is whether control of the OS causes vertical dependence of automobile manufacturers on a small number of technology platforms.

17. Six Important Case Laws

Because dedicated Vehicle OS precedents are still developing, several leading technology-platform and essential-facility cases provide the principal competition-law framework for analysing Vehicle OS conduct.

Case 1: Microsoft Corp. v. Commission — General Court, EU

Case: Microsoft Corp. v Commission, Case T-201/04.

Microsoft's conduct concerning interoperability information and the tying of products became a landmark European competition-law decision.

Relevance to Vehicle OS

The case demonstrates the significance of:

  • interoperability;
  • technical information;
  • tying;
  • leveraging dominance from one technological market into another;
  • exclusion of competing products.

For Vehicle OS, the analogy is particularly important where an OS provider controls technical interfaces necessary for competing automotive applications.

Principle

A dominant technology platform cannot necessarily use control over technical interoperability to protect or extend dominance into neighbouring markets.

18. Case 2: Google Android — European Commission

Case: Google Android, European Commission Decision of 18 July 2018.

The Commission examined Google's contractual arrangements concerning Android devices, including tying and restrictions affecting competing search and mobile-browser services.

Relevance

Vehicle OS ecosystems can exhibit similar characteristics because the OS can serve as a gateway through which complementary applications reach consumers.

Relevant concepts include:

  • tying;
  • pre-installation;
  • defaults;
  • portfolio effects;
  • distribution restrictions;
  • ecosystem leverage.

Vehicle-OS analogy

An OS provider could potentially leverage dominance in Vehicle OS into:

  • navigation;
  • search;
  • voice assistance;
  • payments;
  • advertising;
  • charging services.

19. Case 3: Google Shopping

Case: Google Search (Shopping), European Commission Decision of 27 June 2017; subsequently considered by the EU Courts.

The case concerned the treatment of Google's own comparison-shopping service in its search results.

Relevance to Vehicle OS

The broader competition-law concept is preferential treatment of an undertaking's own downstream service by a platform controlling access to users.

A Vehicle OS provider operating a competing navigation or charging application could theoretically create a similar issue if it systematically gives its own service preferential treatment.

Key concept

Platform neutrality can become a competition concern where a dominant platform controls access to a neighbouring market in which it also competes.

20. Case 4: Bronner v Mediaprint

Case: Oscar Bronner GmbH & Co. KG v Mediaprint Zeitungs und Zeitschriftenverlag GmbH & Co. KG, C-7/97.

The Court of Justice established important principles concerning refusal to supply and essential facilities.

Relevance to Vehicle OS

Suppose a Vehicle OS provider controls an interface that is indispensable for a particular class of automotive applications.

A refusal-of-access analysis may then examine:

  • indispensability;
  • elimination of competition;
  • duplication possibilities;
  • objective justification.

Importance

The case prevents competition law from automatically turning every commercially important platform into an obligation to provide access.

21. Case 5: IMS Health

Case: IMS Health GmbH & Co. KG v NDC Health GmbH & Co. KG, C-418/01.

The case concerned access to a copyright-protected structure and the circumstances under which refusal to license could raise competition-law concerns.

Relevance to Vehicle OS

Vehicle OS technology may involve:

  • proprietary APIs;
  • software interfaces;
  • databases;
  • technical architectures;
  • protected software.

IMS Health is relevant to the difficult relationship between intellectual-property rights, interoperability and competition law.

Vehicle-OS issue

A dominant OS provider cannot necessarily be compelled to disclose every proprietary technology merely because competitors would benefit from access. The exceptional conditions governing compulsory access remain important.

22. Case 6: Qualcomm

Case: Qualcomm, European Commission decision concerning exclusionary payments and rebates in the baseband-chip market, later considered by the EU Courts.

The Qualcomm litigation illustrates the competition-law significance of arrangements that can restrict rivals' access to an important technology ecosystem.

Relevance to Vehicle OS

Vehicle OS ecosystems depend on numerous technological components, including:

  • connectivity chips;
  • communications systems;
  • cloud infrastructure;
  • automotive processors;
  • telematics;
  • software platforms.

Contracts between powerful technology suppliers and vehicle manufacturers may therefore raise questions concerning exclusivity, conditional incentives and foreclosure.

23. Case 7: Apple — App Store / Digital Platform Investigations

Apple's App Store-related competition proceedings in several jurisdictions provide an important modern framework for analysing platform control over applications and payments.

The underlying issues include:

  • app distribution;
  • payment restrictions;
  • commissions;
  • access conditions;
  • anti-steering;
  • self-preferencing;
  • platform governance.

Vehicle OS relevance

If an automotive OS controls the principal app marketplace, similar questions can arise concerning:

access + ranking + payment + commission + technical functionality.

24. Case 8: Intel

Case: Intel Corp. v Commission, Case C-413/14 P.

The litigation concerning Intel's rebates examined the competitive effects of rebates by a dominant undertaking.

Vehicle OS relevance

The case is useful where an OS provider offers manufacturers:

  • discounts;
  • rebates;
  • marketing support;
  • technical benefits; or
  • financial incentives

conditional upon adoption or preferential use of its platform.

The legal analysis should examine the actual or potential exclusionary effects rather than assuming that every discount is anticompetitive.

25. Consolidated Case-Law Table

CasePrincipal IssueVehicle OS Relevance
Microsoft v CommissionInteroperability and tyingAPI access, interoperability, technical restrictions
Google AndroidTying, defaults and distributionPre-installation and default automotive services
Google ShoppingSelf-preferencingPreferential treatment of own navigation/charging services
Bronner v MediaprintRefusal to dealAccess to indispensable Vehicle OS infrastructure
IMS HealthIP, interoperability and refusal to licenseProprietary APIs and technical interfaces
QualcommExclusionary contractual arrangementsTechnology ecosystem foreclosure
Apple App Store proceedingsPlatform access and paymentsAutomotive app stores and payment systems
IntelRebates and exclusionary effectsIncentives for OEM adoption/exclusivity

26. Vehicle OS and Essential-Facility Doctrine

The essential-facility doctrine may become relevant where an OS is genuinely indispensable for competition in a downstream market.

A simplified analytical framework is:

Dominant OS

↓

Control over indispensable interface

↓

Competitor requests access

↓

Access refused or discriminatory

↓

Competitor cannot effectively compete

↓

Exclusionary effect

↓

Objective justification examined

↓

Competition-law assessment

However, the threshold for compulsory access is generally high. Courts have traditionally been cautious because forced access can reduce incentives to innovate and invest.

27. Vehicle OS and Data Portability

Competition concerns can also arise when consumers cannot easily transfer their information from one automotive ecosystem to another.

For example:

Vehicle A OS

→ driving history
→ charging history
→ preferences
→ applications
→ connected services

If these cannot be transferred to Vehicle B OS, switching costs increase.

Competition authorities may therefore examine whether data portability is:

  • technically feasible;
  • reasonably necessary;
  • proportionate;
  • privacy-compliant; and
  • capable of improving contestability.

28. Cybersecurity as an Objective Justification

Vehicle OS competition law cannot be separated from vehicle safety.

An OS provider may legitimately restrict third-party access where unrestricted access could create:

  • cybersecurity vulnerabilities;
  • safety risks;
  • malicious code;
  • unauthorised vehicle control;
  • data breaches;
  • system instability.

Therefore:

Interoperability is not an absolute obligation.

The important question is whether the restriction is necessary and proportionate to the legitimate security or safety objective.

29. Privacy and Competition

Vehicle data may simultaneously constitute:

  • a privacy issue;
  • a consumer-protection issue; and
  • a competition asset.

A dominant OS provider that controls extensive vehicle data may possess advantages unavailable to competitors.

Competition analysis may therefore examine whether:

  • data is exclusively controlled;
  • competitors receive inferior access;
  • consumers can transfer data;
  • data is combined across services;
  • access terms discriminate between competitors.

30. Algorithmic Competition

Vehicle OS platforms increasingly use algorithms for:

  • navigation;
  • charging recommendations;
  • route selection;
  • service recommendations;
  • advertising;
  • pricing;
  • insurance;
  • maintenance recommendations.

An OS provider could potentially favour its affiliated services through algorithmic design.

For example:

Algorithm recommends OS provider's charging network → greater usage → more data → improved algorithm → stronger position.

Competition authorities may therefore investigate whether ranking or recommendation systems systematically disadvantage competing providers.

31. Merger and Acquisition Issues

Vehicle OS competition can also arise through acquisitions.

A large technology company might acquire:

  • automotive navigation software;
  • connected-car platforms;
  • charging software;
  • mapping companies;
  • fleet-management companies;
  • vehicle-data businesses;
  • automotive cybersecurity companies.

A merger could potentially combine:

OS power + data + applications + infrastructure.

Competition analysis may examine whether the transaction eliminates an emerging competitor or enables foreclosure of downstream rivals.

32. Competition Risks in the Vehicle OS Ecosystem

The major risks can be summarised as follows:

Competition ConcernPossible Conduct
TyingOS tied to navigation/payment
BundlingMultiple automotive services bundled together
Self-preferencingOwn applications receive priority
Interoperability refusalAPIs denied to competitors
Data foreclosureCompetitors denied vehicle data
Exclusive dealingOEMs required to use one OS
Default manipulationOwn services made difficult to replace
App-store restrictionsRival applications excluded
Payment tyingMandatory platform payment system
Technical discriminationCompetitors receive inferior APIs
Switching barriersUser data cannot easily migrate
Predatory conductBelow-cost OS strategy designed to exclude rivals
Margin squeezeExcessive platform charges combined with downstream competition
AcquisitionsAcquisition of emerging automotive technology competitors

33. Competition-Law Assessment Framework

A regulator examining Vehicle OS conduct could proceed through the following stages:

Step 1 — Define the relevant market

Determine whether the relevant market is:

  • Vehicle OS;
  • connected-car platforms;
  • automotive app distribution;
  • navigation;
  • charging;
  • vehicle data; or another market.

Step 2 — Establish market power

Consider:

  • market share;
  • barriers to entry;
  • network effects;
  • switching costs;
  • data advantages;
  • OEM dependence.

Step 3 — Identify conduct

Determine whether the conduct involves:

  • tying;
  • refusal to deal;
  • discrimination;
  • exclusivity;
  • self-preferencing;
  • data restriction;
  • technical degradation.

Step 4 — Analyse foreclosure

Ask whether competitors are actually or potentially excluded.

Step 5 — Examine consumer effects

Consider:

  • prices;
  • quality;
  • innovation;
  • choice;
  • privacy;
  • security;
  • interoperability.

Step 6 — Examine objective justification

Consider:

  • safety;
  • cybersecurity;
  • privacy;
  • technical compatibility;
  • intellectual-property protection.

Step 7 — Consider remedies

Possible remedies include:

  • interoperability obligations;
  • API access;
  • non-discrimination;
  • data portability;
  • choice screens;
  • removal of exclusivity;
  • separation of certain functions;
  • monitoring requirements.

34. Remedies

Where competition authorities establish unlawful exclusionary conduct, possible remedies may include:

Structural remedies

  • divestiture;
  • separation of business units;
  • restrictions on acquisitions.

Behavioural remedies

  • API access;
  • non-discrimination;
  • interoperability;
  • data portability;
  • fair access conditions;
  • prohibition of self-preferencing;
  • removal of exclusivity.

Consumer-facing remedies

  • choice screens;
  • default switching;
  • easier application installation;
  • transparent data-transfer mechanisms.

35. Key Legal Principles

The principal competition-law principles applicable to Vehicle OS markets are:

  1. Control of an important digital platform does not by itself establish unlawful conduct.
  2. Dominance and abuse must be distinguished.
  3. Interoperability restrictions can raise competition concerns where they exclude rivals without sufficient justification.
  4. Tying can allow dominance in an OS to be leveraged into neighbouring markets.
  5. Defaults can materially affect competition where users face switching costs.
  6. Self-preferencing can become significant where a platform competes with businesses dependent upon it.
  7. Vehicle data can constitute an important competitive input.
  8. Refusal-of-access cases require careful analysis of indispensability and foreclosure.
  9. Safety and cybersecurity can provide legitimate justification for technical restrictions.
  10. Competition law seeks to protect the competitive process rather than guarantee competitors access to every proprietary technology.

36. Conclusion

Vehicle Operating Systems are developing into strategic digital infrastructure within the automobile industry. Their importance extends beyond infotainment because the OS can determine access to applications, vehicle data, navigation, charging, payments, advertising, connected services and other automotive ecosystems.

The principal competition-law challenge is the possibility that a powerful Vehicle OS provider can use control over the platform to influence adjacent markets.

The most significant legal questions therefore concern interoperability, tying, self-preferencing, defaults, refusal of access, data advantages, app-store control, exclusivity and switching barriers.

The leading technology-platform decisions such as Microsoft, Google Android, Google Shopping, Bronner, IMS Health, Qualcomm and Intel provide useful doctrinal frameworks even where a particular dispute does not directly concern a Vehicle OS. Future automotive competition litigation is likely to focus increasingly on whether control of the Vehicle OS permits a company to become a gatekeeper over the broader connected-vehicle ecosystem.

 

 

LEAVE A COMMENT