T 2534/17 - Bitcoins at the Boards

 Key points

• “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 []. 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 []. The invention seeks to solve this problem []. 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[]. 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.”
• This may all sound rather complex for normal currencies.
• However, the Board explains “As the [examining] 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. ”
• As a comment, the application (EP2704073A1 ) does not seem to mention cryptocurrencies.
• The Board finds the claims to lack inventive step under the Comvik approach.

T 2534/17 -  

https://www.epo.org/law-practice/case-law-appeals/recent/t172534eu1.html

Reasons for the Decision

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.