T 1896/12 (Dynamic currency conversion/GLOBAL BLUE) 15-02-2018
Download and more information:
DYNAMIC CURRENCY CONVERSION SYSTEM AND METHOD
Inventive step - determining at the user terminal the type of currency rate conversion to be performed at the host (no
Inventive step - obvious possibility)
Inventive step - preprocessing at user terminal relieving processing demand on host (no
Inventive step - bonus effect)
I. This appeal is against the decision of the examining division refusing European patent application No. 09719548.1 pursuant to Article 97(2) EPC on the ground of lack of inventive step (Article 56 EPC)
II. In this decision reference is made to the following prior-art publication which was cited during the examination procedure:
D1: US 2003/0046234 A1.
III. In the statement setting out the grounds of appeal, the appellant requested that the appealed decision be set aside and that a patent be granted on the basis of the main request on which the decision was based. Oral proceedings were requested on an auxiliary basis.
IV. In its communication submitted with the summons to oral proceedings, the Board expressed its preliminary opinion that the request lacked inventive step (Article 56 EPC).
V. In a reply, dated 11 January 2018, the appellant filed an amended main request and an auxiliary request together with arguments in favour of inventive step.
At the oral proceedings, the appellant confirmed his requests that the decision under appeal be set aside and a patent be granted on the basis of the main request or, in the alternative, auxiliary request 1 filed with letter dated 11 January 2018.
After due consideration of the appellant's arguments the Chairman announced the decision.
VI. Independent claim 1 according to the main request reads as follows:
"1. A transaction terminal system comprising:
- at least one input interface (50, 52, 54) to receive payment card data and transaction details, the at least one interface including a card reader (54) configured to read the payment card data from a payment card;
- a communications interface (62) to connect to a remote host system (18); and
- processing logic (40) operable- to determine payment card data available from the payment card and to use the determined payment card data to determine one of a plurality of types of rate request messages (331, 333, 335, 339, 342) to transmit via the communications interface to the remote host system for identifying a currency conversion rate and- to receive a response message from the host system,
- wherein each type of rate request message includes the determined payment card data and a respective request type indicator indicative of the type of rate request message,
- wherein a rate request message for at least a selected rate request message type includes a conversion currency field for a conversion currency indicator; and
- wherein at least one response message is a rate response message including a conversion currency indicator, a conversion rate indicator and a converted transaction amount value for that currency."
Claim 1 according to the first auxiliary request further specifies that the processing logic comprises a chip logic module and further adds to the end of the claim:
"- wherein the processing logic is operable to respond to insertion of a payment card having a logic chip to attempt to retrieve billing currency information or issuer country information stored on the payment card and
- in the event of billing currency information being retrieved from the payment card, to transmit a rate request message of a first type that includes a first request type indicator indicative that the rate request message is of the first type and includes a conversion currency indicator representative of a billing currency retrieved or derived from information retrieved from the payment card, or
- in the event of issuer country information being retrieved from the payment card, to transmit a rate request message of a third type that includes a third request type indicator indicative that the rate request message is of the third type and includes an issuer country indicator representative of an issuer country retrieved or derived from information retrieved from the payment card, and
- wherein the processing logic comprising a switchable logic module switchable to be active or inactive, which switchable logic module is operable, when active and in the absence of a conversion currency being identified in the transaction terminal system, to transmit a rate request message of a second type that includes a second request type indicator indicative that the rate request message is of the second type and does not include a conversion currency indicator."
VII. The appellant argued essentially as follows:
In contrast to the contested decision, which relied on a general purpose networked ATM, D1 should have been considered as the closest prior art. Claim 1 provided for "identification" of what processing needed to be conducted at the host subject to local requirements at the terminal so that the host did not need to be aware of all local requirements (see point 6.3.2 of the grounds of appeal). In other words, the client terminal determined what currency conversion method to use, whereas the rest of the processing was done in the host.
According to the appellant the distribution of tasks between the client and the host according to claim 1 enabled an optimisation of the processing load at the host. A certain kind of preprocessing was performed by the client by determining one of a plurality of types of rate request messages with the alleged effect of a reduced processor load at the host (see e.g. point 6.3.1 of the statement setting out the grounds of appeal).
1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.
Main request
2. Claim 1 relates to a card-based system that can offer a user (e.g. a payment card holder) an alternative currency for payment. More specifically, it is directed to a transaction terminal system, i.e. a client, which is connected to a host via a communication interface. An input interface receives payment data from a card. Based on that payment data the client determines a "type of rate request message", which essentially tells the host which method it should use to convert the amount to the alternative currency. The host replies with a response message providing a currency conversion rate. The messages exchanged between client and host are mainly defined by respective fields and indicators related to financial aspects regarding a currency conversion and payment card data.
2.1 The technical infrastructure of an ATM client according to claim 1 connectable to a host is essentially the same as was used in the prior art before the priority date of the present application (see e.g. figure 2 of D1). It is rather the types of messages and the distribution of processing that distinguish the claimed subject-matter from known ATMs. According to the appellant's submissions, a certain kind of preprocessing is performed by the ATM client by determining one of a plurality of types of rate request messages with the alleged effect of a reduced processor load at the host (see e.g. point 6.3.1 of the statement setting out the grounds of appeal).
2.2 According to the disclosure of the present invention, the alleged technical effect of reduced processor load is related to elements 10, 18, 32 and 34 of figure 1 operating as shown in figure 5A, process F as part of the upper part of figures 4B and 4C of the application. The "preprocessing" is the selection of one of five categories depending on what information is available on the payment card (currency code available; dynamic currency retrieval allowed; issuer country code available etc.). In the Board's view this is a collection of necessary information for generating the correct rate request message to be transmitted rather than a processor demanding preprocessing. This analysis is in accordance with the appellant's statement that claim 1 provides for "identification" of what processing needs to be conducted at the host subject to local requirements at the terminal so that the host does not need to be aware of all local requirements (see point 6.3.2 of the grounds of appeal).
2.3 However, according to the wording of claim 1 the "determined card payment data" is also transmitted to the host, i.e. the information about local requirements. The Board does not concur with the appellant's interpretation that only the necessary payment card data is transmitted. According to claim 1, which reads "to determine payment card data available from the payment card and to use the determined payment card data to determine one of a plurality of types of rate request messages", the expression "determined payment card data" refers to all the information read from the card. Therefore, according to claim 1 there is no room for any reduction of bandwidth when transmitting data to the host.
3. Article 56 EPC - Inventive step
3.1 The assessment of inventive step in the decision under appeal considered a general purpose networked ATM as described in the description of the present application to be the closest prior art (see page 3, last paragraph of the contested decision). However, the Board concurs with the appellant that D1 is the more appropriate starting point for assessing inventive step.
3.2 The independent claims are directed to a mix of technical and non-technical features. The Board does not dispute that claim 1 directed to a client terminal, claim 12 directed to a host, claim 20 directed to a system comprising client and host, as well as the method according to claim 21 appear in a technical context. The method can be considered to be performed by technical means, because it involves at least one computer with means for storing data, means for processing data and means for transmitting and receiving data, and, therefore, has technical character. Accordingly, the claimed subject-matter is an invention in the sense of Article 52(1) EPC (see T0258/03 "Auction method/HITACHI").
3.3 However, the question of inventive step requires an assessment of whether the invention makes a technical contribution over the prior art. Features which do not make such a contribution cannot support the presence of an inventive step (see T0641/00 "Two identities/COMVIK", Headnote I).
3.4 In the Board's judgement the features related to payment data, currency rates and conversion "per se" are considered to pertain to a financial method, i.e. to the non-technological part of claim 1.
3.5 The contribution of the invention does not lie in an improved infrastructure of a networked ATM. The ATM connected to a host as used according to claim 1 is that of a general purpose ATM network as disclosed in figure 2 of D1. Every communication between ATM and host involves requests and messages, which are technical features in general, but which were commonly known in the art and are disclosed, at least implicitly, in D1 (see e.g. figure 5). The contribution lies rather in the way of associating payment card related information with rate request data, namely for generating a currency conversion request message. The type of data processed is financial data (account numbers, issuer country codes, billing currency etc.), which in the Board's view is non-technical cognitive data, not functional data (see T 1194/97 Data structure product/PHILIPS, OJ EPO 2000, 525).
3.6 According to the appellant the distribution of tasks between the client and the host according to claim 1 enables an optimisation of processing load at the host. A certain kind of preprocessing is performed by the client by determining one of a plurality of types of rate request messages with the alleged effect of a reduced processor load at the host (see e.g. point 6.3.1 of the statement setting out the grounds of appeal).
3.7 The Board agrees with the appellant that a decision about the distribution of tasks between client and host generally falls within the technical domain and, hence, contributes to the technical character of the claim. However, the Board judges that there is no inventive technical contribution involved by the claimed solution in this case in view of the disclosure of D1 and the fact that the distribution is triggered by financial rules and data analysis depending on the payment card data.
The claimed "preprocessing" at the client side, i.e. the ATM, is in fact the selection of one of a plurality of categories depending on what information is available on the payment card (see the application on page 14, line 3 onwards and figure 4B: currency code available; dynamic currency retrieval allowed; issuer country code available). In the Board's view, this is a collection and organisation of the necessary financial information for generating the correct rate request message to be sent to the host. Those are considered to be non-technical prerequisites, which the technically skilled person would receive from the business person as a specification requirement for implementation. Thus, in the Board's view, the skilled person would be faced with the problem of how to implement this "preprocessing" given the teaching of D1.
3.8 D1 discloses the technical infrastructure according to claim 1 (see D1, figure 2 with corresponding text of the description). Currency conversion is based on account specifying information read from a magnetic card (see D1, e.g. figures 3 and 4, steps S10, S20 and [36, 45]). Either a user has different accounts with different currencies (see D1, [0069]) or the user can directly select a currency (see D1, [0075]) resulting in different rate request types.
3.9 According to D1, the processing for conversion rates and converted transaction amounts may be executed by either the ATM or the host (see e.g. D1, [0040, 0048, 0077]). The host then replies by communicating a conversion rate to the ATM (see D1, [0081]).
The Board points out that the so called "second configuration" in D1 according to which the user is presented with information to directly select a currency (see D1, [0075]) is equivalent to dependent claim 6 of the present application (see also figure 4C, steps 340, 341). Since there is no hierarchy defined in claim 1 for determining the types of rate request messages and claim 6 directly refers to claim 1, the scenario covered by claim 6 falls within the scope of claim 1. The skilled reader of D1 would realize from the second configuration of D1, that part of the processing can be done at the terminal (selection of a currency), while the rest of the processing is done by the host (looking up a conversion rate).
3.10 The person skilled in the art within the meaning of Article 56 EPC, a computer expert in the field of ATM networks, provided with the rules for currency conversion of the non-technical abstract financial concept, would have considered the claimed implementation obvious in view of the normal skills and the general knowledge of computer programming in order to solve the problem of efficiently and effectively implementing currency conversion (see point 6.2.2 of the grounds of appeal) in an ATM network according to D1. The skilled person knowing about distributed computing in client-server-networks would have considered using processing capacities at the client as well as at the host in an efficient way depending on what financial information is available at the ATM terminal without the need for inventive skills.
3.11 Storage, selection and processing of financial data is an administrative measure, such as would be performed by a human when converting currencies and looking up currency rates, making use of general purpose computer functions (e.g. storing and retrieving information in electronic form) without creating a further technical effect. The distribution of tasks between client and host contributes to the technical character of the claim, but does not provide for an inventive technical contribution in view of the disclosure of D1. The fact that the steps of retrieving, selecting and transmitting are performed automatically is an obvious consequence of using a networked ATM system.
3.12 The appellant's arguments to the contrary provided in writing and during oral proceedings do not convince. In particular, the Board considers that any savings due to the "preprocessing" is actually only a bonus effect of having taken the decision to determine the collection and organisation of financial information at the client.
The Board also doubts that the preprocessing involves any significant processing power. Moreover, according to claim 1, the payment card data used at the client is transmitted together with a request type indicator (see point 2.3 above). Hence, there is no complete processing of the payment card data at the client side. The host still needs to process payment card data, e.g. by looking up rate information from a respective lookup table.
3.13 In the absence of any technical contribution beyond the straight-forward computer-implementation, the subject-matter of claim 1 does not involve an inventive step (Article 56 EPC) over the disclosure of D1 combined with the skilled person's common general knowledge in the field of distributed computing.
Auxiliary request
4. Claim 1 according to this request further specifies the processing logic by extracting from the payment card data either
- the billing currency information (rate request message of a first type according to former dependent claim 3), or
- the issuer country information (rate request message of a third type according to former dependent claim 5) or
- in the absence of a conversion currency being identified in the transaction terminal a "default" rate request, i.e. the host has to find out the currency conversion rate without identification information from the client (rate request message of a second type according to former dependent claim 4).
4.1 The additional features only further refine the non-technical criteria for defining first to third types of rate request messages (see figure 4B, steps 330, 332, 334) by specifying financial rules forming part of the requirements specification to be implemented. The technically skilled person would be told the financial dependencies of account, currencies and how to organise this (e.g. if one has got a country information from the payment data, a country code has to be sent etc.). The implementation of those requirements is regarded as obvious in view of the normal skills and the general knowledge of computer programming in order to solve the problem of efficiently and effectively implementing currency conversion for the same reasons given with regard to the main request.
4.2 Furthermore, regarding the last feature (second type of rate request) the host does not even receive a result of preprocessing from the ATM terminal. The alleged effect of reduced processor load at the host side is therefore not achieved. Therefrom it becomes apparent that the alleged technical advantage is not always achieved by the claimed subject-matter.
4.3 The additional features therefore do not provide for an inventive technical contribution beyond the straight-forward computer-implementation. The subject-matter of claim 1 according to the auxiliary request does not involve an inventive step (Article 56 EPC) over the disclosure of D1 combined with the skilled person's common general knowledge in the field of distributed computing.
For these reasons it is decided that:
The appeal is dismissed.