|European Case Law Identifier:||ECLI:EP:BA:2009:T038407.20090908|
|Date of decision:||08 September 2009|
|Case number:||T 0384/07|
|IPC class:||G07F 1/00|
|Language of proceedings:||EN|
|Download and more information:||
|Title of application:||Methods and systems for effecting payment card transactions|
|Applicant name:||European Tax Free Shopping Limited|
|Relevant legal provisions:||
|Keywords:||Inventive step (no)
Stay of the proceedings (no)
Summary of Facts and Submissions
I. This is an appeal against the refusal of application 03 764 094 for lack of an inventive step, Article 56 EPC 1973.
II. The appellant applicant requested that the decision under appeal be set aside and that a patent be granted on the basis of claims 1 to 22 filed with letter dated 9 August 2006, received at the EPO 11 August 2006.
Furthermore, as a procedural request, the appellant requested that the appeal proceedings be suspended, pending the outcome of the referral No. G 03/08 before the Enlarged Board of Appeal.
III. Claim 1 reads as follows:
"1. A method of processing a payment card transaction between a first cardholder and a first merchant in a data processing terminal connected to a network of data processing terminals, the transaction having a first currency and a second currency, the method comprising the steps of:
creating a second cardholder and a second merchant;
receiving a transaction record of the first transaction from a remote merchant terminal;
creating a first transaction record of a transaction between the first merchant and the second cardholder based upon said received transaction record, the first transaction record having transaction data in the first currency;
creating a second transaction record of a transaction between the first cardholder and the second merchant based upon said received transaction record, the second transaction record having transaction data converted in the second currency ; and
communicating said first and second transaction records to one or more remote data processing terminals, respectively, for processing said first and second transaction records".
IV. Reference is made to the following document cited in the application as originally filed:
D1: WO 01 04846 A
V. The appellant in substance provided the following arguments:
The application concerned a data processing method and not a business method. The converted transaction known from D1 already provided the possibility for a cardholder to conduct the transaction in his own currency rather than in the currency of the merchant. The problem addressed in the application concerned the ghost copies created in this transaction which could result in a double debiting of the cardholder. As neither this problem nor the claimed solution were known or suggested in the prior art, the presence of an inventive step had to be acknowledged.
As there was significant uncertainty surrounding Articles 52 and 56 when applied to the field of computer-implemented inventions, and in general relating to the question of "technical" subject-matter, the outcome of the referral to the Enlarged Board of Appeal G 03/08 would be of assistance to both the applicant and the board in the context of the present case. In particular question 2, 3 and 4 of the referral had a direct bearing on the outcome of the present case. Accordingly, the proceedings ought to be suspended, awaiting the outcome of the referral.
Reasons for the Decision
1. The appeal is admissible.
2. Exclusion to patentability, Article 52(2) and (3) EPC
Claim 1 concerns a method of processing a payment card transaction between a first cardholder and a first merchant in a data processing terminal connected to a network of data processing terminals.
It in fact concerns a financial transaction in which the first cardholder pays the first merchant in a trade in which the first cardholder makes a purchase from the first merchant (see also description, page 1, lines 14 to 22 and page 9, lines 1 to 5) and is, thus, a method for doing business.
In accordance with Article 52(2)(c) EPC, in particular methods for doing business shall not be regarded inventions within the meaning of Article 52(1) EPC. According to Article 52(3) EPC the patentability of such methods shall only be excluded to the extent that the application, and indeed the claimed subject-matter as this defines the matter for which protection is sought, relates to methods for doing business as such.
However, where the claimed method involves technical means, it does not relate to a method for doing business as such and its patentability is therefore not excluded (see also T 258/03 (OJ EPO 2004, 575), Headnote I, Reasons 4.7).
As in the present case the method as claimed, in addition to those features corresponding to the underlying business scheme itself, includes features corresponding to technical means for the technical implementation of the business scheme, such as a data processing terminal connected to a network of data processing terminals etc., it does not constitute a method for doing business as such, and, therefore, is not excluded from patentability in accordance with Article 52(2) and (3) EPC.
3. Request for suspension of the proceedings
3.1 The appellant applicant requested that the appeal proceedings be suspended awaiting the outcome of the referral to the Enlarged Board of Appeal G 3/08.
The appellant in particular contended that the answer to questions 2, 3 and 4 of this referral had a direct bearing on the outcome of the present case.
3.2 Absent any directly applicable provisions of the EPC or the Rules of Procedure of the Boards of Appeal, the ordering of such a suspension is at the discretion of the board.
3.3 The above referral is concerned with the point of law which concerns the application of the exclusion of computer programs as such.
The present case however is not concerned with this point of law. None of the claims is directed to a computer program as such. Furthermore, exclusion of patentability (Article 52(2) and (3) EPC) is not an issue contested by the board in the present case, as it is accepted that the use of means as claimed for implementing the business scheme provides the required technical character of the claimed subject-matter (see point 2 above).
Accordingly, the outcome of the above referral is not decisive for deciding the present case.
In fact, to the appellant's argument that it would only be equitable to the applicant to stay the proceedings as there was no further body outside the EPO to have jurisdiction on the case to which the appellant could have redress on this matter, it is noted that the outcome of the above referral cannot put the appellant in an more favourable position on this very point of law, since the technical character of the claimed subject-matter as a whole, and thus its non-exclusion, is recognised by the board.
3.4 As to the appellant's argument, that the second, third and fourth question of the above referral had a direct bearing on the outcome of the present case, it is noted that the board fails to see how any of these questions would be decisive for deciding the present case.
The second question of the above referral, the leading part of which reads "Can a claim in the area of computer programs avoid exclusion under Art. 52(2)(c) and (3) merely by explicitly mentioning the use of a computer or a computer-readable data storage medium?", is clearly directed to a computer program. Claim 1 is not concerned with a computer program, but with a business scheme implemented using a data processing terminal connected to a network of data processing terminals, a remote merchant, transaction records etc. Furthermore, as the exclusion of the patentability under Article 52(2) and (3) EPC is not at stake, the answer to this question does not have a bearing on the present decision to be taken.
Similarly, the fourth question, which first part reads "Does the activity of programming a computer necessarily involve technical considerations?", has no bearing on the present case. At no point does the activity of programming a computer play a role for deciding the present case.
As far as the third question is concerned, which leading part reads "Must a claimed feature cause a technical effect on a physical entity in the real world in order to contribute to the technical character of the claim?", as apparent from the accompanying explanations, it is primarily concerned with drawing a line between technical effects and effects lying solely in the field of programs for computers, in case of features related to computer programs whose effects are confined to the internal working of the computer. In the present case no such features are present. But even considering a broader scope of the question, the board is not persuaded that the answer by the Enlarged Board of Appeal would be decisive for deciding the present case. A decisive issue in the present case is whether, for the purpose of assessing the presence of inventive step, certain features of claim 1, in particular those corresponding to setting up a third party acting as an intermediary in the transaction with a (second) cardholder and a (second) merchant account, pertain to the realm of schemes, rules and methods for doing business listed in Article 52(2) EPC. The above third question of the referral does not address this issue.
Although it can not be excluded, as argued by the appellant, that the answer to this question by the Enlarged Board of Appeal may possibly cover subject-matter or activities listed in Article 52(2) EPC other than computer programs, and in particular schemes, rules and methods for doing business at issue in the present case, and provide some guidance in deciding the present case, this mere possibility is not a sufficient reason for staying proceedings. Here, the interest of the party in awaiting the outcome of the referral for such possible guidance cannot counterbalance the interest of the public in a swift decision on pending patent applications, including the present one.
3.5 Accordingly, the appellant's request for suspension of the proceedings is refused.
4. Inventive step
4.1 As expounded in the application (description, page 1, lines 15 to page 3, line 12), in general, conventional transactions involving a card payment are conducted in the currency of the merchant. Thus, if an Irish credit card is used for a purchase in the USA, the currency of the transaction will probably be in US$. The transaction value will subsequently be converted into an equivalent EURO value by the credit card holder's bank but is unknown at the point of sale. This equivalent EURO value will subsequently appear on the credit card holder's statement. This restriction can be inconvenient for cardholders travelling abroad, as they are unsure of the exact value of the transaction in their own currency at the point and time of sale.
Dynamic currency conversion overcomes these limitations by performing the currency conversion at the point of sale at the time the customer makes a purchase using their payment card. An example of a dynamic currency conversion system is described in document D1. With dynamic currency conversion processes, the cardholder is informed at the point of purchase as to what amount they are paying in the cardholder's own currency, whilst the merchant obtains payment in the merchant's own currency.
This process is possible because the function of converting from the currency of the merchant to the currency of the cardholder is performed at the point of sale terminal rather than in the computer systems of the bank in which the cardholder has their credit card account.
Payment card transactions are processed and submitted from the merchants to the financial institutions, or an intermediary, as transaction records. Each transaction has an associated transaction record, containing the details of the transaction.
Before the introduction of dynamic currency conversion in payment card transactions, an extract of a transaction record would have looked something along the lines of the transaction record shown in Figure 1 of the application. The precise fields and formats of fields used may vary from bank to bank. In brief, the data in the fields identifies the date of the transaction, the name of the holder of the payment card, the card number of the payment card, the expiry date of the payment card, the name of the merchant who is performing the transaction, the code of the merchant performing the transaction and the amount of the transaction (in the merchant's currency).
With the introduction of dynamic currency conversion transactions, a number of additional fields are required to be "captured". An extract of an exemplary transaction record in a dynamic currency conversion environment is shown in the transaction record in figure 2. The additional fields to be captured comprise the converted currency element of the transaction, which may include the converted amount in the currency of the cardholder's payment card account, which the cardholder will see on their statement and the exchange rate used to perform the conversion. The currency of the cardholder may also be required.
Normal transactions (transactions processed in the currency of the merchant only, an example of which is shown in figure 1) are processed conventionally typically through the acquiring bank of the merchant, whereas the dynamic currency conversion transactions may be separated from the normal transactions and may be routed to a dynamic currency conversion system, which may be separate from the acquiring bank, for transmission into the card schemes and which may be settled back to the acquiring bank and/or the merchant via a multi-currency payment card processing bank or other route. A multi-currency payment card processing bank is a bank which is capable of processing payment card transactions from merchants in more than one currency.
The separation function may be handled by a POS device dispatching normal and/or converted transactions to a first host and normal and/or converted transactions to another host or hosts (page 3, lines 12 to 14).
According to the application "For the purposes of the Acquirer and/or other third parties paying the merchant and/or providing the Merchant with the statement in relation to all merchant transactions (rather than two separate regular payments and/or two separate statements), the normal and dynamic currency conversion transactions need to be amalgamated in some way. Accordingly, for settlement purposes vis a vis the acquirer to the merchant, and likewise the statement from the acquirer to the merchant and/or for related card scheme merchant service fee charges deducted & payable to the acquirer by the merchant, a "ghost copy" of the dynamic currency conversion transactions may be incorporated/sent to the Acquirer's or other third parties host. However, to prevent duplication of debits against the Card Holder, these "ghost copy" transactions must not be processed into the card schemes with the normal transactions. Thus the Acquirer's and/or third parties host systems have to be amended, in addition to modifications to the related accounting thereof" (page 3, lines 16 to 28).
4.2 To the board, however, the nature of these ghost copies remains unclear and thus it is not apparent to which extent they constitute a problem. In a dynamic currency conversion transaction, as explained in the application, a transaction record is created including additional fields containing the converted currency which may be routed to a multi-currency payment card processing bank for settlement with the acquiring bank and the merchant. This is, however, a single transaction record debiting the cardholder and it is not apparent why and where a ghost copy of this transaction would be created. As to the need mentioned in the application to amalgamate normal and dynamic currency conversion transactions, this apparently concerns the fact that both normal and dynamic currency conversion transactions may be handled at a single POS device. These are however different transactions, involving different cardholders. It is not apparent why and where a ghost copy would be created or how double debiting of a cardholder could occur.
4.3 Document D1 discloses a currency conversion transaction as acknowledged in the application and discussed above in which the cardholder is informed at the point of purchase as to what amount they are paying in the cardholder's own currency, whilst the merchant obtains payment in the merchant's own currency (cf D1, page 14, line 7 to page 16, line 17 and figure 8).
However, it is noted that document D1 neither mentions ghost copies, nor provides any insight as to what the alleged ghost copies might be.
4.4 It is furthermore noted that according to the detailed description of the invention, and indeed sole embodiment of the invention, the solution offered comprises a (second) transaction between the (first) cardholder and the (second) merchant (the third party) which is a converted transaction i.e. a dynamic currency conversion transactions as discussed above (page 12, line 28 to page 13, line 10). As this type of transaction according to the application itself is problematic due to the occurrence of "ghost copies" and the corresponding risk of double debiting the cardholder, any possible problem associated herewith would in effect not be solved by the invention.
No convincing explanations were adduced by the appellant in writing and in the oral proceedings and in the end the representative of the appellant indicated not to know what exactly these ghost copies were.
The appellant's argument that the claimed method addressed the problem of ghost copies and double debiting of the cardholder of occurring in the method of document D1 or in other conventional, unspecified systems must, therefore, be dismissed.
4.5 Taking document D1 as the closest prior art, the claimed method differs in substance from D1 in that rather than providing a (converted) transaction between a cardholder and a merchant, it involves a third party acting as an intermediary having a cardholder account and a merchant account, with a (converted) transaction between the cardholder and the third party merchant and a (conventional, unconverted) transaction between the third party cardholder and the merchant.
The interposition of a third party acting as an intermediary in a financial transaction, as is the case in the present application, is in the board's opinion a measure pertaining to the realm of schemes, rules and methods for doing business as such. In fact, the third party here is assuming the classic role of a broker mediating between a buyer and a seller in a business transaction.
4.6 The appellant argued that there was no third party involved in the claimed method as the created second cardholder and second merchant where merely pseudo entities consisting of respective accounts in the system.
The board notes however that according to the application description "The above described method in effect creates two transactions, the net result of which is a debit from the cardholder and a credit to the merchant, with a third party acting as an intermediary and having a merchant account and a cardholder account" (page 13, lines 21 to 23). Also according to the description "The second cardholder identified in the first transaction record 500 is a cardholder account or pseudo cardholder of an intermediary possibly for example the operator or an associate of the operator of the currency conversion scheme" (page 12, lines 11 to 13). Again the intermediary is a third party, where "pseudo cardholder" merely expresses that this cardholder, unlike true cardholders such as the first cardholder, does not make purchases by itself at a merchant.
Also the appellant's argument that the splitting of a (single) transaction into two transactions would be counterintuitive to a business person and thus had to be technical is not convincing. As discussed above, the interposition of a third party acting as an intermediary in a financial transaction is non-technical and the consequential splitting of the transaction in two is thus non-technical as well.
4.7 Since the interposition of a third party acting as an intermediary in a financial transaction, here a payment card transaction, pertains to the realm of schemes, rules and methods for doing business as such, the patentability of which is excluded under Articles 52(2) and (3) EPC, it cannot contribute to inventive step.
Inventive step will be assessed on the technical implementation of the business scheme, where the business scheme appears as an input requirement to the skilled person entrusted with the technical implementation, irrespective of whether the business scheme as such is innovative (see also T 641/00 (OJ EPO 2003, 352), Headnote II, Reasons 3 to 7).
4.8 In the present case, the technical implementation of the interposition of a third party acting as an intermediary in a payment card transaction as per claim 1 involves the steps of:
- creating a second cardholder and a second merchant;
- receiving a transaction record of the first transaction from a remote merchant terminal;
- creating a first transaction record of a transaction between the first merchant and the second cardholder based upon said received transaction record, the first transaction record having transaction data in the first currency;
- creating a second transaction record of a transaction between the first cardholder and the second merchant based upon said received transaction record, the second transaction record having transaction data converted in the second currency ; and
- communicating said first and second transaction records to one or more remote data processing terminals, respectively, for processing said first and second transaction records.
To the person skilled in the art, in the present case a person skilled in the field of technical solutions for payment card transactions, it would be obvious to implement the intermediary third party in the converted transaction known from document D1 by creating a third party cardholder and a third party merchant and to provide a (converted) transaction between the card holder and this third party merchant in the card holders currency and a further transaction between this third party cardholder and the merchant in the merchant's currency, as this represents the most straightforward solution.
Furthermore, it would be obvious to the skilled person to implement these transactions by creating corresponding transaction records with respective transaction data, to base these transaction on a corresponding transaction record received from a remote merchant terminal (eg a conventional point of sale terminal) and to communicate the transaction records to one or more remote data processing terminals (eg processing bank), as this corresponds to the conventional technical implementation of payment card transactions in general (see eg document D1, page 2, lines 1 to page 3, line 9; page 14, line 7 to page 16, line 17; figures 3, 4, 8)).
4.9 It is noted that the board concurs with the appellant that unlike in the decision under appeal (reasons 3.2) the creation of transaction records, the creation of the second cardholder and merchant (to the extent it implies the creation of corresponding accounts for the transactions) and the reception and communication of the records is technical and is part of the technical implementation of the (non-technical) business scheme.
Notwithstanding this, these features do not render the claimed subject-matter inventive as discussed above.
4.10 Accordingly, the subject-matter of claim 1 lacks an inventive step in the sense of Article 56 EPC 1973.
For these reasons it is decided that:
1. The request for the suspension of the proceedings is refused.
2. The appeal is dismissed.