T 1724/16 15-07-2021

1. Decision in written proceedings

Following the opponent's statement that they would not participate in or be represented at oral proceedings, the oral proceedings were cancelled. The decision is therefore issued in writing (Article 12(8) RPBA 2020) on the basis of the requests, grounds and evidence present on file and taking into account the Board's preliminary opinion.

2. Article 100(c) EPC 1973

2.1 The transaction authorisation system of claim 1 comprises a user interface unit including:

"a card reader device (35) ... wherein the card reader device (35) is arranged to read data from a card to be charged for the transaction".

Claim 1 of of the application as originally filed (PCT/GB01/02275, published as WO 01/91073 A1) did not define a card reader.

2.2 Granted claim 1 also comprises the following feature:

"a transaction authorisation request based on the user inputs on the transaction, on data on the card read by the card reader device (35) and on the location identifier".

The corresponding feature of claim 1 of the application as originally filed reads as follows:

"an authorisation request based on the transaction authorisation and location identifier".

2.3 The opponent points out that these amendments were said by the proprietor (then the applicant, see letter dated 12 April 2010) to be principally based on claim 17 of the application as originally filed, which reads:

"A transaction authorisation system according to any preceding claim, in which the user interface unit includes a card reader device, wherein the card reader device is arranged to read data from a card to be charged for the transaction, the user interface unit processing the data read from the card to form at least a part of a transaction authorisation."

2.4 It is not disputed that original claim 17 discloses that data read from a card by a card reader may be used in forming a part of the transaction authorisation request.

However, the opponent argues that the final clause of original claim 17 discloses that the card data is incorporated into the transaction authorisation request in a specific way, being first processed by the user interface unit.

In claim 1 as granted this has been replaced by the formulation: "based ... on data on the card read by the card reader device", which, according to the opponent, is broader than the disclosure of original claim 17, thereby extending the claimed subject-matter beyond the content of the application as originally filed.

2.5 Two passages from the description are also cited by the opponent and the Opposition Division in this respect. The first is from page 9, lines 12-19 of the published application, corresponding to page 8, line 30 to page 9, line 5 of the description as originally filed (in the following the Board does not limit itself to the exact lines cited by the opponent or the Opposition Division):

"The user inserts a credit or debit card into the card reader device 35, which obtains the necessary card details including card number and expiry date. The user then enters an authorisation code associated with the card via the keypad 37. The user interface unit 30 communicates with the utility meter 10 and passes the transaction code and card data to the utility meter 10. These are combined at the utility meter 10 with the identification code to form an authorisation request. Preferably, parts or all of authorisation request are encrypted at the utility meter 10 and/or at the user interface unit 30."

2.6 The second passage is from page 13, lines 11-18 of the published application (page 12, lines 20-27 of the description as originally filed):

"Whilst the processing and composition of an authorisation request is performed at the utility meter 10 in the above described embodiment, it is equally possible that the identification code is obtained from the utility meter 10 by the user interface unit 30, combined with the card data, transaction code and authorisation code, encrypted and then communicated to the utility meter 10. At the utility meter 10, any necessary data packeting and the like are performed prior to transmission. Encryption algorithms such as DES, RSA or any other available mechanism may be used."

2.7 Hence, the data forming the transaction authorisation request may be subject to encryption and "any necessary data packeting and the like", in which case the final transaction authorisation request would not comprise raw input data (user input, card data and location identifier), but data derived from the input data. This was reflected in original claim 1 by the phrase "based on the transaction authorisation and location identifier" and in original claim 17 by the phrase "processing the data read from the card".

In the view of the Board, both of these formulations are intended to convey the same idea, namely that the user input, card data and location identifier may be transformed in some way (e.g. by encryption or data packeting) before being incorporated into the final transaction authorisation request. The Board therefore judges that applying the term "based on", instead of "processing", to the card data also does not add any new subject-matter.

2.8 Original claim 17 discloses the feature that the "processing" takes place in the user interface unit, which is not in granted claim 1. However, the skilled person would appreciate that this is merely an example, and that other possibilities are disclosed in the application as originally filed. For example, according to the first passage cited above, the utility meter combines and encrypts the data, whereas, according to the second cited passage, this is done at the user interface unit. Hence, no extension of subject-matter is seen in this respect either.

2.9 For the reasons given above in relation to claim 1 (and for the corresponding reasons in relation to method claim 28), the Board finds that the cited ground of opposition of Article 100(c) EPC 1973 does not justify the revocation of the patent as granted.

3. Article 100(b) EPC 1973

3.1 The opponent is correct that claim 1 of the granted patent includes embodiments where the user interface unit may be remote from the utility meter; this is explicitly stated in dependent claim 23. The opponent argues that such embodiments would not allow the user to securely carry out financial transactions of the kind known as "card present" transactions (see e.g. paragraph [0008] of the description of the contested patent).

However, even if this were true, it would mean that at least some embodiments of claim 1 would fail to achieve an effect (allowing "card present" transactions to be securely carried out) which is not claimed, but only mentioned in the description. Since the effect is not part of the invention defined by claim 1, the fact that certain embodiments might be unable to achieve this effect is not a reason for concluding that the invention is insufficiently disclosed.

3.2 In addition, the Board has explained above (point 2.7) how it interprets the term "based on" in claim 1, and does not see why such a formulation would present any difficulties of implementation for the skilled person.

3.3 The ground of opposition pursuant to Article 100(b) EPC 1973 does not, therefore, justify the revocation of the patent as granted.

4. The question of the admission of E6 into the procedure

4.1 The Opposition Division decided not to admit E6 into the procedure on the grounds that it was late filed and not prima facie relevant (Reasons, points 4.1.2.1 to 4.1.2.3). The Board therefore has the discretion not to admit this document into the appeal procedure pursuant to Article 12(4) RPBA 2007. In the statement of grounds of appeal the opponent argued that the subject-matter of claim 1 lacked novelty over E6, but did not address the decision of the Opposition Division not to admit this document into the procedure.

4.2 According to established case law:

"a Board of Appeal should only overrule the way in which a first instance department has exercised its discretion if it comes to the conclusion either that the first instance department in its decision has not exercised its discretion in accordance with the right principles ... or that it has exercised its discretion in an unreasonable way, and has thus exceeded the proper limits of its discretion" (G 7/93, Reasons, point 2.6).

4.3 The Board noted in its communication under Article 15(1) RPBA 2020 (point 5.1) that the decision of the Opposition Division not to admit E6 into the procedure on the grounds that it was late-filed and prima facie not relevant did not appear to be manifestly unreasonable nor to have been based on wrong principles; the Board was not, therefore, inclined to overrule it.

4.4 Since the opponent has not submitted any further arguments on this matter, the Board sees no reason to alter its previously-stated view. Document E6 is therefore not admitted into the appeal procedure.

Consequently, the question of novelty will be considered in relation to document E1 only.

5. Article 100(a) EPC 1973: Novelty in Relation to E1

5.1 The concrete elements of claim 1 appear to be disclosed in E1, that is to say:

- a user interface unit (e.g. control unit 22 in Fig. 2) capable of accepting user inputs (via keypad 18, see column 3, lines 17-21) including a card reader device (14) arranged to read data from a card to be charged for the transaction (column 6, lines 51-60);

- a utility meter (column 7, lines 19-22); and

- a remote authorisation authority (column 3, lines 42-51).

Moreover, the meter of E1 is associated with an identifier (the electricity meter number, see column 4, lines 14-21 and Fig. 4) which would be unique and specific to its location (it is implicit that the electricity supply company would have a record of the location of each meter, identified by its unique electricity meter number).

5.2 According to claim 1, the utility meter and the user interface unit are arranged to communicate to generate a transaction authorisation request based on three types of data:

(a) the user inputs on the transaction;

(b) data on the card read by the card reader device; and

(c) the location identifier;

and to transmit the transaction authorisation request to a remote authorisation authority.

5.3 In the arrangement of E1 (column 6, lines 1-68) a transaction (actuation of, or payment for, a utility) may be requested by inserting a charged actuator card into the card reading device, the information contained on the card being communicated to a respective main computer (column 6, lines 3-10). Hence, the transaction request disclosed in E1 comprises only data on the card read by the card reader device.

As explained in the following, several features of claim 1 are not disclosed in E1.

5.4 Firstly, E1 does not disclose that the utility meter and the control unit communicate for the purposes of generating and transmitting a transaction authorisation request. According to one embodiment of E1 (column 7, lines 46-52), the meter communicates with the card, and hence implicitly with the card reader, which is part of the control unit. However, this is only disclosed for the purpose of storing a meter reading in the memory of the card, not for generating and transmitting a transaction authorisation request.

5.5 Secondly, E1 does not disclose the incorporation of the location identifier into a transaction authorisation request. According to E1 (column 4, lines 14-20), an electricity meter number may be stored on the card, but why this is done or what use is made of the stored meter number is not stated. It is not disclosed that the electricity meter number is incorporated into a transaction request communicated to a main computer, nor is this implicit; it appears to the Board more likely that this feature is connected with storing a meter reading in the memory of the card, as disclosed in column 7, lines 46-52.

5.6 Thirdly, E1 does not disclose that a transaction authorisation request (e.g. a request for the supply of electricity) would incorporate user input data. The input data in E1 is merely a PIN code to avoid unauthorized use of the card (see column 3, lines 17-21). It is not disclosed that this data is sent to the main computer, nor is this implicit; the PIN could be validated locally within control unit 22.

5.7 The Board therefore judges that the transaction authorisation system of claim 1 (and, for the same reasons, the method of claim 28) is new within the meaning of Article 100(a) EPC 1973 in conjunction with Article 54 EPC 1973.

6. Article 100(a) EPC 1973: Inventive Step in Relation to E1

6.1 The transaction authorisation system of claim 1 differs from E1 in the features set out above under points 5.4, 5.5 and 5.6.

6.2 According to the opposed patent, the invention addresses the problem of providing secure authorisation of transactions, in particular financial transactions (paragraph [0001]), and the opponent agreed that the technical effect of the claimed invention "is to enhance security of transactions against fraud" (statement of grounds of appeal, page 4, final paragraph).

6.3 It is therefore to be determined whether, on the basis of the common general knowledge in the art, and in the light of the problem to be solved, it would be obvious to the skilled person to arrive at the features distinguishing claim 1 over E1, as identified above under points 5.4, 5.5 and 5.6.

6.4 The Board can accept that the skilled person would arrive at the feature mentioned above under point 5.6 (the transaction authorisation request incorporating user input data) without inventive activity. Although the user input data in E1 (a PIN code) is not disclosed as being sent to the main computer or as relating to a particular transaction, the possibility of using PIN codes in the validation of transactions would be well-known to the skilled person, and would represent an obvious possible additional security measure.

6.5 However, the Board does not accept that the features mentioned above under points 5.4 (the utility meter and the user interface unit being arranged to communicate to generate a transaction authorisation request) and 5.5 (the transaction authorisation request being based inter alia on the location identifier) would be obvious to the skilled person on the basis of E1 and common general knowledge.

6.6 The conventional function of a utility meter is to measure the usage of a utility and to communicate the result of that measurement, either by a direct reading or by sending the measurement data to a remote entity (for example, to the card memory in E1, as disclosed in column 7, lines 46-52).

The Board finds no disclosure or hint in E1 that the meter may be used for any purpose unrelated to metering utility usage, in particular for the entirely different purpose of communicating with a user interface unit in order to generate a transaction authorisation request. Moreover, no evidence has been adduced by the opponent that the use of utility meters for such a purpose constitutes part of the common general knowledge in the art.

6.7 The opponent argued that there are embodiments of E1 in which the card would only work with a specific control unit, and hence a specific meter (column 4, lines 23-31), and that this "requires that information on the meter and on the card is somehow compared, which requires communication between the card reader and the meter" (statement of grounds of appeal, page 5, first paragraph).

However, while this passage implicitly discloses communication between the card and the meter, it is merely to enable the or each memory device on the card "to effect meter reading". As noted above, this type of communication between the card and the meter for storing a meter reading in the card memory is also disclosed in column 7, lines 46-49, but has nothing to do with the claimed communication between the utility meter and the user interface unit to generate a transaction authorisation request.

6.8 The opponent points out that E1 discloses an electricity meter number (column 4, lines 14-23) and the Board accepts that this would correspond to the claimed location identifier. However, this is the only passage in E1 mentioning the electricity meter number, and it is only mentioned as an example of the information which could be stored on the memory devices of the actuator card. It is not stated why the electricity meter number might be stored in card memory device, and there is nothing in this passage which suggests the incorporation of the electricity meter number into a transaction authorisation request.

6.9 The Board therefore judges that, taking into account the available prior art, the transaction authorisation system of claim 1 (and, for the same reasons, the method of claim 28) involves an inventive step within the meaning of Article 100(a) EPC 1973 in conjunction with Article 56 EPC.