T 1658/15 (Universal merchant platform II / 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 10183825.3, which was a divisional application on the basis of 03760289.3.

II. The Examining Division found that the invention lacked inventive step as a straightforward implementation of an administrative scheme.

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

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 first auxiliary requests, document D11 (US2003/0042301), and four sworn statements. The appellant also requested oral proceedings.

V. The appellant subsequently requested accelerated processing, and filed a fifth sworn statement in support of this request.

VI. The Board arranged to hold oral proceedings. In a communication sent with the summons, the Board set out its provisional view of the case. The Board expressed doubts as to compliance with Articles 76, 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 business measures and programming measures.

VII. In response, the appellant submitted further arguments regarding the two requests submitted with the statement setting out the grounds of appeal, and filed a new, second auxiliary request.

VIII. During oral proceedings before the Board, the appellant submitted an amended claim 1 and an amended description for the main request.

IX. 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 sole claim and the amended description according to the main request as filed during the oral proceedings before the Board, and figures 1 - 3 as originally filed.

X. The sole claim according to the main request reads as follows.

A system 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 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, the system comprising:

the server (100) including one of a plurality of available integration approaches, the available integration approaches including a thin-client (106), a direct connection and an easy connection,

wherein the thin client (106) is operable to format name/value pairs in XML according to a required MAPS message format and securely communicate the message to the MAPS (200) via HTTPS, wherein the thin client (106) is a COM object or a Java component,

wherein the direct connection is a connection in which the merchant can use direct Java calls to interface with the MAPS (200) and communicate XML messages, and

wherein the easy connection is a connection in which the merchant can redirect the consumer (50) using HTTPS posts via the consumer's browser to an easy connect web server of the MAPS (200) and can receive responses at a specific response URL, wherein the web server acts on behalf of the merchant and communicates with the MAPS (200) to provide appropriate processing for an appropriate authentication initiative,

the server (100) being operable to obtain payment information for the transaction from the consumer (50) and forward the payment information to the MAPS (200) using the included integration approach; and

the MAPS (200) including an HTTPS server (212), a direct connector (214) providing a Java interface, an easy connector (216) providing the easy connect web server, and a message distribution layer (220) configured to route XML messages to specific plug-in components in a plug-in layer (230), wherein the plug-in layer (230) includes a plurality of individual authentication initiative plug-in components, the MAPS (200) being operable to:

obtain the payment information for the transaction from the server (100), said payment information including a number identifying the particular payment instrument being used;

determine the type of payment instrument being used from the payment information, wherein a specific 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, wherein the specific plug-in component (232) formats and routes messages in accordance with authentication protocols prescribed for the particular payment instrument being used;

obtain 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 to

return the obtained authentication determination to the server (100).

XI. 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. The skilled person would understand that "integration approach" referred to a manner of unifying components, particularly in the context of the three approaches set out in the claim.

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

Reasons for the Decision

Procedural matters

1. The appeal concerns a divisional application of European patent application 03760289, which underlies the case T 1463/11, also before the Board. In view of the similarities of the cases, the Board decided to treat the present case at the same time as the older. It was, therefore, unnecessary to consider the appellant's request for accelerated processing.

Background

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

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

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

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

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

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

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

9. The appellant, on appeal, has filed document D11. D11 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 D11 is a secondary indicium; but it cannot be a starting point for an assessment of inventive step.

10. 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 at least 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.

11. Claim 1 comprises a number of additional features, which also go beyond the features defined in claim 1 of the parent application. However, as will be seen, the Board finds that the invention would be inventive on the basis of the differences set out above. It is, therefore, unnecessary to consider whether the other features might make some further contribution.

The approach to the assessment of inventive step

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Further issues

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

34. In particular, the Board is satisfied that the terms "integration approach", "thin client", "direct connection", and "easy connection" are terms of art. Moreover, in his letter of 28 October 2016, the appellant provided a basis for the amendments which the Board considers to be sufficient.

Conclusion

35. 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 extend beyond the contents of neither the application as filed (Article 123(2) EPC), nor the parent application (Article 76 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:

Claim 1 of the main request filed during the oral proceedings before the Board.

Description pages 1 to 17 filed during the oral proceedings before the Board.

Figures 1 to 3 as originally filed.