T 2534/17 (Payment module/RAKUTEN) of 10.5.2021

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division to refuse the European patent application No. 12775983.5 (published as EP 2704073 A1) for added subject-matter (Article 123(2) EPC) and lack of inventive step (Articles 52(1) and 56 EPC). Regarding inventive step, the division considered that the invention was essentially a business method implemented on a multi-application smart card generally known from any of D2 (WO 2010/131012 A1), D3 (EP 1560172 Al) or D7 (XP055317544 - Java Card**(TM) Platform Security).

II. In the statement setting out the grounds of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main or one of the first to fourth auxiliary requests filed therewith. The main and the first to third auxiliary requests were the same as the refused requests. The fourth auxiliary request essentially corresponded to the refused fourth auxiliary request. Oral proceedings were requested on an auxiliary basis.

III. In the communication accompanying the summons to oral proceedings, the Board expressed its preliminary view that the subject-matter of claim 1 of the main, the third, and the fourth auxiliary requests extended beyond the content of the application as filed and that the main and the first to third auxiliary requests lacked clarity and inventive step over D3.

IV. In a reply dated 9 April 2021, the appellant filed new fifth to eighth auxiliary requests together with arguments in favour of inventive step.

V. At the oral proceedings, held by videoconference on 10 May 2021, the appellant confirmed the requests submitted in writing.

VI. Claim 1 of the main request reads (with the Board's numbering of the features):

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 app storage areas (A-l,...,A-N) respectively corresponding to the plurality of electronic values and a utility electronic value app storage area (UA) corresponding to a utility electronic value;

[9] wherein each of the plurality of the electronic value app storage areas (A-l,...,A-N) stores the balance of the electronic value, programs for processing of changing the balance, programs for processing of cooperating with the utility electronic value, and an encryption key of the utility value;

[10] wherein the each of the plurality of the electronic value app storage areas (A-l,...,A-N) is encrypted by the encryption key of the electronic value;

[11] wherein the utility electronic value app storage area (UA) stores the balance of the utility electronic value, programs for processing of changing the balance, programs for processing of cooperating with the plurality of the electronic values, and the encryption keys of the plurality of the electronic values;

[12] wherein the utility electronic value app storage area (UA) is encrypted by the encryption key of the utility electronic value;

[13] wherein the electronic value app storage area of the one electronic value which is input the balance change information from the electronic value payment terminal is accessible when an authentication is executed based on the encryption key of the one electronic value;

[14] wherein the utility electronic value app storage area is accessible 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 app storage areas of the other electronic values are accessible 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.

VII. Claim 1 of the first auxiliary request clarifies in features 8 to 15 that the storage means (32) comprises electronic value apps (A-1,...,A-N) and a utility electronic value app (UA) which in turn comprise the various storage areas. Also in features 13 to 15 the utility electronic value app is said to be "configured to cooperate" with the electronic value apps.

VIII. Claim 1 of the second auxiliary request adds to the end of feature 8 of claim 1 of the first auxiliary request "wherein payment with an electronic payment terminal is performed by means of an electronic value app".

IX. Claim 1 of the third auxiliary request adds to the end of feature 2 of claim 1 of the second auxiliary request "wherein the storage means (32) is for further storing exchanges [sic] rates, the exchange rates being exchange rates between the utility electronic value and each of the plurality of stored electronic values".

X. Claim 1 of the fourth auxiliary request reads:

A payment module comprising:

a memory operable to store a plurality of applications; and

a processor operable to read program code in the plurality of applications and operate as instructed by the program code,

wherein the plurality of applications comprise a plurality of electronic value applications, EV-Apps, and a utility electronic value application, UEV-App,

wherein each of the EV-Apps comprises:

first information relating to an electronic value of an EV-App;

first program code configured to cause the at least one processor to access the first information;

a first encryption key for accessing the UEV-App; and

second program code configured to cause the at least one processor to cooperate with the UEV-App,

wherein the UEV-App comprises:

second information relating to an electronic value of the UEV-App;

third program code configured to cause the at least one processor to access the second information;

second encryption keys for accessing the plurality of EV Apps; and

fourth program code configured to cause the at least one processor to cooperate with the plurality of EV Apps,

wherein the second program code causes the processor to execute first authentication based on the first encryption key and access the UEV-App, and

wherein the fourth program code causes the processor to execute second authentication based on the second encryption keys and access the plurality of EV-Apps.

XI. Claim 1 of the fifth auxiliary request adds near the end of feature 9 of claim 1 of the second auxiliary request "one of the plurality of balance change means". It also replaces in the eleventh feature the "storage areas for storing the balance of the utility electronic value" with "the storage means (32)" and the "programs for processing of changing the balance" with "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)". Finally, it replaces in features 9, 11, 13 to 15 "cooperate" or "cooperating" with "communicate" or "communicating".

XII. Claim 1 of the sixth auxiliary request adds to the end of feature 11 of claim 1 of the fifth auxiliary request that the utility electronic value app further includes

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

XIII. Claim 1 of the seventh auxiliary request replaces the first information feature of claim 1 of the fourth auxiliary request with "first information relating to a balance of an electronic value of an EV-App" and the second information feature with "second information relating to a balance of a utility electronic value of the UEV-App, wherein the utility electronic value is mutually exchangeable with any of the electronic values of the EV-Apps". It also adds at the end of the claim:

"the payment terminal further comprising program code configured to cause

processing of inquiring the balance of the utility electronic value stored in the UEV-App and of inquiring the balance of the electronic values stored in the EV-Apps,

processing of adding a specified recharge amount to the balance of the utility electronic value stored in the UEV-App in response from at least one selected EV-App that the specified recharge amount has been subtracted from the at least one selected EV-App, wherein the processing of adding a specified recharge amount is repeated for one or more selected EV-App of the plurality of EV-Apps until the balance of the electronic utility value becomes equal to a required recharge amount,

processing of subtracting the required recharge amount from the balance of the utility electronic value stored in the EUV-App and of requesting one EV-App to be used for payment to add the required recharge amount to the balance of its respective electronic value,

processing of subtracting a payment amount from the balance of the one EV-App to be used for payment and of transmitting a corresponding processing result to a payment terminal".

XIV. Claim 1 of the eighth auxiliary request adds after the second information feature of claim 1 of the seventh auxiliary request that the UEV-App further comprises "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".

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.

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.

Order

For these reasons it is decided that:

The appeal is dismissed.