T 0844/09 () of 5.2.2013

Summary of Facts and Submissions

I. This is an appeal against the refusal of application 01 951 030 for lack of an inventive step, Article 56 EPC 1973.

II. At oral proceedings before the board, the appellant applicant requested that the decision under appeal be set aside and that a patent be granted in the following version:

Description: Page 1 as filed during the oral proceedings;

Pages 2 to 10 as published;

Claims: 1 to 11 as filed during the oral proceedings;

Drawings: Figures 1 and 2 as published.

III. Claim 1 reads as follows:

"A computer-implemented method of operating a verification system (100) for verifying details of transactions drawn upon a financial account and a user's authorization to use the financial account, the method comprising:

receiving from a user, at a user interface (102), information identifying (204) a financial account which the user desires to use, before the user may initiate an online transaction using the financial account;

generating (208) a series of verifying transactions involving the financial account, with selected details of the transactions not being known to the user;

initiating (210) the series of verifying transactions from a transaction processor (106);

storing in storage means within the verification system a first set of details of said series of verifying transactions;

receiving (216) from the user, at the user interface, a test set of details, to include specified details of evidence of the verifying transactions retrieved by the user from his or her financial account;

comparing (218) said test set of details to said first set of details; and

if said test set of details matches said first set of details, authorizing (220) the user to conduct online transactions using the financial account."

Claim 5 reads as follows:

"A system (100) for verifying a user’s authorization to use an external financial account through automated verification of details of a set of transactions drawn upon the account, comprising:

a transaction processor (106) configured to initiate (210) one or more verifying transactions involving an external financial account identified (204) by a user, with selected details of the transactions not being known to the user;

a memory configured to store a first set of details of said transactions that the user must confirm before the user may initiate an online transaction using the external financial account;

a user interface (102) configured to receive (216) a test set of details, to include specified details of evidence of the verifying transactions retrieved by the user from his or her financial account; and

a processor configured to compare (218) said first set of details and said test set of details, wherein said processor is further configured to authorize (220) the user to use the external financial account if said test set of details matches a predetermined subset of said first set of details."

Claim 10 reads as follows:

"A computer program which when executing on a computer system (100) is configured to perform the steps of any one of claims 1 to 4."

Claim 11 reads as follows:

"A computer-readable storage medium, including the computer program of claim 10."

IV. Reference is made to the following prior art documents:

D1: WO 95 06294 A

D2: US 5 053 606 A

D3: WO 95 16971 A

D4: US 5 963 917 A

V. The appellant in substance provided the following arguments:

There was no basis in the EPC for discounting any features of a claim for not being technical in the consideration of inventive step. Moreover, at any rate because the method of claim 1 was defined to be computer-implemented, all features of the claim were technical and had to be considered for inventive step.

The problem solved by the present invention, namely verifying ownership of an external financial account in the context of an electronic transaction and preventing/detecting electronic fraud, was a technical problem, which was solved by technical means.

The method of claim 1 was different from D3 in a number of ways. First, according to claim 1, the process of authorizing a user to use a certain financial account involved automatically triggering the generating and initiating of verifying transactions with respect to the financial account. This technical feature of responding to information actively received via a user interface in this particular manner was not contemplated by D3. Second, the technical effect of using details of transactions with respect to the financial account, as opposed to a pre-generated list of transaction identifiers as in D3, was that it eliminated the need for communicating any such list to the user outside of the secure communication channel that had already been established by a financial institution for the purposes of permitting the owner of a financial account to access information with respect to financial transactions. Third, D3 did not disclose using details of a financial transaction with respect to an account to verify the user’s authorization to use the account.

Accordingly, the subject-matter of claim 1 was new and involved an inventive step over D3.

Reasons for the Decision

1. The appeal is admissible.

2. Amendments

Claims 1 based on claim 13 as originally filed and on the description, page 1, lines 30 to 32, page 5, line 23 to page 6, line 14 and page 8, line 27 to page 9, line 9.

Independent claim 5 is based on claims 30, 31 as originally filed and on the same passage above of the description.

Dependent claims 2 to 4 are based on originally filed claims 14, 15 to 19 and 20 to 24, respectively.

Dependent claims 6 to 11 are based on originally filed claims 32, 36, 37, 38 and 29, respectively.

Accordingly, the amendments comply with Article 123(2) EPC.

3. Article 52(2) and (3) EPC

3.1 Claim 1 concerns a computer-implemented method of operating a verification system for verifying details of transactions drawn upon a financial account and a user’s authorization to use the financial account. It thus relates to the field of schemes, rules and methods for doing business, which shall not be regarded as inventions pursuant to Article 52(2)(c) EPC. The corresponding features in claim 1 are deemed to be non-technical. The method of claim 1 is, however, defined to be computer-implemented and thus involves a computer as technical means, with a transaction processor, storage means and a user interface. The corresponding features in claim 1 are technical. Claim 1, thus, contains both non-technical and technical features and has technical character as a whole. Accordingly, the subject-matter of claim 1 is not a scheme, rule or method for doing business as such. The patentability of the subject-matter of claim 1 is, therefore, not considered to be excluded under Article 52(2) and (3) EPC (cf T 258/03 (OJ EPO 2004, 575), reasons 3 and 4).

3.2 For the sake of completeness, it is moreover noted that the subject-matter of claim 10, directed to a computer program which when executing on a computer system is configured to perform the steps of any one of claims 1 to 4, is not excluded from patentability under Articles 52(2) and (3) either, since the computer program, when it is run on a computer, produces a further technical effect, ie in transaction security as will become apparent from the discussion of inventive step below, which goes beyond the normal physical interaction between program and computer (cf T 1173/97 (OJ EPO 1999, 609), reasons 6).

4. Novelty

4.1 Document D3

4.1.1 Document D3 discloses a network payment system. In particular, "Figure 14 is a flowchart that describes the operation of the payment system. A client computer 71 constructs a payment order at 79, and computes and adds an authenticator to the payment order at 80. The payment order is sent at 81 to a payment computer, where the authenticator is verified at 82 to ensure that the payment order was originated by the sender it describes" (page 15, lines 28 to 34). After a number of further checks and steps, "settlement is performed at 92 in the external financial system 77 between external accounts that correspond to the sender and the beneficiary" (page 19, lines 17 to 19). According to one method for authenticators, "at step 80, the authenticator is obtained by querying the user for a transaction identifier that is the next string from a physical list of one-time authorization strings. Such a list could be produced on a card, and the user can cross off authorization strings as they are used. According to this method, at step 91, the authenticator is checked against the next expected string from the sender using database 76. Database 76 can hold for each sender a list of random authorization strings" (page 22, lines 7 to 16).

Accordingly, D3 discloses in the terms of claim 1, a computer-implemented method of operating a verification system for verifying a user’s authorization to use the financial account, the method comprising:

receiving from a user, at a user interface, information identifying a financial account;

generating a first transaction identifier;

storing in storage means within the verification system said first transaction identifier;

receiving from the user, at the user interface, a transaction identifier;

comparing said transaction identifier to said first transaction identifier; and

if said transaction identifier matches said first transaction identifier, authorizing the user to conduct online transactions using the financial account.

4.1.2 The subject-matter of claim 1 essentially differs from D3 in that rather than using transaction authentication strings from a list, details of evidence of a series of verifying transactions retrieved by the user from his financial account are used.

In particular, not disclosed in document D3 is

- generating (208) a series of verifying transactions involving the financial account, with selected details of the transactions not being known to the user;

- initiating (210) the series of verifying transactions from a transaction processor (106);

- storing in storage means within the verification system a first set of details of said series of verifying transactions;

- receiving (216) from the user, at the user interface, a test set of details, to include specified details of evidence of the verifying transactions retrieved by the user from his or her financial account;

- comparing (218) said test set of details to said first set of details; and

- if said test set of details matches said first set of details, authorizing (220) the user to conduct online transactions using the financial account.

4.1.3 Accordingly, the subject-matter of claim 1 is new over document D3 (Article 54(1) EPC 1973).

4.2 The subject-matter of claim 1 is also new over the remaining available, more remote prior art.

5. Inventive step

5.1 As noted above (cf point 3.1), claim 1 contains both technical and non-technical features.

According to established jurisprudence, an invention consisting of a mixture of technical and non-technical features and having technical character as a whole is to be assessed with respect to the requirement of inventive step by taking account of all those features, which contribute to said technical character whereas features making no such contribution cannot support the presence of inventive step. Where the claim refers to an aim to be achieved in a non-technical field, eg in the field of schemes, rules and methods for doing business as in the present case, this aim may legitimately appear in the formulation of the problem as part of the framework of the technical problem that is to be solved, in particular as a constraint that has to be met (cf "Case Law of the Boards of Appeal of the EPO", 6th Edition, I.D.8, T 641/00 (OJ EPO 2003, 352)).

5.2 In the summons to oral proceedings before the examining division, which forms the basis of the decision according to the state of the file requested by the applicant, it was argued that the overall aim of the present method was the increase of security of the financial transaction. In the application, this was done by means of the verification of a set of details which were provided by the user and which were related to previous transactions provided by the user. Such a measure was rather an administrative procedure, which needed to be implemented in a computer system in order to be applicable to online transactions. Since an administrative method was subject-matter excluded from patentability, an innovation in that area could not contribute to an inventive step in the sense of Article 56 EPC. The implementation in the computer system did not solve an additional technical problem involving an inventive step. The administrative method and its technical implementation were therefore not interdependent. Claim 1 and the application as a whole were therefore considered as a mere implementation of a non-technical activity. Such an implementation was straightforward for the person skilled in the art of payment systems and did therefore not involve an inventive step in the sense of Article 56 EPC.

5.3 The board, however, cannot concur with these findings.

Although verifying a user's authorization to use a financial account may in certain cases involve an administrative procedure lacking technical character, this is not considered to be the case for the subject-matter of claim 1.

The verification of the user's authorization to use a financial account in the present case, in particular the recognition that the retrieval by the user of transaction details offers a convenient and secure channel for forwarding transaction authentication information to the user, and the realization that "verifying" transactions can be generated and initiated to contain the transaction authentication information, relies on a technical understanding of the operation of the transaction system and its respective components and, thus, lies within the scope of a technically qualified person working in the field of computer-implemented online financial transaction systems and notably entrusted with the security aspects thereof.

Neither the business professional nor the administrative professional would, in the board's judgement, be qualified and indeed able to devise any of these ideas as they lie outside their areas of competence.

Accordingly, the above consideration relating to the verification of the user's authorization to use a financial account cannot be included in the formulation of the technical problem, contrary to what is essentially argued in the decision under appeal applying the principles of decision T 641/00 (cf above).

Still, the remaining features of claim 1 relating to a financial transaction refer to an aim to be achieved in the field of schemes, rules and methods of doing business, deemed to be non-technical, which may legitimately appear in the formulation of the problem (following T 641/00 above).

As will become clear below, however, this point has no further implications in the present case, as document D3 discussed above anticipates the remaining features of claim 1 relating to a financial transaction.

5.4 Document D3 is considered to provide the closest prior art.

As noted above, the core difference of the subject-matter of claim 1 over D3 is that rather than transaction authentication strings from a list, details of evidence of the verifying transactions retrieved by the user from his financial account are used.

As explained in the application, "a typical series of verifying transactions may include two deposits (to a bank account) or credits (to a credit card), each of which is between $ 0.01 and $ 0.99 in value, and may involve different merchant identities (e. g., 1234XYZCorporation, 5160XYZCorporation)" (page 9, lines 1 to 4). Furthermore "selected details (e. g., all or a subset of the variable details) of the transactions are saved (e. g., stored in a database) and the transactions are initiated (e. g., through transaction processors coupled to the appropriate financial systems or entities)" (page 9, line 7 to 9). Moreover, "The user's evidence of the transaction (s), which should include all or a subset of the details of the transaction (s), may be in the form of a monthly statement mailed to the user from his or her financial institution. Or, the user may take a more proactive approach and access his or her instrument or account status on-line or via telephone" (page 9, lines 19 to 22). Hereafter, "the system (e. g., a user interface) may prompt the user to enter the amount of each transaction, the merchant name (or the variable part thereof), the type of transaction, and/or any other detail that was stored" (page 9, lines 25 to 28).

The set of details queried from the user for authenticating the user and authorizing the financial transaction, thus, correspond in function to the transaction authentication strings of document D3. Yet they differ in form and in the way they are provided to the user.

Document D3, in fact, is silent on how the physical list of one-time authentication strings is provided to the user.

The effect of the distinguishing features of claim 1 over D3 in essence is that transaction authenticators are provided to the user in an alternative manner.

5.5 The appellant argued that since the user had to obtain transaction details online relating to a previous or test transaction, effectively he had to pass two levels of verification in order to use an account.

This argument is, however, not convincing. In conventional online-banking systems, involving the use of lists of Transaction Authentication Numbers (TAN) provided to the user like in D3, the user gains online access to a bank account via an internet site of his bank, typically by entering the bank account number and a password, thereby passing a first level verification. At this point, the user has eg direct access to his financial statements or can initiate a fund transfer for which a TAN will be needed. In the case envisaged in the application and covered by claim 1 where the transaction authenticator in the form of a set of details of evidence of a verifying transaction is available through online access to the financial statement of the bank account, a fraudulent user will, thus, have unrestricted access to the transaction authenticator. Accordingly, no second level verification needs to be passed in this case.

5.6 The objective problem to be solved relative to document D3, accordingly, is to provide transaction authenticators to the user in an alternative manner.

The claimed solution consists in:

- generating (208) a series of verifying transactions involving the financial account, with selected details of the transactions not being known to the user;

- initiating (210) the series of verifying transactions from a transaction processor (106);

- storing in storage means within the verification system a first set of details of said series of verifying transactions;

- receiving (216) from the user, at the user interface, a test set of details, to include specified details of evidence of the verifying transactions retrieved by the user from his or her financial account;

- comparing (218) said test set of details to said first set of details; and

- if said test set of details matches said first set of details, authorizing (220) the user to conduct online transactions using the financial account.

This solution is not rendered obvious by document D3.

5.7 Documents D1, D2 and D4

Document D1 discloses a method for automatically processing a loan, including completion of the application, underwriting, and transferring funds, including the use of a programmed computer to interface with an applicant, obtain the information needed to process the loan, determine whether to approve the loan, and effect electronic fund transfers to the applicant's deposit account and arrange for automatic withdrawals to repay the loan (page 3, line 3 to page 6, line 18). The applicant may apply by telephone, in which case his identity is verified using the telephone number by confirming the caller's name and address from a data base, and including perhaps a simple inquiry for verification of the caller's name, number, address and zip code (page 10, line 25 to page 11, line 17). Moreover, before the deposit is made, there are several checks made to prevent fraud, including verification of signature as well as comparison of information obtained from the borrower with that available from a credit report, such as date of birth and the number of years with a present employer (page 14, lines 8 to 12).

Document D1 does not suggest providing transaction authentication data for financial transactions to the user by generating and initiating of verifying transactions as claimed. Accordingly, the claimed solution is not rendered obvious by document D1.

Document D2 is concerned with communication processing between a credit authorization terminal and a host computer to perform settlement processing. The terminal continues to perform communication processing to perform settlement processing for one customer without hanging up the line between the terminal and the host computer, when communication processing is terminated for the previous customer (column 4, line 1 to column 5, line 13).

Document D2 does not suggest providing transaction authentication data to the user by generating and initiating a series of verifying transactions as claimed.

Finally, document D4 is concerned with an automated payment system particularly suited for purchases over a distributed computer network such as the internet. The customer's computer is linked to a payment processing computer and the customer's credit card number and the amount of the goods or services is transmitted to the payment processing computer. The payment processing computer automatically contacts a bank for verification of the credit card and amount. The bank transmits an authorization to the payment processing computer. The payment processing computer communicates a self-generated transaction indicium, and in some embodiments a password, to the customer's computer. The transaction indicium is generated by the payment processing computer for proper record keeping and also used by the customer to verify that an order has been generated and accepted. The customer's computer uses the password with the merchant's computer in obtaining access to protected information (eg a service) or to establish shipping instructions for a product (column 1, line 48 to column 2, line 43).

Document D4 does not suggest providing transaction authentication data for a financial transaction to the user by generating and initiating a series of verifying transactions as claimed.

The claimed solution is, thus, not rendered obvious by any one of the remaining cited documents D1, D2 and D4 either.

5.8 Accordingly, having regard to the cited prior art, the subject-matter of claim 1 involves an inventive step in the sense of Article 56 EPC 1973.

6. Independent claim 5 is directed to a corresponding system for verifying a user’s authorization to use an external financial account through automated verification of details of a set of transactions drawn upon the account. The subject-matter of claim 5 is new and involves an inventive step for in substance the same reasons given above for claim 1.

Also the subject-matter of claim 10, which is for a computer program which when executing on a computer system is configured to perform the steps of any one of claims 1 to 4, and of claim 11, which is for a computer-readable storage medium, including the computer program of claim 10, is new and involves an inventive step for the same reasons given above for claim 1.

7. Claims 2 to 4 and claims 6 to 9 are dependent on claims 1 and 5, respectively, providing further limitations. The subject-matter of these claims, therefore, also involves an inventive step.

8. The patent application as amended also meets the remaining requirements of the EPC, so that a patent can be granted on the basis of these documents.

ORDER

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the department of first instance with the order to grant a patent in the following version:

Description: Page 1 as filed during the oral proceedings;

Pages 2 to 10 as published;

Claims: 1 to 11 as filed during the oral proceedings;

Drawings: Figures 1 and 2 as published.