T 2534/17 (Payment module/RAKUTEN) 10-05-2021

1. The invention

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.

Figure 4 shows electronic value apps A-1 to A-N, and a utility electronic value app UA (feature 8). Each electronic value app A-i includes storage areas 40-i, 42-i, 44-i for storing the balance of currency i, an encryption key for UA, and programs for communicating with UA and for updating the balance of currency i ([0040] to [0043] - features 1 and 9). The utility electronic value app UA includes storage areas 40U, 42U, 44U for storing the balance of the utility electronic value, encryption keys for each of A-1 to A-N, and programs for communicating with A-1 to A-N and for updating the balance of the utility electronic value ([0044] to [0047] - feature 11).

Each storage area is encrypted by the encryption key of the respective electronic value ([0040], [0044] - features 10, 12). The encryption keys are also used to authenticate the apps before they communicate ([0043], [0047] - features 13 to 15).

Essentially, according to the embodiment of Figure 9B, and [0086] to [0096], when a payment terminal requests a payment amount from an (e.g. Mth) electronic value app A-M, and the balance of the Mth currency is insufficient, the deficit ("first reload amount") is calculated (feature 3). The utility electronic value app UA replenishes the account of the Mth currency by transferring money from its own account and, if this is not enough, the further deficit ("second reload amount" - features 4 to 7) from the accounts of the remaining apps to A-N (excluding M). Money taken from the remaining apps is first converted to the utility electronic value, before converting it to the Mth currency (feature 6).

2. Fifth to eighth auxiliary requests - admittance

The fifth to eighth auxiliary requests were filed after notification of the summons to oral proceedings and thus Article 13(2) RPBA 2020 applies, which stipulates that such amendments shall, in principle, not be taken into account unless there are exceptional circumstances, which have been justified by cogent reasons. However, the Board judges that they were filed as a direct reaction to the Board's objections and overcame them. Moreover, the appellant adequately explained the reasons for all of this. The Board considers these are cogent reasons that justify the exceptional circumstances required to admit the requests into the proceedings.

3. Sixth auxiliary request- inventive step

3.1 The Board finds it convenient to deal with the more specific sixth auxiliary request before turning to the higher ranking requests.

3.2 During the discussion of claim 1 at the oral proceedings it became clear that there might be some inconsistencies in the terminology used in the claim, in particular, concerning the terms "programs" and "means", the relation between the storage means (32) and the utility electronic app (UA), and the definition of the "exchange ratios". Nevertheless, the Board is satisfied that the interpretations given by the appellant fall within the embodiment of Figures 4 and 9B. The Board thus takes this embodiment (also summarised under point 1.4 above) as a basis for its assessment of inventive step.

3.3 The examining division held that the idea of taking the total amount of money on a card to conduct a payment was non-technical. In particular, using a utility value, as a special type of currency that is mutually exchangeable with all other currencies, was regarded to be part of a business scheme. The division thus started from generally known multi-application smart cards (exemplified by D2, D3, and D7) as closest prior art and concluded that the subject-matter of claim 1 was a straightforward implementation of a non-technical business method on such a smart card.

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.

The Board considers that the examining division's choice of the closest prior art is too general. In the Board's view, generally known multi-application smart cards imply, at most, the co-existence of different applications on a card. Claim 1, however, comprises a particular arrangement of the applications on the card, which cannot be deemed to be generally known.

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.

The card in D3 stores multiple applications ([0127], Figure 5: A 15, B 16, corresponding to the electronic value apps in feature 8 of claim 1). The applications do not communicate directly with each other, but exchange data via the data exchange application 17, which the Board considers to essentially correspond to the utility electronic value app UA of feature 8 of claim 1. Each app has a dedicated storage area which stores at least the balance of the electronic value ([0315], [0325], according to part of the ninth feature).

3.5 Moreover, after discussing D3 in depth at the oral proceedings, the Board considers, contrary to its preliminary opinion, that D3 also discloses that apps store programs for communicating with each other, encryption keys and the authentication of features 9, 11 and 13 to 15.

The data exchange application 17 stores programs for communicating with each of the other applications (Figure 5, card application plug-in data 182 and 192 for communicating with applications A and B) and corresponding encryption keys (Figure 5, authentication key data 183, 193) as in feature 11. In steps (10) to (12) of Figure 2, application A receives a request from the data exchange application 17, performs data processing based on the request, and sends back a response. This implies that application A also stores programs for communicating with the data exchange application as in feature 9.

3.6 Data exchange between application A and the data exchange application 17 is carried out after mutual authentication as in features 13 to 15, which is shown in Figure 3. In step (62), the data exchange application 17 generates and encrypts an authentication challenge before sending it to application A. In step (65), application A decrypts this challenge and generates and encrypts an authentication challenge for the data exchange application. Although Figure 3 shows authentication based on a shared key, paragraphs [0115] and [0186] indicate that the authentication may be based on a public key encryption scheme. Using such a scheme implies that the data exchange application has to encrypt the authentication challenge in step (62) with the public key of application A, and application A has to encrypt the authentication challenge in step (65) with the public key of the data exchange application. This in turn implies that the data exchange application has to store the public key of application A and application A has to store the public key of the data exchange application according to features 9 and 11.

3.7 The data exchange application converts between the currencies to e.g. guarantee the availability of a certain amount of money in a specific currency ([0319] to [0321]). The conversion takes into account exchange rates, which are stored in the data exchange application storage area ([0313], [0320]) according to the last part of feature 11.

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).

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. As the division observed, administrative or commercial restraints might hinder the direct exchange between certain types of electronic money. For instance, loyalty points from different merchants or pairs of rare currencies are not always directly exchangeable. The conversion is then realised via a commonly used reference currency, such as US Dollar. Likewise, most cryptocurrencies are not directly exchangeable for fiat currencies but require an intermediate conversion step, e.g. via Bitcoin. Finally, a conventional currency exchange kiosk usually deals in a single (utility) currency, namely the currency of the country where the kiosk is situated.

The Board, therefore, holds that the features related to the utility electronic value and its use for exchanging between electronic values do not contribute to the technical character of the invention.

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.

As a side remark, the Board notes that the invention actually requires storing 2N (not N) keys: the utility electronic value app UA stores N keys (one for each electronic value app A-1 to A-N), and each of the N electronic value apps stores the UA key.

Moreover, the card of D3 stores the same number of keys as the payment module of the invention: each application (apart from the data exchange application) stores a single encryption key (needed for the authentication with the data exchange application, as inferred from Figure 3 and [0115], [0186]), and the data exchange application stores the encryption keys of all other applications (key data 183, 193 in Figure 5). Hence, the effect identified by the appellant is not achieved over D3, but only over a hypothetical prior art. Effects not achieved over the closest prior art, however, cannot be taken into account in the assessment of inventive step.

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.

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.

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.

3.13 The appellant argued during the oral proceedings that the data exchange application in D3 was not comparable to the utility electronic value app UA. Its purpose was to bypass dedicated host terminals outside the payment card (cf. Figure 19 of D3) by emulating their functionality. In this way, the card applications and their interfaces could remain unchanged. As D3 explicitly taught not to change these applications, the skilled person would not have considered adapting them to implement the concept of the utility electronic value.

This point is now moot since the Board considers that D3 already discloses that the apps have programs for cooperating with the data exchange application and encryption keys for authentication so that they would not require any extensive modifications. Nevertheless, in the Board's view, what led to the idea of the data exchange application in D3 is irrelevant for the assessment of inventive step. What counts is that this application mediates exchanges between currencies held by different applications. Hence, when implementing the modification to the currency exchange scheme required by the formulation of the technical problem, the skilled person would have certainly considered adapting the data exchange application to accommodate these changes. The Board cannot see anything that would have prevented the skilled person from implementing the utility electronic value and its use for converting between currencies within the data exchange application in the payment card of D3. The rest of the applications in D3 would have remained unaffected thereby.

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.

3.15 The appellant argued during the oral proceedings that by using the same keys for both encrypting the storage areas and authenticating the apps, the invention achieved a compromise between security and complexity.

The Board is not convinced by this argument since the application does not disclose any details of the authentication and encryption algorithms. Hence, any alleged effect of the encryption keys on the security or complexity of these algorithms is merely speculative.

3.16 The appellant further argued during the oral proceedings that the skilled person would not have contemplated encrypting the data in the payment card of D3, because D3 already taught a tamper-resistant module for securing the stored data.

In the Board's view, however, the tamper-resistant module of D3 does not obviate the need for further data protection. This module might only provide physical protection of the stored data (e.g. through a hardened casing). The data might nevertheless be accessible to malicious software.

3.17 Accordingly, claim 1 of the sixth auxiliary request does not involve an inventive step (Article 56 EPC).

4. Main and first to fifth auxiliary requests - inventive step

4.1 Claim 1 of the sixth auxiliary request essentially contains all features of claim 1 of the main and the first to fifth auxiliary requests. Any different wordings in the sixth auxiliary request only aim at overcoming the objections with regard to Articles 123(2) and 84 EPC raised by the Board in the communication accompanying the summons to oral proceedings and at better aligning the claim wording with the embodiment in Figure 9B.

Accordingly, claim 1 of the main and the first to fifth auxiliary requests does not involve an inventive step (Article 56 EPC) for the same reasons as given above for claim 1 of the sixth auxiliary request.

5. Seventh and eighth auxiliary requests - inventive step

When interpreting claim 1 of these requests according to their intended meaning, i.e. according to the disclosure in Figure 9B and the corresponding text in the description, the Board judges that they lack an inventive step (Article 56 EPC) for the same reasons as given with regard to the sixth auxiliary request above.