The application underlying this decision relates to payment cards, and more specifically to the conversion of loyalty points based on a commonly used reference currency, such as US Dollar. However, the EPO considered this non-technical. Here are the practical takeaways from the decision T 2534/17 (Payment module/RAKUTEN) of May 10, 2021 of Technical Board of Appeal 3.5.01:
Key takeaways
Features making no technical contribution to an invention can be legitimately incorporated into the formulation of the technical problem.
A technical effect has to be achieved over the entire scope of a claim.
If a technical effect is only a bonus effect, it cannot count towards inventive step.
The invention
The Board in charge summarized the subject-matter of the application underlying the present decision as follows:
1.1 The invention relates to a payment module, such as a smart card, storing pre-loaded electronic money which is used for purchasing goods or services (paragraph [0002] of the published application).
1.2 Known cards subtract a payment amount from the amount of electronic money stored on the card. If the stored amount is below the required amount, the payment fails. Even smart cards, storing electronic money of different currency types, such as Euro, Dollar, or Yen, cannot compensate a shortage of one of the currencies with the other currencies stored on the card ([0004]).
The invention seeks to solve this problem by using the total amount of electronic money of all available currencies on the card ([0005]).
1.3 The solution involves using a reference currency ("utility electronic value" in the claims). If payment in one currency ("electronic value") is required, e.g. Euro, and the Euro balance on the card is insufficient, the deficit is taken from the reference currency. If, however, the balance of the reference currency is also insufficient, the reference currency is replenished from one or more of the remaining currencies ("electronic values", Figure 9B and [0086] to [0096]).
1.4 This idea is implemented by a plurality of applications (or "apps") on the card; one for each of the electronic values, and one for the utility electronic value.
Fig. 4 of WO2012/147969 A1
Here is how the invention was defined in claim 1 according to the sixth auxiliary request:
Claim 1 (sixth auxiliary request; numbering added by the Board)
A payment module (22), comprising:
[1] a plurality of balance change means for changing balances of a plurality of stored electronic values, respectively;
[2] storage means (32) for storing a balance of a utility electronic value, the utility electronic value being mutually exchangeable with the plurality of electronic values;
[3] first reload amount acquisition means (26) for acquiring a first reload amount required for deducting a required amount, which is specified in balance change information input for one electronic value of the plurality of stored electronic values from an electronic value payment terminal, from a balance of the one electronic value (40-1 . 40-N);
[4] second reload amount acquisition means (26) for acquiring a second reload amount required for deducting the acquired first reload amount from the balance of the utility electronic value (40U) stored in the storage means;
[5] first balance change information generation means (26) for generating, in order that a total amount of money deducted from balances of other electronic values of the plurality of stored electronic values (40-1 . 40-N) than the one electronic value equals the acquired second reload amount, at least one piece of balance change information for decreasing a balance of at least one electronic value of the other electronic values, respectively; and
[6] second balance change information generation means (26) for generating, when in response to the generated at least one piece of balance change information the balance of the corresponding at least one electronic value is changed by corresponding at least one of the plurality of balance change means, respectively, balance change information for increasing the balance of the utility electronic value (40U) by the second reload amount, decreasing the balance of the utility electronic value by the first reload amount, and increasing the balance of the one electronic value by the first reload amount in the storage means;
[7] wherein one of the plurality of balance change means corresponding to the one electronic value changes, in response to the balance change information generated by the second balance change information generation means and the balance change information input from the electronic value payment terminal, the balance of the one electronic value;
[8] wherein the storage means (32) comprises a plurality of electronic value apps (A-1,.,A-N) respectively corresponding to the plurality of electronic values and a utility electronic value app (UA) corresponding to a utility electronic value, and wherein payment with an electronic payment terminal is performed by means of an electronic value app;
[9] wherein each of the plurality of the electronic value apps (A-1,.,A-N) comprises storage areas for storing the balance of the electronic value, programs for processing of changing the balance, programs for processing of communicating with the utility electronic value, one of the plurality of balance change means, and an encryption key of the utility value;
[10] wherein the each of the plurality of storage areas of the electronic value apps (A-1,.,A-N) is encrypted by the encryption key of the electronic value;
[11] wherein the utility electronic value app (UA) includes the storage means (32), the first reload amount acquisition means (26), the second reload amount acquisition means (26), the first balance change information generation means (26), the second balance change information generation means (26), programs for processing of communication with the plurality of the electronic values, the encryption keys of the plurality of the electronic values and exchange ratios between the utility electronic value and each of the plurality of stored electronic values, the exchange ratios used to exchange one unit of the utility electronic value with one unit of each of the electronic values;
[12] wherein the storage areas of the utility electronic value app (UA) are encrypted by the encryption key of the utility electronic value;
[13] wherein the electronic value app of the one electronic value which is input the balance change information from the electronic value payment terminal is configured to communicate with the utility electronic value app when an authentication is executed based on the encryption key of the one electronic value;
[14] wherein the utility electronic value app is configured to communicate with an electronic value app when an authentication is executed based on the encryption key of the utility electronic value stored in the electronic value app storage area of the one electronic value;
[15] wherein the electronic value apps of the other electronic values are configured to communicate with the utility electronic value app when an authentication is executed based on the encryption keys of the other electronic values stored in the utility electronic value app storage area;
[16] wherein the payment module executes programs stored in the electronic value app storage area of the one electronic value, the utility electronic value app storage area, and the electronic value app storage areas of the other electronic values.
Is it patentable?
In the first instance, the Examination Division refused the application due to lack of inventive step and added subject-matter. To overcome these objections, the appellant filed seven auxiliary requests at the appeal stage.
Concerning the sixth auxiliary request, the appellant argued as follows:
The appellant argued that while the payment module of claim 1 was motivated by the business idea to use the total amount of money on a card for payment, it provided a non-obvious technical implementation of this idea. Contrary to the examining division's view, the utility electronic value and the utility electronic value app achieved technical effects and, therefore, were not part of the business method, but of the technical solution that had to be examined for inventive step.
First of all, the Board in charge expressed that it considers the embodiment of Fig. 17 of prior art document D3 as the closest prior art to the claimed subject-matter:
3.4 However, D3 discloses a multi-electronic money card for different currencies, which can be used for payment (Figure 17, [0312], [0325]) and means for converting between them ([0320]). The Board considers this more specific teaching to be a good starting point for assessing inventive step.
Afterwards, the Board identified two distinguishing features:
3.8 Claim 1 therefore essentially differs in that:
i) the conversions between different electronic values are carried out via a utility electronic value, whose balance is stored in and updated by the utility value app UA (feature 2, and implementation in features 3 to 7);
ii) the app storage areas are encrypted using the same keys as those employed for the authentication (features 10 and 12).
Concerning difference ii), the Board considered the distinguishing feature to be an obvious measure applied by the skilled person:
3.14 Concerning difference ii), the Board is of the opinion that encrypting the apps' storage areas does not achieve any surprising or advantageous technical effect, but merely serves its well-known purpose of protecting the stored data. The Board further considers that in view of the public key encryption scheme for mutually authenticating the apps suggested by D3 ([0115], [0186]), it would have been an obvious choice for the skilled person to use the already available public keys of the applications to also encrypt the data in their respective storage areas.
Therefore, difference ii) does not involve an inventive step.
With respect to difference i), the Board arrived at the conclusion that this feature lacks a technical character:
3.9 Concerning difference i), the Board agrees with the examining division that the idea of using a utility value for converting between currencies may arise purely from non-technical business-related considerations and cannot recognise any technical problem which might be solved by this feature. .
To counter this argument, the appellant explained that the claimed subject-matter would lead to a reduced amount of memory:
3.10 The appellant argued that the utility electronic value was conceived with the aim to reduce memory usage. When implementing the business idea of the invention, i.e. using the total amount of electronic money for payment, the straightforward solution would be to allow each app to replenish its account by directly communicating with the other apps. In this setting, each app would have to store the encryption keys of all other apps, which would result in a total of N(N-1) stored keys. By using the utility electronic value app, the invention needed to store only N keys.
3.11 The appellant also argued that the invention needed less memory for storing the exchange rates: it had to store only N exchange rates (between the utility electronic value and each of the electronic values), whereas D3 had to store exchange rates for all pairs of currencies.
However, the Board in charge did not follow these arguments and outlined that the claimed invention is only motivated by non-technical considerations. Notably, the Board further argued that any reduction in memory usage is merely a bonus effect, which does not count towards inventive step. Finally, the Board outlined that the alleged technical effect is not achieved over the entire scope of the claim:
As reasoned above (point 3.9), the Board does not consider that the idea of the utility electronic value is motivated by technical considerations. It follows that the necessary exchange rates between this value and the other currencies also do not contribute to the technical character of the invention. Any reduction in memory usage resulting from the exchange rates is merely a bonus effect, which does not count towards inventive step.
The Board also notes that this effect is not achieved over the entire scope of the claim. In the case of two currencies (i.e. N = 2), for instance, D3 would need to store a single exchange rate between the two currencies, whereas the invention would need to store two rates for exchanging between each of the two currencies and the utility electronic value.
Against this background, the Board concluded that the non-technical feature according to consideration i) could be used for formulating the technical problem. The solution to this problem would then have been obvious to the skilled person:
3.12 According to the COMVIK approach (T 641/00), features making no technical contribution to the invention can be legitimately incorporated into the formulation of the technical problem. In the present case the problem therefore is to implement the concept of the utility electronic value and use it for converting between electronic values within the payment module of D3.
The Board judges that it would have been an obvious choice for the skilled person to implement the utility value and the required exchanges within the data exchange application of D3 as this application already mediates currency exchanges. The skilled person would thereby have arrived at an arrangement falling within the scope of the utility electronic value app UA of claim 1 in a straightforward manner. The calculations involving the first and second reload amounts are a direct implementation of the non-technical decision about the policy for replenishing the various balances of the currencies. Therefore, difference i) does not involve an inventive step.
As a result, the appeal was dismissed.
You can read the whole decision here: T 2534/17 (Payment module/RAKUTEN) of May 10, 2021.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
