T 1416/16 () of 20.10.2020

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division refusing the European patent application No. 09 743 702.4 (published as WO 2009/137716 A2).

The decision under appeal was a so-called "decision on the state of the file" (see also Guidelines for Examination in the EPO, November 2019, C-V, 15). In the impugned decision the examining division made reference to its communication of 16 July 2015 (annex to the summons to oral proceedings), in which it had raised objections against the claims then on file for added subject-matter (Article 123(2) EPC), lack of clarity (Article 84 EPC) and lack of inventive step (Article 56 EPC).

II. The appellant (applicant) requested that the decision under appeal be set aside and that a patent be granted on the basis of the Main Request or one of the 1**(st) and 2**(nd) Auxiliary Requests, all filed with the statement of the grounds of appeal. Moreover, the appellant requested, as a further auxiliary measure, the remittal ("remanding") of the application to the examining division for further prosecution (see statement of the grounds of appeal, point 2).

III. The board summoned the appellant to oral proceedings and issued also a preliminary opinion, according to which all the requests on file comprised added subject-matter and thus did not comply with the requirements of Article 123(2) EPC. Moreover, the board stated that it did not see any reason at that stage that could justify a remittal of the case to the examining division.

IV. The appellant responded and presented arguments against the opinion of the board. During the oral proceedings, which were held through video conference at the request of the appellant, the appellant filed a 3**(rd) Auxiliary Request. The decision of the board was announced at the end of the oral proceedings.

V. The final requests of the appellant were that the decision under appeal be set aside and that a patent be granted on the basis of the Main Request, or one of the 1**(st), 2**(nd) and 3**(rd) Auxiliary Requests.

VI. Claim 1 of the Main Request is worded as follows:

A computer-implemented method for generating a child product that is linked to a core account, the method comprising:

authenticating a user with a financial institution, comprising:

receiving a trigger from a merchant;

transmitting a listing of financial institutions offering the ability to generate child products to the merchant in response to receiving the trigger; receiving a selection of a first financial institution based on the listing of financial institutions; and

authenticating a user with an authentication server of the selected financial institution;

receiving a selection of control parameters from the user, wherein the control parameters define use restrictions for the child product;

receiving a selection of the core account from the user, wherein the core account provides financial backing for the child product;

generating the child product to be used for payment transactions within the use restrictions defined by the control parameters;

storing a record of the child product as well as the use restrictions defined by the control parameters within a memory of a computing device; and

delivering the child product to the user.

VII. Claim 1 of the 1**(st) Auxiliary Request has the same wording with claim 1 of the Main Request except that the feature "authenticating a user with a financial institution, comprising:" has been deleted from the first part of the claim.

VIII. Claim 1 of the 2**(nd) Auxiliary Request has the same wording as claim 1 of the 1**(st) Auxiliary Request with the addition of the feature "wherein at least two of the financial institutions implement correspondingly different methods for authenticating the user" in the step "authenticating a user with an authentication server of the selected financial institution".

IX. Claim 1 of the 3**(rd) Auxiliary Request has the same wording as claim 1 of the 1**(st) Auxiliary Request except that the feature "authenticating a user with an authentication server of the selected financial institution" has been deleted.

X. The appellant argued essentially that the passage in paragraph [0038] of the application as filed provided the necessary basis for the objected features. The appellant's arguments are dealt with in the reasons for the decision.

Reasons for the Decision

1. The appeal is admissible.

2. The claimed invention

2.1 The claimed invention relates to a computer implemented method and a system for generating and distributing financial child products.

A financial child product is a product that can be used to carry out payments, e. g. to merchants. The financial child product is associated with a payment account (e. g. bank account) of a user, which is held with a financial institution (e. g. a bank). Such financial products are, in the context of the present application, credit/debit/gift cards, prepaid cards, etc.

2.2 However, not all financial institutions have the necessary computer implemented infrastructure to support the generation, distribution and management of such child products. In such cases, users turn to other, third party providers for their financial child products.

The application proposes the use of a "payment processing platform", as an intermediary between a user, who wishes such a financial child product, and a financial institution holding the user's account ("core account"). In such a case, the financial institution is not required to update/modify its systems, since all the necessary actions related to the financial child products are taken over by the payment processing platform that is more flexible and easier to modify/update if necessary (see Figure 2 of the published application)

2.3 The claims relate to the generation of such financial child products.

In order to generate such a financial child product, a user, after being authenticated by the financial institution, provides the payment processing platform with a core account to be associated with the child product. The user can set use restrictions ("control parameters") for the financial child product. Such a restriction may be a maximum payment amount per transaction, a validity period of the child product, etc. The payment processing platform generates the requested financial child product and distributes it to the requester (see Figure 3A).

3. Main Request

Apart from some linguistic amendments in claim 11, the claims of the Main Request correspond to the claims filed on 31 July 2013, which constitute the main request underlying the impugned decision.

3.1 Added subject-matter (Article 123(2) EPC)

3.1.1 It is uncontested that, according to the method defined in claim 1 of the Main Request (see point VI above), the generation of the financial child product, including the authentication of the user, takes place during a transaction between the merchant and the user.

The board understands the claimed method as follows: A user connects to a merchant website and selects desired goods or services. It is to be noted that the claim does not specify that the transaction is necessarily an online transaction, it can also be a "normal" one, i. e. a user enters the store of a merchant. At the moment the user needs to pay the merchant, the user decides to use a financial child product. The child product needs to be generated first. A trigger is sent via the merchant's computer system (to the payment platform) and as a response a list of financial institutions able to generate child products is transmitted to the merchant. The user selects one of the financial institutions from the list, and then the process of generating the child product is carried out (see Figure 3A), starting with the user being authenticated by the financial institution.

3.1.2 The question was whether such a procedure for generating a child product during the transaction with a merchant had a basis in the originally filed application. In particular, whether the claimed method is generally applicable to all types of financial products described in the application.

3.1.3 A method for generating a financial child product is schematically presented in Figure 3A (see also paragraph [0045] of the published application). As shown in Figure 3A, the first step (300) of the method relates to authenticating a user. The initial steps of the procedure for generating a child product including various possible implementations of the user authentication step are described in paragraphs [0033] to [0035], and [0046] to [0050] of the application.

In none of these implementations of the user authentication is a merchant involved.

3.1.4 The general description of the use of child products for carrying out transactions with merchants is described in paragraphs [0070] to [0085] (two embodiments). In neither of these two embodiments an authentication of the user during a transaction with the merchant is disclosed or suggested.

3.1.5 The appellant pointed to claim 2 and paragraph [0038] of the application as originally filed (see published application) as basis for these features (see point 3.3 of the statement of the grounds of appeal).

3.1.6 Paragraph [0038] of the application describes carrying out of a transaction between a user and a merchant using a specific type of a financial child product, a PIN debit child product 202 (see also Figure 2). According to this paragraph (see last sentences, starting with "In another embodiment..."), the user can generate the specific financial child product during the transaction with the merchant (as defined in claim 1), suggesting that it is not necessary for the user to have such a financial child product in advance (i. e. before initiating the transaction with the merchant).

3.1.7 The appellant argued that this embodiment was not limited to the specific child product (202) (see also the appellant's letter of 18 September 2020, point 3).

According to the appellant, the skilled person would readily understand that the procedure described in paragraph [0038] was applicable to all the financial child products described in the application and was not limited only to the PIN debit child product 202.

The procedure could also be applied for child products that did not require a PIN and so it was not specific to the PIN debit child product 202.

Moreover, the PIN debit child product 202 was the first to be described in the application and the skilled person would understand that the described procedure applied also to the child products described in the subsequent paragraphs.

Finally, the use of the plural "products" in the expression "...the payment processing platform transmits a listing of financial institutions offering the ability to generate child products to the merchant" indicated that the method referred to all types of child products described in the application.

3.1.8 The appellant's arguments do not convince the board.

As mentioned previously (see points 3.1.3 and 3.1.4), in the parts of the description which refer to the general procedures of generation of child products and their use during a transaction with a merchant, there is no indication of any involvement of a merchant during the generation of the child product. The procedure described in paragraph [0038] and defined in claim 1 is to be regarded, thus, as a modification of and exception to the generally formulated procedure.

The various child products (202 to 216) are described separately in corresponding paragraphs of the description ([0038] to [0044]). The claimed features appear only in paragraph [0038], which relates to the PIN debit child product 202, but not in any of the paragraphs describing the other child products. There is no reference either to these features in any of the paragraphs describing other types of child products.

3.1.9 Furthermore, the board is of the view that it is readily understandable that the procedure of claim 1 cannot be applied to all the other types of child products. For example, a gift card (210) must be generated in advance and cannot be generated at the moment of the purchase of the gift (present), otherwise it does not serve its purpose, i. e. of offering a present to someone. The same applies to a prepaid card 206, which, as its name indicates must be paid in advance (i. e. before the transaction with the merchant). A virtual card 204 as a credit card cannot normally be generated on the spot, as the financial institution usually makes a credit check of the user before issuing a credit card.

In addition, as the application repeatedly mentions, such cards (gift cards, prepaid cards, etc.) can be generated as a physical card instead of or in addition to a virtual card (see for example paragraph [0008]). The generation and distribution of such a physical card to the user during a transaction with a merchant does not seem feasible.

3.1.10 Finally, the board does not consider the fact that the paragraph mentions the ability to generate "child products" and not the specific PIN debit child product 202 to be a strong indication that this procedure is generally applicable to all child products (see also the paragraph bridging pages 3 and 4 of the appellant's letter of 18 September 2020).

In the board's view, the skilled person when reading the description would readily understand the procedure of paragraph [0038] to apply only to the specific child product (PIN debit child product 202), as already explained (see points 3.1.8 and 3.1.9). In this context, the skilled person would read the term "child products" as referring to those described in the same paragraph, i. e. PIN debit child products 202 and not to all the child products described in the application.

3.1.11 The board's view is, thus, that the procedure of paragraph [0038] can not be regarded as generally applicable to all types of financial child products, but is limited only to the PIN debit child product 202.

3.1.12 Regarding original claim 2, the board notes that neither original claim 2 nor original claim 1 (on which claim 2 depends) comprise any feature(s) relating to the authentication of the user with a financial institution (server). Hence, the combination of the features in claim 1 of the Main Request is not supported by a combination of original claims 1 and 2.

3.1.13 The board concludes, therefore, that the method defined in claim 1 of the Main Request constitutes an intermediate generalisation which goes beyond the originally filed content of the application, contrary to the requirements of Article 123(2) EPC.

4. 1**(st) and 2**(nd) Auxiliary Requests

4.1 Claim 1 of both the 1**(st) Auxiliary Request and the 2**(nd) Auxiliary Request comprises the features related to receiving a trigger from the merchant, transmitting a listing of financial institutions offering the ability to generate child products to the merchant in response, receiving a selection of a first financial institution based on the listing of financial institutions and authenticating a user with an authentication server of the selected financial institution.

4.2 For the same reasons as for the Main Request, the board concludes that Claim 1 of the 1**(st) Auxiliary Request and the 2**(nd) Auxiliary Request does not meet the requirements of Article 123(2) EPC.

4.3 In addition, claim 1 of the 2**(nd) Auxiliary Request comprises the following added feature, underlined by the board:

authenticating a user with an authentication server of the selected financial institution, wherein at least two of the financial institutions implement correspondingly different methods for authenticating the user;

4.3.1 The appellant referred to paragraphs [0034], [0035] and [0046] to [0050] as basis for this amendment (see point 5.1 of the statement of the grounds of appeal).

4.3.2 As explained above (see point 3.1.3), these paragraphs describe different possible implementations of the user authentication step during the generation of a child product and indicate no involvement of any merchant in this step. Hence, these parts provide no basis for the transmission of the listing of financial institutions after receiving a trigger by a merchant, so that they cannot provide a basis for the added feature either.

4.3.3 Even paragraph [0038], which describes the transmission of the list of financial institution to a merchant after receiving a trigger, does not provide any information or any suggestion about the user authentication methods implemented by the financial institutions in the transmitted listing or that at least two of the financial institutions implement correspondingly different user authentication methods.

4.3.4 The board concludes, thus, that the feature added in claim 1 of the 2**(nd) Auxiliary Request goes beyond the content of the application as originally filed (Article 123(2) EPC).

5. 3**(rd) Auxiliary Request

5.1 The 3**(rd) Auxiliary Request was filed during the oral proceedings before the board, after the board had expressed its opinion that the requests on file did not meet the requirements of Article 123(2) EPC.

5.2 The appellant stated that the request addressed the objection under Article 123(2) EPC held by the board against the other requests on file. In addition, it was based on the 1**(st) Auxiliary Request and did not add any new subject-matter. Moreover, the appellant made reference to the arguments submitted with its letter of 31 October 2012 to the examining division and explained that there were no new arguments to deal with, since those arguments supported the submitted 3**(rd) Auxiliary Request. Finally, the appellant noted that the examination procedure was rather short as there had been only one communication by the examining division before the summons to oral proceedings and so it had no chance to explore which way might lead to a patent.

5.3 The board notes that claim 1 of the 3**(rd) Auxiliary Request is a combination of original claims 1 and 2, and seems to overcome the objection under Article 123(2) EPC raised against the previous requests.

5.4 The board notes also that claim 1 does not comprise any reference at all to a step of authenticating the user during the generation of the child product.

5.4.1 Ever since the first submission of the appellant (then applicant) during examination, with the letter of 31 October 2012 (which the appellant referred to), the features related to the user authentication have always figured in the claims (see claims filed with that letter and with letter of 31 July 2013, as well as the claims underlying the decision under appeal). The applicant in its argumentation about novelty and inventive step has consistently put this feature forward as the main feature distinguishing the claims from the prior art (see for example the first sentences of points 5 and 6 in the letter of 31 October 2012 and of point 6 in the letter of 31 July 2013). The same is true for the grounds of appeal (see for example page 6 of the statement of the grounds of appeal).

5.4.2 By deleting this feature from claim 1 of the 3**(rd) Auxiliary Request, the appellant removed the feature that it has consistently regarded as the feature that rendered the claimed subject-matter inventive over the state of the art. This raises prima facie questions as to whether the subject-matter of claim 1 is at all inventive.

In addition, by removing the user authentication from the claimed method, the 3**(rd) Auxiliary Request is not converging in respect to the other requests on file. The discussion would take a different direction from what has consistently been its theme until now, introducing, in essence, a fresh examination case. The board considers that such a discussion would fall beyond the scope of the present appeal.

5.4.3 Hence, the board, exercising its discretion under Article 13(2) Rules of Procedure of the Boards of Appeal (RPBA 2020), decided not to admit the 3**(rd) Auxiliary Request into the procedure.

6. Since the Main Request, the 1**(st) Auxiliary Request and the 2**(nd) Auxiliary Request are not allowable, and the 3**(rd) Auxiliary Request is not admitted in the procedure, the appeal must fail.

Order

For these reasons it is decided that:

The appeal is dismissed.