T 0520/11 () of 17.3.2015

Summary of Facts and Submissions

I. The appeal is against the refusal of application

no. 99 911 945 for lack of an inventive step, Article 56 EPC, (fourth and sixth auxiliary request) over document

D1: WO 97/10562 A.

The main request and the first to third, fifth and seventh auxiliary request were not admitted into the proceedings under Rule 137(3) EPC.

II. At oral proceedings before the board, held on 17 March 2015, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the following application documents:

Description: Pages 5, 6, 7 and 34 (with pages 8 to 12 deleted) as filed during the oral proceedings before the board;

Pages 1 to 4 and 13 to 33 as published;

Claims: Nos. 1 to 25 titled "Main request" filed during the oral proceedings before the board;

Drawings: Sheets 1/2 and 2/2 as published.

III. Reference is also made to the following further document:

D3: "Extensions for Financial Services (XFS) interface specification - Part 1: Application Programming Interface (API) - Service Provider Interface (SPI) - Programmer's Interface", CWA 13449-1, European Committee for Standardization CEN, December 1998, pages 1 to 121.

IV. Claim 1 reads as follows:

"A method for providing transaction services in an ATM (3) or Kiosk, the ATM (3) or Kiosk being operable to read a smart card and/or bank card and further comprising a plurality of hardware devices, with the capabilities of at least one of the hardware devices being non-identical between more than one ATM (3) or Kiosk across a network of ATMs (3, 4) or Kiosks, said ATM (3) or Kiosk being controlled by one or more software applications (10), and comprising an operating system (12); said method characterized in that:-

the one or more software applications (10) interact with said hardware devices through a functional interface of middleware software (13), wherein said functional interface is hardware independent but provides functionality which is implemented in a manner adapted to the particular capabilities of the particular hardware devices which are provided,

wherein the middleware software comprises a series of transaction objects and device controls for standard device functions,

wherein the series of transaction objects implement common ATM or kiosk transactions and are able to interpret the capabilities of the hardware on which they are run by interrogating at least one of the device controls, said at least one device control acting as a persistent server for a hardware device and being configured to abstract details of the hardware device,

at least one of the software applications is built by customising or combining said series of transaction objects, and

said at least one of the software applications is operable to interrogate said at least one device control and to run on a plurality of different hardware implementations, adapting its functionality to the capabilities of that hardware implementation."

Claim 13 reads as follows:

"A computer program comprising program instructions for causing a computer to perform the method of any of Claims 1 to 12."

Claim 14 reads as follows:

"An ATM (3) or Kiosk operable to read a smart card and/or bank card and further comprising a plurality of hardware devices with the capabilities of at least one of the hardware devices being non-identical between more than one ATM (3) or Kiosk in a network of ATMs (3, 4) or Kiosks, said ATM (3) or Kiosk being controlled by one or more software applications (10), and an operating system (12) which controls and receives information from said hardware devices through a functional interface of middleware software (13) comprising transaction objects, wherein said functional interface is hardware independent but provides functionality which is implemented in a manner adapted to the particular hardware capabilities of the particular hardware devices which are provided,

wherein the middleware software comprises a series of transaction objects and device controls for standard device functions,

wherein the series of transaction objects implement common ATM or kiosk transactions and are able to interpret the capabilities of the hardware on which they are run by interrogating at least one of the device controls, said at least one device control acting as a persistent server for a hardware device and being configured to abstract details of the hardware device,

at least one of the software applications is built by customising or combining said series of transaction objects, and

said at least one of the software applications is operable to interrogate said at least one device control and to run on a plurality of different hardware implementations, adapting its functionality to the capabilities of that hardware implementation."

Claim 23 reads as follows:

"A network comprising an ATM or Kiosk according to any of Claims 14 to 22, one or more networking means and one or more application servers."

Claim 24 reads as follows:

"An Extranet formed by combining a plurality of networks of ATMs (3) or Kiosks according to Claim 23."

V. The appellant submitted in substance the following arguments:

The subject-matter of claim 1 was both novel and inventive over the cited prior art.

Document D1 did not provide any detail about the operator interface and how the application and the hardware interacted through this interface. According to D1, the operator interface was to "hide" implementation details of the display. The software application, thus, clearly was not operable to interrogate any device control and to run on a plurality of different hardware implementations, adapting its functionality to the capabilities of that hardware implementation, as defined in claim 1. The same applied to the smart card application programming interface (SCRAPI). Moreover, smart cards were not hardware of the ATM or kiosk.

Document D3 was a specification of the Extensions for Financial Services (XFS) interface. This standard provided for an XFS manager mapping a specified Application Programming Interface (API) to a corresponding Service Provider Interface (SPI) and then routing a request to the appropriate service provider. However, the ability to provide functionality implemented in a manner adapted to the particular capabilities of the particular transaction device provided was not taught.

Reasons for the Decision

1. The appeal is admissible.

2. Amendments

Claim 1 is based on claims 1 to 3 as originally filed and on the description as originally filed (cf page 16, lines 30 to page 17, line 1; page 17, lines 7 to 8; page 18, lines 7 to 9 and 20 to 23).

Claims 2 to 12 are based on originally filed claims 4, 8, 9, 10, 15, 19, 20, 21, 25, 27 and 28, respectively.

Claim 13 is derivable form the application as a whole from which it apparent that a computer program is provided comprising programming instructions causing a computer to perform the method of any of claims 1 to 12.

Claim 14 is based on claims 29 to 31 as originally filed and on the description as originally filed (same parts as for claim 1).

Claims 15 to 25 are based on originally filed claims 32, 37, 38, 47, 48, 53 and 55 to 59, respectively.

Accordingly, the amendments comply with Article 123(2) EPC.

3. Novelty

3.1 Document D1

Document D1 discloses a system comprising a plurality of kiosks coupled to a system server over a network. The kiosks are for use with smart cards and include a plurality of software services accessible by one or more application programs being executed in the kiosk through an application programming interface (cf page 4, line 24 to page 7, line 18; figures 1 and 2).

In particular, document D1 discloses, using the terminology of claim 1, a method for providing transaction services in a kiosk (100), the kiosk being operable to read a smart card and/or bank card and further comprising a plurality of hardware devices (209, 210, 211, 212), with the capabilities of at least one of the hardware devices being non-identical between more than one kiosk across a network of kiosks, said kiosk being controlled by one or more software applications (200), and comprising an operating system (cf page 5, lines 14 to 16).

Moreover, as shown in figure 2, a set of kiosk applications 200 is provided on top of a plurality of application level kiosk services 201 through 207. These application level services may include, in various embodiments, an operator interface 201, kiosk server 202, card data access functions 203, stored value functions 204, security functions 205, PIN pad functions 206, and automatic update functions 207 (cf page 6, lines 15 to 20; figure 2).

The operator interface 201 preferably provides a set of windowing functions, an "attract" screen, which operates when the kiosk is idle, a set of standard templates, which can be used by vendors to design an operator, interface suitable for a particular application, and an order selection and accumulation function for compiling order information for applications which sell goods or services. Operator interface 201 preferably hides implementation details of display 209, such that vendors developing kiosk applications need only make function calls to services in operator interface 201. The encapsulation and abstractions provided by operator interface 201 thus simplify and standardize the task of creating vendor applications which operate harmoniously on kiosk 100 (cf page 6, line 21 to page 7, line 1).

Accordingly, document D1 also discloses that the one or more software applications (200) interact with said hardware devices (209) through a functional interface of middleware software (201), wherein said functional interface is hardware independent but provides functionality which is implemented in a manner adapted to the particular capabilities of the particular hardware devices which are provided, as defined in claim 1.

Document D1, however, does not provide any detail about the operator interface and how the application and the hardware interact through this interface.

In particular, as argued by the appellant, from the fact that in D1 the operator interface is stated to "hide" implementation details of the display, it is clear that in D1 the software application is not operable to interrogate any device control and to run on a plurality of different hardware implementations, adapting its functionality to the capabilities of that hardware implementation, as defined in claim 1.

Document D1, moreover, discloses a smart card application programming interface (SCRAPI) 208 providing a means of isolating differences among different types of smart cards from kiosk applications. For example, one type of smart card may directly provide purse manipulation functions, while another vendor's smart card may not. One feature of SCRAPI 208 is thus to hide such differences from kiosk applications 200 so that each vendor need not be aware of the various types of smart cards used in the kiosk. (cf page 7, lines 11 to 18).

This smart card application programming interface, however, differs from the functional interface defined in claim 1. Smart cards are strictly speaking not hardware devices of the kiosk. Moreover, as for the operator interface discussed above, from the fact that in D1 the SCRAPI interface "isolates" or "hides" differences among different types of smart cards from kiosk applications, it is clear that in D1 the software applications is not operable to interrogate any device control and to run on a plurality of different hardware implementations, adapting its functionality to the capabilities of that hardware implementation, as defined in claim 1.

Accordingly, the subject-matter of claim 1 is new over document D1, Article 54(1) EPC 1973.

3.2 The subject-matter of claim 1 is also new over the remaining available, more remote prior art.

3.3 Document D3

Document D3 is the Workshop Agreement of revision 2.0 of the Extensions for Financial Services (XFS) interface specification by the European Committee for Standardization (CEN). It is dated December 1998 and thus published after the priority date of the application, 24 March 1998. According to the introduction of D3, however, revision 2.0 was released on 11 November 1996, ie well before the priority date of the application (cf "0. Introduction", final paragraph).

The XFS standard (previously named WOSA/XFS) is referred to in the application as originally filed (cf page 16, lines 4 to 12; page 33, line 18 to page 34, line 18).

The standard according to D3 provides for an XFS manager, which includes XFS Application Programming Interfaces (APIs) that interact with Windows based applications and corresponding Service Provider Interfaces (SPIs) which provide an interface for service providers. The XFS manager maps a specified API to a corresponding SPI and then routes a request to the appropriate service provider. The service providers manage the hardware interfaces to services or devices and may interface directly with physical devices (cf section 2.1, "Architecture").

However, as argued by the appellant, the ability to provide functionality implemented in a manner adapted to the particular capabilities of the particular transaction devices provided is not taught by D3 and indeed represents the very problem to which the present invention is addressed.

Accordingly, the subject-matter of claim 1 also differs from the XFS standard as provided by document D3.

4. Inventive step

As discussed above, having regard to document D1, which is considered to provide the closest prior art, the subject-matter of claim 1 differs in that details are provided regarding the operator interface and how the application and the hardware interact through this interface, and in particular in that at least one of the software applications is defined to be operable to interrogate at least one device control and to run on a plurality of different hardware implementations, adapting its functionality to the capabilities of that hardware implementation.

As essentially argued by the appellant, compared to document D1 where the software application is not able to adapt its functionality to the specific capabilities of the hardware of the kiosk, the method of claim 1 provides a better handling of kiosks with differing hardware capabilities.

Accordingly, the objective problem to be solved relative to document D1 may be formulated generally as to improve the interoperability with kiosks having different hardware.

Document D1, however, as discussed above provides little detail as to how the interfaces "hide" the hardware difference from the application and does not provide any adaptation of the functionality of the application to the specific capabilities of the hardware of the kiosk.

Accordingly, the solution to the above problem as claimed is not suggested by document D1.

The claimed solution is also not suggested by any of the remaining available documents.

In particular, as discussed above, document D3 does not suggest any adaptation of the functionality of the application to the specific capabilities of the hardware.

Accordingly, having regard to the available state of the art, the subject-matter of claim 1 is not obvious to a person skilled in the art and, thus, involves an inventive step in the sense of Article 56 EPC 1973.

5. The subject-matter of claim 13, directed at a computer program comprising program instructions for causing a computer to perform the method of any of claims 1 to 12, is also new and involves an inventive step for in substance the same reasons given for claim 1.

It is noted in this respect that the computer program claimed is technical as it serves to control a technical piece of equipment (ATM or kiosk). It is, therefore, not excluded from patentability under Article 52(2)(c) and (3) EPC.

The subject-matter of claim 14, directed at a corresponding ATM or kiosk, having regard to the available state of the art, is new and involves an inventive step for in substance the same reasons given for claim 1.

The subject-matter of claim 23 and 24, directed at a network comprising an ATM or Kiosk according to any of claims 14 to 22 and an extranet formed by combining a plurality of such networks, respectively, is also new and involves an inventive step by virtue of the ATM or kiosk of claim 14 being novel and inventive.

Claims 2 to 12, 15 to 22 and 25 are dependent on claim 1, 14 and 24, respectively, providing further limitations. The subject-matter of these claims, therefore, is also new and involves an inventive step.

6. The patent application documents also meet the remaining requirements of the EPC, so that a patent can be granted on the basis of these documents.

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the department of first instance with the order to grant a patent with the following documents:

Description: Pages 5, 6, 7, 34 as filed during the oral proceedings before the Board;

Pages 1 to 4 and 13 to 33 of the application as published;

Claims: Nos. 1 to 25 as filed during the oral proceedings before the board;

Drawings: Sheets 1/2 and 2/2 as published.