T 0796/14 (Mobile device gateway/JOHNSON) 16-02-2018

1. Main request: admissibility (Articles 12(4) and 13(1) RPBA)

1.1 Claim 1 of the main request was substantially amended as compared to claim 1 as filed with the statement of grounds of appeal by adding, inter alia, the feature:

"wherein the memory unit further comprises computer code for cataloging media files of the first source device and the second source device into a list, wherein the list is updated whenever a device catalog is change or deleted" (underlining by the board),

and by deleting, inter alia, the following features:

"a second manager configured to receive a third command from the application and to translate the third command from the application into a fourth command for the second transport"; and

"wherein the application is operable to format dictation of speech into the first command or the third command, wherein the first command relates to a first media file of the database system stored on the first source device and the third command relates to a second media file of the database system stored on the second source device".

The amendments to claim 1 of the main request thus resulted in an entirely fresh case being presented.

1.2 These amendments were submitted with the letter dated 14 February 2018, i.e. two days before the scheduled oral proceedings, and hence constitute an amendment to the appellant's case within the meaning of Article 13(1) RPBA.

According to Article 13(1) RPBA, any amendment to a party's case after it has filed its grounds of appeal may be admitted and considered at the board's discretion, which is to be exercised in view of inter alia the complexity of the new subject-matter submitted, the current state of the proceedings and the need for procedural economy.

Further, in exercising its discretion under Article 13(1) RPBA, the board considers it appropriate to take Article 12(4) RPBA into account (following T 361/08, Reasons 13, and T 144/09, Reasons 1.17). According to Article 12(4) RPBA, the board has the power to hold inadmissible requests which could have been presented in the first-instance proceedings.

1.3 The board notes that the newly added feature (see point 1.1 above) had never been claimed before and has therefore most likely not been searched. Further, the deletion of features referred to above shifts the matter for which protection is sought to other technical matter, i.e. an entirely fresh case, and cannot be considered an attempt to overcome objections raised by the board for the first time. Nor did the appellant argue otherwise. Therefore, the board can see no reason why the applicant would not have been in a position to present the request in question before the department of first instance. Further, it notes that the filing of this request for the first time in the appeal proceedings means that the examining division was not given an opportunity to give a final decision on its merits. The board would therefore be compelled to either give a first ruling on the subject-matter, which would run contrary to the primary purpose of second-instance proceedings, i.e. examining the contested decision (see G 10/93, OJ EPO 1995, 172, Reasons 4), or remit the case to the department of first instance, which would clearly be contrary to procedural economy.

The board thus concludes that the main request could, and indeed should, have been filed during the examination procedure if the appellant wished to pursue the subject-matter in question.

| |

1.4 Exercising its discretion under Articles 12(4) and 13(1) RPBA, the board therefore decided not to admit this request into the appeal proceedings.

2. Auxiliary request: inventive step (Articles 52(1) and 56 EPC)

2.1 Claim 1 of the auxiliary request includes minor clarifying amendments compared to claim 1 of the main request as filed with the statement of grounds of appeal, the latter being essentially based on claim 1 of the auxiliary request decided on by the examining division, with a further feature added (i.e. feature D, see point 2.2 below).

Exercising its discretion under Articles 12(4) and 13(1) RPBA, the board therefore decided to admit this request into the appeal proceedings.

2.2 D4 is considered to represent the closest prior art. The examining division identified distinguishing features A1, A2 and B1 to B3 between the subject-matter of claim 1 of the auxiliary request before it and the system disclosed in document D4. Considering the clarifying amendments (see point 2.1 above) and using the same notation as the examining division did, these features correspond to the following features of claim 1 of the present auxiliary request:

(A1) a first manager configured to receive a first command from the first application and to translate the first command from the first application into a second command for the first transport,

(A2) a second manager configured to receive a third command from the first application and to translate the third command from the application into a fourth command for the second transport,

(B1) a fourth interface for receiving audio signals from a microphone mounted to the vehicle; and

(B2) computer code for facilitating the dictation of speech received at the microphone and provided as audio signals via the fourth interface; and

(B3) wherein the first application is operable to format the dictation of speech into the first command or the third command, wherein the first command relates to a first media file of the database system stored on the first source device and the third command relates to a second media file of the database system stored on the second source device.

The subject-matter of claim 1 of the present auxiliary request further differs from the system disclosed in D4 in that:

(D) the first manager provides a common application programming interface (API) to the first application and other applications.

2.3 The board notes that the examining division's analysis and the resultant distinguishing features are based on two assumptions, namely (1) that iTunes**(®) as mentioned in D4 ("System Features" section under the header "Music") in connection with support for additional formats including DRM-protected files is also used for the indexing of songs as mentioned in a separate point under the same header "Music", and (2) that iTunes**(®) was known at the priority date to provide the indexing of songs originating from two source devices. In the board's view, these assumptions cannot be directly and unambiguously derived from D4. Consequently, the following further distinguishing features compared to the system of D4 must be considered:

(C1) a database system for storing catalog information relating to media files stored on the first source device and the second source device; and

(C2) the database system is configured to automatically manage the catalog when the first source device is connected to the first interface or the second source device is connected to the second interface.

2.4 The board's identification of the distinguishing features compared to the system disclosed in D4 was not contested by the appellant.

2.5 As follows from points 2.6 to 2.9 below, the above-cited distinguishing features relate to the solution of different technical problems. The board does not see how the features in question co-operate amongst themselves such as to provide a new and surprising technical effect, which might otherwise possibly justify an inventive step. Nor did the appellant argue otherwise. It is, therefore, sufficient to consider the inventive contribution of the distinguishing features separately.

2.6 With respect to features A1 and A2, the examining division in the decision under appeal (see point 11.6) considered that they reflected a straightforward choice in computing architecture, which the skilled person would select depending on the circumstances without exercising inventive skill, in order to solve the problem posed. It stated that it was well-known to a person skilled in the art, e.g. a software engineer, to provide hierarchical abstraction layers in software, so that application developers did not need to be concerned with the details of interfaces and device drivers. Such managers, for example implemented as application programming interfaces, formed part of the standard toolbox used in the framework of operating systems. Windows in a version as early as Windows 95 included "managers" in a DirectX package that provided a translation layer between software applications (e.g. games) and device drivers ("transports") of e.g. sound cards. The examining division concluded that a skilled person would include features A1 and A2 in a normal design procedure, which did not involve an inventive step.

The board agrees with the examining division's reasoning and notes that the appellant did not raise any arguments against that reasoning.

2.7 Features C1 and C2 co-operate to provide fast indexing of songs. In D4, the aim of faster indexing is already mentioned in the "System Features" section under the header "Music" ("Faster-indexing of songs (useful when there are hundreds or thousands of songs)"). As it was well-known at the earliest priority date (23 January 2007) that iTunes**(®) provided fast indexing of songs, the board considers that using iTunes**(®) would have been an obvious implementation in the system of D4, it being noted that D4 mentions faster indexing just after mentioning iTunes**(®) in connection with supporting additional formats.

The appellant did not contest this reasoning as such. It did contest that iTunes**(®) provided fast indexing for media files stored on two source devices. Regardless of whether or not iTunes**(®) was known at the time to provide fast indexing of media files stored on two source devices, it would have been obvious to the skilled person to consider fast indexing of songs for all source devices mentioned in D4 under the header "Music". The board notes that the claimed control system does not provide any particular feature which goes beyond the mere fact of catalogue information storage and management for media files stored on two source devices. Nor does the board see that there was any technical prejudice at the time against catalogue storage and management for media files stored on two source devices. Hence, features C1 and C2 essentially express a desideratum. For the above reasons, they do not contribute to an inventive step.

2.8 Features B1, B2 and B3 co-operate to allow speech control of the media files of the first and second source devices.

D10 is a document which is considered relevant for assessing whether or not the inclusion of these features in the system of D4 would have been obvious to the person skilled in the art. More specifically, it discloses a script for use in voice recognition with iTunes**(®). In particular, commands like "play", "artist" and "song" may be issued by speech using this script. Hence, the board considers this document together with iTunes**(®), as it was generally known at the priority date as suggesting a version of iTunes**(®) operable to format the dictation of speech into a command. Even if the particular script disclosed in D10 would not have functioned satisfactorily, as argued by the appellant, it would have been obvious to the skilled person to correct any script programming mistakes, such that it would fulfil the intention mentioned in the first paragraph of D10 ("A script to use voice recognition with iTunes" and "I have written an AppleScript that will allow me to speak the song I want to play.").

Using a version of iTunes**(®) which includes such a script for catalogue information storage and catalogue management (see point 2.7 above), the presence of a fourth interface for receiving audio signals from a microphone mounted to the vehicle (feature B1) would then be inherent, in order to support speech recognition as taught by D10. Likewise, a computer code for facilitating the dictation of speech received at the microphone and provided as audio signals via the fourth interface (i.e. feature B2) would then be implicit, in order to support speech recognition as taught by D10. Finally, an application operable to format the dictation of speech into a first command or a third command, wherein the first command relates to a first media file of the database system stored on the first source device and the third command relates to a second media file of the database system stored on the second source device (i.e. feature B3), would then also be implicit, in order to support speech recognition as taught by D10, it being noted that fast indexing of media files of several source devices as such would have been obvious to the skilled person (see point 2.7 above).

2.9 Feature D (see point 2.2 above) may be regarded as solving the problem of facilitating the creation of software applications for the system.

Application programming interfaces (APIs) were a well-known technique for providing a platform of routines, protocols and tools for building software applications. The advantages of enabling (third-party) application builders to provide applications without having to be concerned with other system details were also well-known to a skilled person, such as a software engineer, at the earliest priority date. Computer operating systems, such as Windows, Unix and macOS, commonly provided an API for programmers. They were widely used in hardware devices in order to facilitate application development. A skilled person trying to solve the problem of enabling (third-party) developers to provide applications for the control system of D4 would therefore, without exercising inventive skill, implement such a commonplace technique, noting that it was also evident that the advantage provided by an API would achieve its full potential only if it could be used for the programming of a plurality of applications.

2.10 The board concludes that the subject-matter of claim 1 of the auxiliary request does not involve an inventive step and hence does not fulfil the requirements of Article 52(1) EPC in combination with Article 56 EPC.

3. There being no allowable request, it follows that the appeal is to be dismissed.