T 1148/20 (Upgrading infotainment system functionality/HARMAN) 25-10-2023

Reasons for the Decision

1. Admissibility of the appeal

In view of the facts set out at points I to III above, the appeal fulfills the admissibility requirements under the EPC and is consequently admissible.

2. The admittance of the amended application documents received on 21 September 2023

The board accepts the appellant's arguments that the amended claims (and descriptions) were filed in response to the objections (principally clarity) raised by the board for the first time in the summons to oral proceedings, which constitutes exceptional circumstances within the meaning of Article 13(2) RPBA 2020 and consequently admits these requests.

3. Summary of the invention

3.1 In the following the paragraph numbers refer to the published application.

3.2 The application addresses the problem of upgrading the applications and features of a vehicle infotainment system within the limitations of its hardware and at minimal extra cost; see [5-7]. In this context, an "infotainment" system provides information, entertainment and navigational assistance; see [3].

3.3 The solution according to the invention is to make use of the functions of a mobile device, such as a smartphone (see figure 2; 204 and [24]), user commands being relayed by the "head unit" of the infotainment system to the mobile device to control those functions; see [21].

3.4 As illustrated in figure 1, the smartphone is connected to the vehicle infotainment system (102) via USB and/or Bluetooth; see [23]. The smartphone comprises applications including a sub-application, for instance an SMS (short message service) application (see figure 6; 602 and [24]) or a navigation application (see [42]), and a content provider application (130), for instance a Bluetooth SPP (serial port profile) proxy server; see [26].

3.5 The infotainment system comprises a content consumer application (110), for instance a Bluetooth SPP proxy client application; see figure 2; 210 and [22, 26]. The "head unit" of the infotainment system allows the various applications to share the system's computing resources and input/output interfaces, for instance a human machine interface (HMI) (114), loudspeakers (120) and a display (122); see [4,19-20].

3.6 The message flow graphs in figures 3 to 6 illustrate the communication between the mobile device and the head unit of the infotainment system; see [34-44]. In particular, figure 5 concerns the communication of user commands from the content consumer application (210) in the infotainment system via the content provider application (230) in the mobile device to the sub-application (502); see [39-40]. Figure 6 concerns the use of SMS and "NAV" (navigation) sub-applications on the mobile device by the head unit of the infotainment system, the content provider application in the mobile device initially compiling a list of available sub-applications that may operate on the smartphone (204) under the control of the head unit (202); see [29, 41-44].

4. Clarity, Article 84 EPC

The amendments to the claims, in particular clarifying claim 1 of all requests to explicitly set out the combination of the infotainment system and the mobile device and deleting the expression "feature rich", overcome the clarity objections raised by the board in the summons to oral proceedings.

5. The board's understanding of the claims

5.1 In the light of paragraph [21] of the description, the mobile device (104) is understood to make certain applications running on it available to the head unit (102) of the vehicle infotainment system, which effectively operates as a proxy for whatever resource, for instance the display or speakers, controlled by the head unit, is used by the applications on the mobile device. This understanding includes the SMS (short message service) and navigation sub-applications running on the mobile device; see figure 6 and paragraphs [41-44].

5.2 Claim 1 of each request sets out a system in which a mobile device is integrated into a vehicle infotainment system comprising a head unit. Claim 1 sets out the features disclosed in figure 5 concerning the communication of user commands entered into the head unit (102) via the content consumer application (210) and Bluetooth/USB link (106) to the content provider application (230) in the mobile device and (via a service) on to the sub-application (502); see [39-40]. For the purposes of the following analysis, the board accepts the appellant's argument that the content provider application is not part of the operating system of the mobile device. The content provider application as claimed must be "aware" of the (sub-)applications on the mobile device so as to be able to "launch" (i.e. "start") a sub-application if needed - and, regarding the auxiliary requests, to maintain a list of sub-applications.

5.3 The content provider application "binds" to the service started by the first sub-application for receiving commands from the content consumer application forwarded by the content provider application. As set out in claim 1, binding ensures that commands received from the content consumer application reach the sub-application. The service establishes a communication link between the head unit and the sub-application on the smartphone.

5.4 The board understands claim 1 of the main and first and second auxiliary requests as not being limited to the Android operating system. This is not so with that of the third auxiliary request, since it uses the language of the Android operating system in the form of the expression "broadcast receiver".

6. Document D1 (DE 10 2009 059 141 A1)

6.1 As shown in figure 1, D1 relates to the integration of a component (10), such as a "mobile radio telephone" (see [47]) or an "audio/video player" (see [38]), into a vehicle information system (20) via a data connection (16); see [38].

6.2 The vehicle information system comprises a display (22,23), speakers (24,25) and a computer (27). The semantics of each application on the component are made available to a generic interface generator in the information system to integrate the application into the user interface (21) of the information system; see [40].

6.3 The component has input/output devices for use with several applications (13-15) which are executed on it; see [38]. These applications also interact with the user interface of the vehicle information system; see [41].

6.4 The decision regarded the processing logic in the computer (27) (see [37]) as disclosing the content consumer application in claim 1. The selection of application "E" in figure 2 (see [57]) was regarded as disclosing a content provider application launching a selected sub-application in the mobile device. It was seen as implicit in D1 that, if the information system wanted to use a particular application (13-15) on the mobile device, that it had to bind to a service offered by that application.

6.5 The appellant has questioned whether D1, in particular its operating software, discloses a content provider application. An application could not be considered system software. In the oral proceedings the appellant argued that each of the three applications on the mobile device (10) in D1 (see figure 1;13-15 and [40,44]) communicated directly with the head unit of the vehicle information system (20), this being implied by the semantic information provided by each application for use by the head unit. In D1 the applications did not communicate with one unique application interface in the head unit.

6.6 It is common ground between the board and the appellant that the operating system or operating software in the mobile device (10) of D1 does not comprise an "application-aware" content provider application in the sense of the claims.

6.7 In the terms of claim 1 of the main request, D1 discloses: a system for integrating an application platform operating on a mobile device (10) and a vehicle infotainment system, the system comprising: a head unit (21) configured to control access to a user input device (26) in the vehicle infotainment system, the head unit having a processor (27) and a communications interface (16); and a content consumer application operating under control of the processor in the head unit and configured to communicate user generated commands entered by a user via the user input device (see figure 2 and [57]) over the communications interface to the mobile device, wherein the user generated commands include commands for selecting and controlling sub-applications executing on the mobile device, the mobile device being configured to: receive from the content consumer application a selection of a first sub-application included in a plurality of sub-applications available on the mobile device; receive from the content consumer application a first user generated command to control an operation of the first sub-application and forward the first user generated command to the first sub-application to control the operation of the first sub-application.

7. Inventive step, Article 56 EPC

7.1 The main request

7.1.1 In view of the above analysis of D1, the board finds that the subject-matter of claim 1 of the main request differs from the disclosure of D1 in that it provides an application-aware content provider application which forwards commands it receives from the content consumer application and which launches sub-applications for execution on the mobile device.

7.1.2 The board takes the view that D1 discloses a user interface (21) of the information system (20) sending commands to the audio player sub-application (see [47, "Audioszenarien"]) in the mobile device (component 10); see [40-41].

7.1.3 The appellant has argued that in D1 the system software controlled the applications. Moreover the communication link between the information system and mobile unit in D1 could either provide separate links between each application and the information system or a single link to a common interface for all three applications. The claimed solution was not an obvious choice. Moreover the head unit and mobile device in the application both had system software on which applications ran. Communication between the head unit and the mobile unit could be handled either by system software or applications.

7.1.4 The board agrees with the appellant that D1 gives no details of how the three applications (13-15) communicate with the information system (20) via the data connection (16). However, disagreeing with the appellant, the board considers that realising the data connection with the information system as a client application and the mobile device, in particular the content provider application, as a server application would have been an obvious solution, allowing the information system to control the mobile device. It means that the content provider application operates at the application level, providing a common interface for sub-applications on the mobile device. The board sees the combination of various related functions in one application generally as a usual choice of software architecture. In the case at hand, the claimed architecture also allows all knowledge about the interface with the vehicle to be kept local to the content provider application and is, in the board's judgement, also an obvious way to achieve the non-technical aim of keeping that interface proprietary.

7.1.5 Consequently the board finds that the subject-matter of claim 1 of the main request does not involve an inventive step, Article 56 EPC, starting from D1.

7.2 The first auxiliary request

7.2.1 This request adds the feature (based on [28], last sentence) that the mobile device comprises an operating system.

7.2.2 The board takes the view that the mobile devices mentioned in D1 (see [47] "Display-Szenarien"), namely a PDA, MP3-player, mobile radio telephone or navigation device typically had an operating system, as distinct from any application or "operating software", at the priority date in 2012. Hence the additional feature is at least obvious, if not implicit, from D1 and thus unable to lend inventive step, Article 56 EPC, to claim 1.

7.3 The second auxiliary request

7.3.1 Claim 1 differs from that of the main request in additionally setting out the configuration of the content provider application in the mobile device to additionally identify one or more sub-applications that may operate on the mobile device under the control of the head unit and to add those sub-applications to an application list; see [29].

7.3.2 According to the decision (see points 6-7), the additional features were known from D1; see [57-58] and the menu list A-E (53) in figure 2.

7.3.3 The appellant has argued that, although D1 shows a menu of applications on the vehicle information system (20), there was no disclosure of how a list of applications was generated. D1 did not disclose the mobile device comprising an application component for forming a list from which the vehicle information system could select a sub-application. Moreover D1 (see [20]) disclosed each application on the mobile device (10) providing the vehicle information system with semantics parameters representing the input and output of information, the parameters being stored by the vehicle information system; see [21]. Hence in D1 the vehicle information system had to adapt to the applications on the mobile device, the invention avoiding this adaption. In D1 the vehicle information system decided which of the applications on the mobile device, that it knew about, would be supported.

7.3.4 The board is of the opinion that D1 discloses not all applications on the mobile device being supported by the vehicle information system; see [1,11]. The entries (A-E) in the menu (53) in figure 2 of D1 are understood to correspond to applications on the mobile device that are supported by the vehicle information system. Moreover D1 discloses the mobile device being "personalised" by the user before being connected to the vehicle information system; see [17]. Hence the mobile device in D1 can determine which applications operate under the control of the vehicle information system. Under these circumstances it would have been an obvious choice for the skilled person starting from D1 to have the mobile device provide the list of applications forming the menu of applications in figure 2 (see also [57]), the inclusion of this function in the content provider application being a usual matter of software structuring.

7.3.5 Hence the board agrees with the decision that the additional features are unable to lend inventive step to claim 1.

7.4 The third auxiliary request

7.4.1 Claim 1, compared to that of the previous request, sets out the additional feature (see [29]) that

"when a new sub-application is installed on the mobile device, a new application broadcast receiver that is different than the content provider application adds the new sub-application to the application list."

7.4.2 The decision (see points 10-11) found that the application broadcast receiver played no part in the integration of the mobile device with the head unit and instead was an obvious solution to the unrelated partial problem of updating or installing software. Hence the additional feature was unable to lend inventive step to inter alia claim 1.

7.4.3 The board notes that the description defines a "broadcast receiver" in the context of the Android operating system, as follows; see [28]:

"... a 'broadcast receiver' is a component that provides a generalized mechanism for asynchronous event notifications. During operation, an application may encounter a condition or an event that should be communicated. The broadcast receiver may be configured to detect the condition and to subsequently communicate it."

7.4.4 Contrary to the decision, the board takes the view that updating the list of sub-applications on the mobile device, thus discovering new applications, does indeed play a part in the integration of the mobile device with the head unit, since the additional feature implies that a newly discovered application may operate under the control of the head unit.

7.4.5 The appellant argued in the oral proceedings that the broadcast receiver was a mechanism for informing the content provider application when a new application was discovered so that it could be added to the application list as soon as possible. The appellant agreed with the board that the skilled person would have been aware of the "broadcast receiver" mechanism and how it worked.

7.4.6 The board considers the desire obvious to make a new application on the mobile device available to the head unit as soon as possible, i.e. as soon as it is installed. That given, the board finds that the additional feature merely sets out the use of a known mechanism as intended for an obvious purpose, namely to update the application list on the mobile device as soon as possible, a task not involving an inventive step. The "broadcast receiver" recognises a predefined condition, namely the installation of a new application suitable for control by the head unit and triggersthe execution of a predefined action, namely updating the list of sub-applications, accordingly.

7.4.7 Consequently the additional feature is unable to lend inventive step to claim 1.