T 1463/11 (Universal merchant platform / CardinalCommerce) of 29.11.2016

Summary of Facts and Submissions

I. The applicant, CardinalCommerce Corporation, appeals the decision of the Examining Division to refuse European patent application 03760289.

II. The Examining Division found that claim 1 according to the main request and the third auxiliary request lacked inventive step, and that claim 1 according to the first and second auxiliary requests introduced subject matter extending beyond the content of the application as originally filed.

III. During the procedure, the Examining Division introduced the following documents:

D1: WO 01/18720

D2: WO 01/80100

D3: WO 01/82246

IV. With the statement setting out the grounds of appeal, the appellant filed a new main and two auxiliary requests. During the appeal procedure, the appellant filed further arguments, four sworn statements, and a copy of a new document (D4, US2003/0042301).

V. The Board arranged to hold oral proceedings.

With the summons, the Board set out its provisional view of the case. The Board expressed doubts as to compliance with Articles 84 and 123(2) EPC, and considered the invention to lack inventive step as a straightforward implementation, on a standard computer network, of non-technical measures (business measures and programming measures).

VII. In response, the appellant submitted further arguments regarding the three requests submitted with the statement setting out the grounds of appeal, and filed new third, fourth, and fifth auxiliary requests.

VIII. During oral proceedings before the Board, the appellant submitted an amended set of claims 1 - 14 for the main request.

IX. Claim 1 according to the main request reads as follows.

A computer-implemented method for processing authentication of a consumer (50) via a computer at a centralized merchant authentication processing system, MAPS, (200) using one of a plurality of different types of payment instruments to conduct a commercial transaction over a communications network with a server (100) operated by an online merchant, wherein the server (100) includes a thin client (106) operable to link information with the MAPS (200) upon demand and operable to format name/value pairs to a required MAPS message format and to securely communicate the message to the MAPS (200), wherein the payment instrument being used is either enrolled in or not enrolled in an authentication program conforming to one of a plurality of authentication protocols prescribed for the respective plurality of different types of payment instruments by payment networks (70, 72, 74, 76, 78) supporting the same, wherein the MAPS (200) comprises a connectivity layer (210) that sits on top a message distribution layer (220) that sits on top a plug-in layer (230) and an external connection layer (240), the method comprising:

(a) obtaining at the server (100) payment information for the transaction from the consumer (50) and forwarding the payment information to the MAPS (200) using the thin client (106), said payment information including a number identifying the particular payment instrument being used;

(b) determining at the MAPS (200) the type of payment instrument being used from the payment information, wherein the plug-in layer (230) of the MAPS includes a plurality of individual authentication initiative plug-in components (232) operable to listen to the message distribution layer (220) for a specific message type, wherein a respective plug-in component (232) is activated by the message distribution layer (220) that sends messages to the specified plug-in component (232) based upon the type of payment instrument being used for the transaction being processed;

(c) obtaining at the MAPS (200) an authentication determination from one of the payment networks (70, 72, 74, 76, 78) for the transaction in accordance with the authentication protocols prescribed for the determined type of payment instrument being used; and,

(d) the MAPS (200) returning the obtained authentication determination to the server (100) operated by the merchant.

In so far as relevant to the decision, the appellant's arguments can be summarised as follows.

The term "thin client" is a term of art. The skilled reader would understand the relative term "thin" as a comparison with the MAPS server, so that the thin client provided sufficient processing for the communication with the MAPS, but the MAPS is responsible for the "business logic" of actual authentication.

It would be clear to the skilled reader of the application as filed, that the key issue was to move the plug-ins from merchants' servers to the MAPS. That would require a form of communication between merchants' servers and the MAPS, but the details of the communication were not essential to the invention, beyond ensuring that the requisite data were transferred.

At the priority date, there was a prejudice against putting any part of the authentication process outside the merchants' servers. The four sworn statements testified to that. As a result, the skilled person would not have considered providing a MAPS server at all, let alone a MAPS server with the details defined in the claims.

At the end of the oral proceedings the appellant requested that the decision under appeal be set aside and that the case be remitted to the department of first instance with the order to grant a patent on the basis of the set of claims of the main request as filed during the oral proceedings before the Board.

Reasons for the Decision

Background

1. The invention is concerned with online shopping. A consumer, having decided to buy something from an online shop, chooses how to pay. That could be a choice of credit card or of some other means of paying. To complete the transaction, the consumer has to be authenticated. The online store will pass information about the intended transaction to the credit-card company (for example), which handles the task of ensuring the consumer is entitled to use the chosen means of payment, and which informs the online shop of the outcome.

2. The technical implementation of this authentication involves the server of the online shop (the "merchant server") communicating with the computer of the credit-card company (as it may be). This communication is conventionally handled by a "plug-in" in the merchant server, a piece of software specific to the particular authenticating authority and to the needs of the authentication process. There will be a plug-in for each of the different means of payment: one for one type of credit-card; one for another; one for direct transfer from a particular bank, and so on.

3. The invention is about the plug-ins. It does not change their function, or how they perform it. All that is unchanged. Rather, the plug-ins are no longer installed in each online shop, but are installed on a separate server that can be accessed by several online shops and that handles access to several authenticating authorities. The idea is to alleviate the shop's server from the installation and upkeep of the plug-ins.

4. Thus, the invention replaces the three-machine prior art (consumer's computer, merchant's server, authenticating server) with a four-machine system (consumer's computer, merchant's server, authenticating server, and "merchant authentication processing system" - MAPS).

The starting point for inventive step

5. Document D1 foresees a single payment instrument (an "ATM card"). Authentication involves the merchant's server, an authenticating server, and a consumer's computer. There is no mention of plug-ins or of the organisation of software in layers.

6. Document D2 foresees a plurality of payment instruments and corresponding plug-ins (D2, page 6, lines 12-14 for example). The term "plug-in" is not used, but that is what the payment clients are. They take the form, preferably, of thin clients (D2, page 9, lines 13 - 15). There is no disclosure of whether software is arranged in layers.

D3 foresees a plurality of payment instruments and corresponding plug-ins for authentication (D3, page 16, lines 3-6, for example). There is, again, no disclosure of software being arranged in layers.

8. The appellant, on appeal, has filed document D4. D4 is not prior art. It was published after the priority date of the present application. The appellant argues that it nevertheless reflects the prevailing thinking in the field at the priority date. If that is so, then D4 is a secondary indicium; but it cannot be a starting point for an assessment of inventive step.

9. The application sets out along the lines described above. While D1 is somewhat further away, because it deals with a single payment instrument, D2 and D3 are broadly similar to the disclosure in the application itself. The invention, starting from either D2 or D3, or from the prior art set out in the application itself, differs by the centralised location of the plug-ins, in the means of communicating with the new location, and in the details of how the software is organised.

The approach to the assessment of inventive step

As the Examining Division found, and as the appellant agreed, claim 1 defines a method with both technical and non-technical elements. As is well established, non-technical elements do not contribute to inventive step, and, to that end, may appear in the formulation of the objective technical problem (T 0641/00, Two identities/COMVIK, OJ 2003, 352). If the essential idea of the invention lies in a non-technical field (usually one excluded by Article 52(2) EPC, such as business, programs, or presentations of information), the objective technical problem often amounts to a statement of requirements that any implementation must meet.

11. The basic principle of the Comvik approach is that only technical features can contribute to inventive step; but all technical features potentially do so.

12. The assessment of what is and what is not technical is, therefore, a critical step in the formulation of the objective technical problem. A non-obvious difference over the prior art leads to a positive outcome, if it is deemed technical; but a non-obvious difference that is deemed non-technical leads to a negative outcome. This often leads to opposing definitions of the problem and must therefore be analysed precisely.

13. The formulation of the objective technical problem in terms of non-technical requirements raises the question of what requirements the business person (for example) can actually give to the technically skilled person. Naturally, any requirement that is purely a business matter can be included. The business person can formulate requirements such as, "Move the money from the payer's account to the payee's account", but in the normal course of things, the business person will not include any technical matter.

14. In the real world, there might be circumstances under which a business person might require some particular technology be used. A real business person is not unaware of technology, and might, for example say, "We should do this on the internet", or "Let's do this by wireless", or "We have a lot of XXXX processors, please use them to implement my business idea."

However, in the assessment of inventive step, the business person is just as fictional as the skilled person of Article 56 EPC. The notion of the skilled person is an artificial one; that is the price paid for an objective assessment. So it is too with the business person, who represents an abstraction or shorthand for a separation of business considerations from technical. A real business person, a real technically-skilled person, or a real inventor does not hold such considerations separately from one another.

16. Thus, the notional business person might not do things a real business person would. He would not require the use of the internet, wireless, or XXXX processors. This approach ensures that, in line with the Comvik principle, all the technical matter, including known or even notorious matter, is considered for obviousness and can contribute to inventive step.

17. Similarly, the notional business person might do things that a real business person would not, such as include requirements that go against business thinking at the time - a sort of business prejudice, as is alleged in this case (see below). If this were not the case, business requirements would need to be evaluated and would contribute to inventive step, contrary to the Comvik principle.

Application to the present case

The examining division, in essence, considered that the problem solved by the invention amounted to how to outsource the authentication of a commercial transaction to a third-party, which was an administrative or business activity. It would thus be a requirement given to the skilled person. The appellant argued that the business person would never have formulated this problem because it went against thinking at the time. In the Board's view both of these approaches are too simplistic and need to be qualified by the considerations given above. In particular, neither approach distinguishes precisely enough between technical and non-technical aspects.

19. Firstly, the Board agrees that outsourcing a purely commercial transaction could be a requirement given to the skilled person. In such a case, it would follow from the above that a prejudice against this would not help the applicant. However, the Board judges that the transaction authentication in the present case cannot be abstracted to a purely business activity because it has aspects such as the use of plug-ins and servers.

20. It also follows from the above that the business person cannot require the technically-skilled person to use, for the plug-ins, a server other than the merchant server, and which is (perhaps) accessible to other vendors. The business person might well have noticed that expense and difficulties were involved in running the merchant server; but she has no technical appreciation of why that is or that using another server might help. Those are matters for the a programmer or network engineer.

Programs for computers are, in general, not considered technical. However, the choice of where a particular computation is carried out in a distributed system will normally have implications for availability, for latency and so on, and those are technical matters. The Board is persuaded, that the decision to centralise the plug-ins in a separate server that can be accessed by several merchant servers, in order to simplify installation and maintenance and reduce load, should be considered a technical one.

22. Thus, the question is whether the technically skilled person, from the starting point set out in the application, or from D2 or D3, would relocate the plug-ins in a centralised server. Having taken that decision, a series of other decisions would be needed such as how merchant servers access the plug-ins. If the relocation was not obvious, then an inventive step must be acknowledged. If it was obvious, then the further decisions must be looked at, to the extent they are reflected in the claims.

The obviousness of relocation

23. The issues of where particular software can best be located and whether it can be shared rather than copied, are familiar to network engineers. Thus, the technically-skilled person, seeking to simplify the merchant server or the installation or updating of plug-ins, might have considered placing them in a separate server that could be accessed by various merchants' servers. That speaks against inventive step. However, as pointed out by the appellant, there are a number of other possibilities, such as centrally managing the plug-ins, combining them into a single plug-in, and introducing a proxy server as in D4. None of the prior art suggests relocating the plug-ins in a centralised server and the appellant has argued that there was a technical prejudice against doing it, all of which speak in favour of inventive step.

A number of the appellant's submissions were, in fact, business prejudices, if they were prejudices at all.

Merchants considered it was essential that they keep control over consumer transactions, and the payment operators were worried the introduction of another party would affect profits. As mentioned above, these cannot affect the assessment of inventive step. Business is business.

25. The appellant supported its argument with four sworn statements. They are all intended to show that there really was a technical prejudice.

26. Mr Gallagher was Director of ECommerce and Products and Services at First Data Corporation(1996 - 2000), Senior Vice President of Corporate Alliances at Chase Paymentech (2000 - 2007). In 2002 - 2003, he evaluated the appellant's technology on behalf of Chase Paymentech. He says that he, and Chase Paymentech generally were dismissive of the invention for business reasons, but also because it "had the potential of creating latency of delay during a transaction", "increased the opportunities for a communications or other failure interrupting the transaction", and "created opportunity for a hacker to breach or compromise system security".

Mr Grace was employed at Bank One (now JP Morgan Chase) in retail banking and Management positions (1990 - 1994), by NYCE Corporation as Director of the Advanced Products Group (1999 - 2005). Mr Grace evaluated the appellants invention in 2002. He says the NYCE customers such as Amazon, Walmart, and Cybersource were all of the view that the merchant had to keep control of interactions with the consumer. There were doubts regarding additional latency and security, but also as to the merchant losing track of the transaction while the authentication process via the MAPS was taking place.

28. Mr Heatherington has worked for the National Westminster Bank, for MasterCard International (1992 - 1999) in senior management positions, for Bank One Canada (1999 - 2000) as Chief Executive Officer, for Cyota Inc (2000 - 2001) as Chief Executive Officer, and for First Data Loan Company Canada (2001 - 2013). He evaluated the appellant's invention for Cyota Inc. and for First Data Loan Company Canada. He explains that there were several approaches to authentication of credit-card transactions over the internet. The present invention was another, which changed the flow of information and was counter-intuitive, because, in order to cope with millions of transactions each day, banks and issuers of cards were loath to relinquish control. That might decrease the speed of transactions, increase the opportunities for failure, create new opportunities for hacking, and render the system less predictable by allowing the appellant to control part of the flow. Mr Heatherington states that the approach taken by the invention were ridiculed at a conference in 2001.

29. Mr Chandra Balasubramanian is one of the inventors in the present case. He worked as a software developer (1993 - 1999). He has been the appellant's Chief Technical Officer since 1999. His submission is that the system assessed by Mr Grace was an embodiment of the claimed invention.

The Board can ascribe little value to these statements, but neither can it simply ignore them. Messrs Gallagher, Grace, and Heatherington were evidently speaking more as businessmen than as engineers; the submissions are by reference to particular working embodiments rather than to the generality of the claimed subject matter;

Nevertheless, they tend to show that there were technical considerations that spoke against relocating the plug-ins. These were the potential for an increase in latency, possible reductions in the number of transactions that can be processed in a given time period, and the increase in the number of points at which communications could be subject to hacking. The argument about the merchant losing track of a transaction during authentication does not seem pertinent, since that happens in the prior art anyway. The argument concerning the appellant controlling part of the flow assumes that the MAPS server is under the control of the appellant, but the claim says nothing about that; and who owns the server is a non-technical matter anyway. On balance, these observations establish a prima facie case for technical prejudice against relocating the plug-ins to a centralised server.

Conclusion on inventive step

31. Thus, the situation at the priority date was that plug-ins were installed on the merchant's web server. The skilled person might have been aware that their installation and maintenance involved difficulties and their relocation on a central server was possible. However, there was no hint to do so and a prima facie prejudice against doing so which is not rebutted by any of the documents on file. In the Board's judgment, in such circumstances, their re-location cannot be considered to have been obvious.

32. Claim 1 defines, in a certain amount of detail, how the merchant's server is set up to communicate with the MAPS. Prima facie, they look like perfectly normal software structures, but since the provision of the MAPS at all is already a non-obvious step, there is no need to consider whether these details add to the inventive step, and the Board refrains from doing so.

33. The above applies to claim 11 as well as to claim 1.

Further issues

34. The Board has questioned compliance with Articles 84 and 123(2) EPC, but is now persuaded that the application is compliant.

35. In particular, the Board is satisfied that the software layers in the client need not match corresponding layers in the MAPS, though it would often be convenient if they did. In the Board's view, the particular layers and connections set out in the description are optional but convenient ways of organising the software that provide the communication between the merchant's server and the MAPS and between the MAPS and the authenticating servers.

36. The Board is also satisfied that the term "thin client" is a term of art. It is a relative term, but that is harmless in the present case, because the client is "thin" in relation to the MAPS, which bears the main burden of processing.

Conclusion

37. The Board sees nothing that stands in the way of the grant of a European patent. In particular, the claimed subject matters involve an inventive step (Article 56 EPC), are clear (Article 84 EPC), and do not extend beyond the contents of the application as filed (Article 123(2) EPC).

Order

For these reasons it is decided that:

The decision under appeal is set aside.

The case is remitted to the department of first instance with the order to grant a patent on the basis of the following documents:

Claims 1 to 14 of the main request filed during the oral proceedings before the Board.

Description pages 4 and 5 filed with the grounds of appeal dated 30 May 2011.

Description pages 1 to 3 and 6 to 17 as published.

Figures 1 to 3 as published.