Visa Inc. v CardinalCommerce Corporation
[2011] APO 34
•25 May 2011
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Visa Inc. v CardinalCommerce Corporation [2011] APO 34
Patent Application: 2003243523.
Title: Universal Merchant Platform For Payment Authentication.
Patent Applicant: CardinalCommerce Corporation.
Opponent:Visa Inc.
Delegate: M. G. Kraefft
Decision Date: 25 May 2011
Hearing Date: 28 February 2011
Catchwords: PATENTS – grounds of opposition – lack of novelty, inventive step and manner of manufacture – prior use established between two compatible systems – expectation of ascertainment of document by person skilled in the art not established – prior art insufficient against claimed invention – claims found novel, inventive and for a manner of manufacture.
Representation: Applicant: Mr Chris O’Sullivan, assisted by Ms Connie Merlino, patent attorneys of F B Rice & Co, Sydney, and by Mr John Cornely, US patent attorney.
Opponent: Mr Christian Dimitriadis, of counsel, instructed by Mr Duncan Longstaff, patent attorney of Blake Dawson, Melbourne.
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2003243523.
Title: Universal Merchant Platform For Payment Authentication.
Patent Applicant: CardinalCommerce Corporation.
Decision Date: 25 May 2011
DECISION
The opposition fails on all grounds argued by the opponent.
The application may be sealed after twenty-eight (28) days from the date of this decision.
If the Commissioner of Patents is served with a notice of appeal from this decision before that time, then sealing is not to occur until the appeal has been decided or is discontinued.
REASONS FOR DECISION
CardinalCommerce Corporation (“CardinalCommerce”) filed patent application 2003243523 on 12 June 2003. The application claims priority from a US application filed on 12 June 2002. Application 2003243523 was advertised accepted on 10 April 2008.
Visa Inc (“Visa”) filed a notice of opposition on 10 July 2008. A statement of grounds and particulars in support of the opposition followed on 10 October 2008. Visa subsequently amended this statement under Regulation 5.9. The Patent Office allowed the amendment on 18 March 2009.
The stages of serving evidence-in-support, evidence-in-answer and evidence-in-reply were completed on 5 March 2010.
SPECIFICATION
The specification describes the invention as relating to the art of authentication. It has particular application with facilitating the authentication of an individual to conduct a secure commercial transaction with credit or debit card over a communications network.
Use of these cards in connection with electronic commerce (“e-commerce”) presents certain difficulties, including difficulties concerning authentication or positive identification of the cardholder. The specification states that maintaining consumer confidence in security has become difficult with increased reports of fraud. The resulting apprehension is also fuelled by consumer uncertainty of the reputation or integrity of a merchant with whom the consumer is dealing. Questionable security of the consumer’s card information or other personal information typically submitted along with a traditional e-commerce transaction serves to increase apprehension even more. Additionally, cardholders, merchants and financial institutions are all concerned about safeguarding against fraudulent or otherwise unauthorized transactions.
Some credit card networks support authentication initiatives whereby a cardholder is authenticated by the bank or financial institution issuing the card, that is, the issuing bank. In one example, at a point of checkout, a consumer selects an appropriate payment method based on the initiatives supported by the merchant. At this point, the consumer fills out an on-line checkout form including a payment option, card number and expiry date. Based on the payment information, the merchant, via a plug-in on their server, initiates various protocols with the credit card network, the merchant’s acquiring bank and the cardholder’s issuing bank. The enrolment of the card in an authentication program is verified and, if positive and subsequent authentication protocols are passed, authentication occurs. When the merchant receives the authentication, the merchant initiates the payment authorization process. The acquiring bank ultimately sends the transaction data via the appropriate credit card network to the issuing bank for settlement.
When using authentication initiatives, the credit card network often ensures participating merchants that fraudulent transactions and other charge backs, as they are known in the art, will not be the merchant’s responsibility provided the specified protocols have been followed. On the other hand, there are considerable burdens on merchants that participate in the authentication initiatives. Typical installation of the merchant plug-in can be overly burdensome on computing resources. For a merchant that participates in a plurality of authentication programs for multiple credit card networks, the burden can be higher, requiring a separate plug-in for each individual authentication initiative. This may be especially so when considering that each credit card network may have its own particular protocols, data fields and specific data formats. Furthermore, the merchants are responsible for installing updates or changing their plug-ins to reflect changes in protocols mandated by the credit card networks.
The specification states the present invention contemplates a new and improved system and/or method which overcomes the above-referenced problems.
The specification has 14 claims. Claims 1, 5 and 14 are independent claims. They read as follows:-
1.A system for supporting authentication processing of commercial transactions conducted over a communications network between a consumers (sic) and merchants, wherein the consumers are each using one of a plurality of different types of payment instruments, said used payment instrument being either enrolled 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, the system comprising:
a connection layer for connecting with the merchants to exchange communications therewith, said connection layer receiving payment information for the transactions from the merchants, said payment information for each transaction including a number identifying a particular payment instrument being used;
a plug-in layer including a plurality of plug-in components, each plug-in component administering a different one of a plurality of authentication programs in accordance with the authentication protocols prescribed to obtain an authentication determination for the transactions; and,
a distribution layer residing between the connection layer and the plug-in layer, said distribution layer determining from the payment information received for each transaction which of the different authentication program (sic) is prescribed for the type of payment instrument identified in the payment information, and routing communications between the connection layer and selected plug-in components in the plug-in layer, wherein said payment information for each transaction is routed to the plug-in component responsible for administering the authentication program for the particular payment instrument used for that transaction.
5.A method for supporting authentication processing of a commercial transaction conducted over a communications network between a first party and a second party, wherein said first party maintains a server operatively connected to the communications network for conducting the commercial transaction with the second party and accepts payment therethrough via a plurality of different payment instrument types belonging to different payment networks, said plurality of different payment instrument types having different authentication protocols prescribed therefor by their respective payment networks, conduct of said commercial transaction including the second party submitting payment information identifying a particular payment instrument being used for the commercial transaction, said payment information being obtained by the first party’s server, said method comprising:
(a) providing software installed on the first party’s server that sends payment information for the plurality of different payment instrument types accepted by the first party from the first party’s server to a universal platform server, said universal platform server being equipped to format and route messages over the communications network in different manners to accommodate the plurality of different authentication protocols prescribed by the different payment networks;
(b) determining from the payment information received at the universal platform server, for each commercial transaction, which of the different authentication protocols is prescribed by the payment network for the type of payment instrument identified in the payment information;
(c) selecting, in accordance with the determination of step (b), a particular authentication protocol from the plurality of different authentication protocols supported by the universal platform server;
(d) obtaining an authentication determination for the commercial transaction in accordance with the selected authentication protocol, including formatting messages and routing the formatted messages over the communications network in accordance with one or more mandates of the selected authentication protocol; and,
(e) returning the obtained authentication determination to the first party’s server.
14.A system for supporting authentication processing of a commercial transaction conducted over a communications network between a first party and a second party, wherein said first party maintains a server operatively connected to the communications network for conducting the commercial transaction with the second party and accepts payment therethrough via a plurality of different payment instrument types belonging to different payment networks, said plurality of different payment instrument types having different authentication protocols prescribed therefor by their respective payment networks, conduct of said commercial transaction including the second party submitting payment information identifying a particular payment instrument being used for the commercial transaction, said payment information being obtained by the first party’s server, said system comprising:
(a) software installed on the first party’s server that sends payment information for the plurality of different payment instrument types accepted by the first party from the first party’s server to a universal platform server, said universal platform server being equipped to format and route messages over the communications network in different manners to accommodate the plurality of different authentication protocols prescribed by the different payment networks;
(b) means for determining from the payment information received at the universal platform server, for each commercial transaction, which of the different authentication protocols is prescribed by the payment network for the type of payment instrument identified in the payment information;
(c) means for selecting, in accordance with the determination of step (b), a particular authentication protocol from the plurality of different authentication protocols supported by the universal platform server;
(d) means for obtaining an authentication determination for the commercial transaction in accordance with the selected authentication protocol, including formatting messages and routing the formatted messages over the communications network in accordance with one or more mandates of the selected authentication protocol; and,
(e) means for returning the obtained authentication determination to the first party’s server.
Overall the difference between the alleged invention as claimed above and the admitted prior art seems to be the setting up of a universal authentication program plug-in layer and a distribution layer, or a universal platform server, all removed from the merchant site, for all determination of relevant authentication protocols and for consequential routing.
STATEMENT OF GROUNDS AND PARTICULARS (AS AMENDED)
Visa’s grounds of opposition are that the claimed invention does not comply with subsections 18(1)(a) or (b) of the Patents Act and that the specification does not comply with subsections 40(2) or (3) of the Act. A substantial number of prior art documents and statements are listed under the first ground in respect to novelty, inventive step and manner of manufacture. Visa has provided two particulars in respect to the second ground. Visa did not press the section 40 ground at the hearing as articulated in the statement of grounds and particulars.
EVIDENCE
Visa’s evidence-in-support of the opposition consists of statutory declarations by Mr Bahram Boutorabi, Mr Andrew Weller and Mr Greg Storey. All three declarants individually had significant experience, before the priority date of the present application, in e-commerce technologies including the security and authentication of on-line transactions.
CardinalCommerce’s evidence-in-answer consists of statutory declarations by Mr Ramtin Shams, Ms Connie Merlino, Mr Souheil Badran, Mr Kevin Wayne Friedman, Mr Stephen Craig Mott and Mr Michael A Keresman. Mr Shams has attested to having been very familiar with the authentication methods promoted by Visa and MasterCard before the priority date of the present application. Ms Merlino, patent attorney for CardinalCommerce, has exhibited three patent applications listing two of Visa’s declarants as inventors. The remaining four declarants individually had significant experience before the priority date in on-line payment and authentication systems.
Visa’s evidence-in-reply consists of a statutory declaration from Mr Boutorabi.
APPLICABLE LAW
Section 18 of the Patents Act is the pertinent section in respect to the present application. Relevant parts of subsection (1) appear below.
(1)Subject to subsection (2), an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim:
(a) is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies; and
(b) when compared with the prior art base as it existed before the priority date of that claim:
(i) is novel; and
(ii) involves an inventive step; and …….CONSTRUCTION OF CLAIMS
The claims on their face appear quite clear. This seems to have support as Visa did not press section 40 matters from the statement of grounds and particulars at the hearing. However, at the hearing, Mr Dimitriadis submitted the claims of the application suffered from the difficulty of “parameteritis”. He noted this style of drafting of claims was discussed in Raychem Corp.’s Patents, [1998] RPC 31 at 37. There, Laddie J. stated:-
“This is the practice of seeking to repatent the prior art by limiting claims by reference to a series of parameters which were not mentioned in the prior art….. The attraction of this to a patentee is that it may be impossible to prove now that the prior art inevitably exhibited the parameters and therefore it is impossible for an opponent to prove anticipation.”
Mr Dimitriadis quoted further from page 37 of the above decision.
“There is another practice which can be used to obscure the patentee’s contribution, if any, to the art. This takes the form of drafting claims in an unnecessarily complicated way so that they are difficult to work through”.
Mr Dimitriadis submitted the distribution layer of claim 1 for example in the present case was merely an arbitrary concept or one that is inevitably present between a connection layer and a plug-in layer and thus is a parameter that adds nothing of substance.
The relevance of the above submissions to the present case is not readily apparent. The terminology and constructional features defined in the claims are neither complex nor obscure. In respect to the distribution layer for example, claim 1 clearly defines a systems role for that layer of determining which of the different authentication programs is prescribed and of routing communications accordingly. The layer is not merely an arbitrary or inevitable consequence adding nothing of substance. The claims to my mind clearly set out the functionality and juxtaposition of tangible, networked features of a method and system that supports authentication processing in an on-line commercial transactions environment.
I find the claims of the application are not flawed in the way asserted above.
NOVELTY
In referring to several earlier decisions in respect to novelty, the Bristol-Myers Squibb Company v FH Faulding & Co Ltd decision, (2000) 46 IPR 553 at 576, states that what the authorities contemplate is that a prior publication, if it is to destroy novelty, must give a direction or make a recommendation or suggestion which will result, if the skilled reader follows it, in the claimed invention.
At the hearing Mr Dimitriadis indicated that Visa relied on its declarants’ exhibits and declarations to establish prior use as much as prior written disclosure of the alleged invention as claimed. He noted the nature of the written and diagrammatic evidence was commercial in the sense of presenting authenticating systems to potential clients and thus did not have the same technical detail as patent specifications would have. Mr Dimitriadis submitted that, consequently, much of the documentary evidence implied or inferred the nature of the authenticating systems.
Subsection 7(1) refers to prior art information made publicly available in a document or through doing an act for novelty considerations. In respect to doing an act, two types of actions often come to mind in this area. They are prior use, as Mr Dimitriadis has indicated, or prior oral disclosure.
Prior use requires a relatively high standard of proof. The UK Appeal Tribunal discussed the standard of proof required to establish prior use in Seiller's Application [1970] RPC 103. At page 106 Graham J. stated:
"In my judgement it is necessary that proof of prior user in opposition cases should be very clear. Normally in the absence of cross-examination, this will involve corroboration of a mere statement as to recollection in a declaration, particularly where the time interval involved is considerable. Such corroboration is often best found in documents contemporary with the fact to be proved. Each case, however, must be considered on its own facts, and I say expressly that I am not attempting to lay down any rule as to what is or is not sufficient in any given case."
The UK Court of Appeal approved these comments in Dunlop Holdings Limited's Application [1979] RPC 523 at 548. A similar approach is evident in Windsurfing International Inc v Borsimex Pty Ltd, (1984) AIPC 90-135. Towards the end of section 8.38 Waddell J. states:
"It is essential that an allegation of prior public use should be strictly proved. Evidence which is uncorroborated is undoubtedly suspect and should be scrutinised with particular care. The Court must be satisfied that the proof is sufficient in the circumstances, having regard to the gravity of the allegation."
In the present case, there are some references in Visa’s evidence of prior use, mainly from Mr Boutorabi. He is the chief executive officer and founder of a corporate group of companies, of which GPayments Pty Ltd, is a business division. Mr Boutorabi indicated in his second declaration at [36] that, before the priority date, examples fitting the claims of the application existed within the Australian market. He listed some GPayments systems by example. There is little in the way of corroborating evidence to support Mr Boutorabi’s statements. In this respect, several of Mr Boutorabi’s exhibits open with slides of GPayments’ client base. Several large and well-known companies appear in those slides. On the other hand, there is firstly no corroborating evidence before me from any client. Secondly, there is nothing before me to establish the nature of any systems supplied to any particular client. In any case, I give some limited weight to Mr Boutorabi’s statements about existence within the Australian market.
GPayments systems referred to as Active Access and Active Merchant are discussed in several of Mr Boutorabi’s exhibits, BB-10, BB-11, BB-20, BB-25 and BB-28, for example. Some of these exhibits are presentations given to potential clients before the priority date of the application. The exhibits demonstrate how Active Access and Active Merchant were implemented in an on-line commercial transactions environment. Some exhibits discuss the systems separately. Exhibit BB-11, at page 4, and exhibit BB-20 discuss modes where Active Access and Active Merchant have been integrated.
No single exhibit appears to fully describe the nature of the systems and also their integration in one document. Nonetheless, I am prepared to accept the exhibits collectively and Mr Boutorabi’s statements satisfactorily demonstrate prior use of Active Access/Active Merchant as a combination in some modes.
For all other systems in the evidence, I will rely only on the written material that was provided in evidence.
Mr Dimitriadis principally cited two systems to challenge the novelty of the invention as claimed. The first system was the Active Access/Active Merchant system of GPayments. The second system was the Secure SuiteTM system of a US company, Cyota Inc.
Active Access/Active Merchant
Active Access and Active Merchant are discussed in several of Mr Boutorabi’s exhibits, as mentioned above. Mr Boutorabi stated these are presentations made to potential clients or are papers written by GPayments before the priority date of the application.
Active Access is described by Mr Boutorabi as an authentication server for card issuers (exhibit BB-28, slide 26). Exhibit BB-10 specifically indicates that Active Access is designed for internal deployment at a financial institution. The architecture comprises a communication layer communicating with three core components. These contain Visa’s 3D Secure (Three – Domain) authentication protocol, MasterCard’s SPA (Secure Payment Application) authentication protocol and Maestro’s authentication protocol. The “Three-Domain” refers to the card issuer domain (for example the card issuing bank and the cardholder), the acquirer domain (for example the acquiring bank and the merchant) and an interoperability domain between the two. Clearly Active Access caters for multiple authentication protocols. These core components in turn communicate with Active Access’ plug-in interface which connects various back-end systems via plug-ins, such as an Active Wallet/ Active Access plug-in to an Active Wallet database.
Mr O’Sullivan submitted that Active Access was a card issuer solution only. He referred to Mr Keresman’s evidence at [35] – [38]. Mr Keresman stated that the practicalities of an issuer authentication solution meant it would not have been simply adaptable to a merchant solution. Issuer systems actually authenticate transactions while merchant solutions simply support authentication. Also, an issuer solution is able to stand virtually independently of the issuing bank’s other computer servers. The merchant system on the other hand must integrate with the check-out processes which in turn impacts other merchant systems like payment processing.
Mr Dimitriadis submitted the communication layer of Active Access was the functional equivalent of the connection layer and distribution layer of claim 1 of the application. He noted the function of the communication layer of Active Access was described in exhibit BB-10 as forwarding authentication requests from client applications to the relevant core component. Exhibits BB-10 and BB-25 further describe the same function as dispatch of authentication requests to the relevant core component. I am prepared to accept the communication layer of Active Access is broadly analogous to the connection and distribution layer of claim 1 of the application.
It is noteworthy though that exhibit BB-10 and the other exhibits related to Active Access are silent on where, in the architecture, the determination is made as to the relevant core component. Claim 1 of the application defines this determination being made in the distribution layer, that is, remote from the merchant site. Similarly, claims 5 and 14 define the universal platform server for this role, also remote from the merchant site, or first party site, to use the words of those two claims. By comparison, the communication layer of Active Access merely forwards authentication requests to the relevant core. There is no clear disclosure of a determination of which is the relevant core being made in Active Access.
Active Merchant is described as a plug-in for on-line merchants (exhibit BB-28, slide 26). Exhibit BB-14 illustrates a 3D Secure payment authentication flow connecting the issuer and acquirer domains, where a merchant plug-in initiates authentication and payment processing across the domains. Exhibit BB-20 further illustrates the function of the merchant plug-in among other processes in 3D Secure. Upon a customer entering details at a merchant site, the Active Merchant plug-in checks card issuer participation with a Visa directory. That in turn checks card participation with the issuer. When a confirmation is received by the Visa directory, it sends the location of the issuer’s Active Access to the merchant plug-in for authentication purposes. The plug-in redirects the customer’s browser to the issuer’s Active Access with the transaction details. For MasterCard SPA, a customer or cardholder, shopping at a merchant site, proceeds to checkout when completed. A cardholder plug-in or electronic wallet or applet acquires payment information from the payment page at the merchant site. The applet sends a payment authorisation request to the Active Access server at the issuing bank. Active Access generates an authentication token and sends it to the applet. The applet inputs the authentication token to the merchant.
The discussion to this point has principally been about authentication processing with individual protocols, 3D Secure or SPA, assuming prior knowledge about the relevant protocol to use. There is little about how a determination of a relevant authentication protocol is made or managed out of a multiple of authentication protocols. Exhibit BB -25 includes a document outlining a merchant authentication package that an acquirer bank can provide to on-line merchants to simultaneously upgrade their web sites to support 3D Secure and SPA. Mr Boutorabi states in his second declaration at [10] that Active Merchant was developed specifically to enable on-line merchants to support multiple authentication protocols including Visa and MasterCard standards. Active Merchant could handle all authentication messaging and communications on the merchant’s behalf, checking the customer’s credit card with the relevant directory service to ensure it is enrolled before asking the cardholder’s issuing bank to authenticate the customer. Upon authentication, Active Merchant informed the merchant whether it was safe to proceed with the transaction, that is, whether authentication had been successfully completed. This loosely describes multiple authentication protocol processing from the merchant site. At best though, there may be an inference that determination of the relevant authentication protocol, from the card payment information, was performed, or at least initiated, at the merchant site. Even this differs though from the claimed invention where this function is performed remote from the merchant site.
That Active Merchant may integrate with Active Access is supported by exhibit BB-11, page 4, at least for Visa 3D Secure. This was an internal GPayments paper before the priority date of the application. While that may infer some doubt about public disclosure before the priority date, there appears to have been no inhibiting fetter for those who could have received the paper internally. Even if I am wrong on this point though, exhibit BB-11 appears to have some relevance in supporting prior use of the Active Access/Active Merchant combination, at least for 3D Secure. The exhibit supports exhibit BB-20’s presentation to potential clients on the nature of the Active Access/Active Merchant combination as described above.
In exhibit BB-11, it is stated that, to support 3D Secure, Active Access communicates with 3D Secure merchant plug-ins such as Active Merchant. For MasterCard SPA, exhibit BB-11 describes Active Access communicating with a cardholder applet, Active Checkout.
In any case, even in combination, Active Access/Active Merchant lacks a clear disclosure of the claimed feature of determination of the relevant protocol being made in a distribution layer or by a universal platform server remote from the merchant site.
I conclude the claims of the present application are novel over Active Access/Active Merchant.
Secure SuiteTM
Mr Boutorabi stated in his second declaration that Exhibit BB-22 consists of pages from the Cyota website captured on 13 February 2002 by the “WayBackMachine” at This information is consistent with the Web-Archive URL at the bottom of each page of the exhibit.
Mr O’Sullivan referred to a European Patent Office (“EPO”) Boards of Appeal decision, T1134/06, to highlight a finding that the Internet generally, including the Internet Archive WayBackMachine, was not a reliable source for determining the state of the art. The content, particularly the formatting, of a site in the Internet Archive for any particular quoted date is not necessarily an accurate or instantaneous reflection of the look of the site on the day.
While I am not bound by an EPO Board of Appeals decision, it may nonetheless be persuasive. I accept the Internet Archive may not be entirely reliable in respect to dates of availability or content on a particular date. On the other hand, the Cyota site as in exhibit BB-22 appears in order on the face of it. Moreover, the listed capture date in the Web-Archive URL for this exhibit is some four months before the priority date of the application. Even allowing for some variance in accuracy of the publication date, I think four months is likely to be a sufficient buffer to cover that.
I am prepared to accept that, on the balance of probabilities, the contents of exhibit BB-22 were publicly available before the priority date of the present application.
Exhibit BB-22 describes Secure Suite as a modular on-line payment security platform designed to support, in a single implementation, a wide range of authentication and card security products. Secure Suite is stated to include Verified by Visa (an alternative branding of 3D Secure), MasterCard SPA, amongst other protocols. The architecture comprises a core platform providing common issuer utilities such as enrolment and authentication. A unified front-end platform features a customer self-service application and multiple card support. Between the core platform and the unified front-end lies the hardware for different authentication protocols, such as Verified by Visa and MasterCard SPA, driven by a financial back-end integration system. Mr Boutorabi describes this at [31] as a layer between the unified front-end and the core platform in which individual plug-ins for different authentication standards (e.g. Verified by Visa and MasterCard SPA) sit to convey messages between the unified front-end and the core platform.
Mr O’Sullivan referred to Mr Keresman’s evidence. At [41], Mr Keresman stated that Secure Suite was only an issuer specific solution for authentication rather than a merchant solution. Furthermore, at [42], Mr Keresman stated an issuer, including one using Secure Suite, does not exchange any communications with a merchant or a merchant service provider, such as a payment gateway. Also, an issuer solution does not need to determine which authentication method to apply since any request for authentication it receives will be specific to the authentication method.
Secure Suite is clearly geared at card issuer and cardholder support. The exhibit espouses several benefits each for card issuers and cardholders. Additionally, it is stated that the core platform provides several issuer utilities. The unified front-end provides customer or cardholder applications. In between, the arrangement may well be described as an intermediate layer where individual plug-ins for different authentication protocols convey messages between the front-end and the core platform. On the other hand, there does not appear to be any architecture in exhibit BB-22 that equates with that of the claimed invention of the present application. That is, there does not appear to be any disclosure in exhibit BB-22 of a distribution layer between a connection layer and a plug-in layer as in claim 1 of the application. Similarly there does not appear to be any disclosure of a universal platform server equipped to format and route messages over a communications network according to different authentication protocols prescribed by different payment networks as in claims 5 and 14 of the application.
Furthermore there is no clear disclosure of a determination of the relevant authentication protocol, to be used for an on-line transaction, being made in a distribution layer or a universal platform server in the way claimed in the present application.
Mr Dimitriadis submitted that many of the claimed features of the present application are present in Secure Suite by implication. For example, his written submissions stated that an issuer connection layer for communicating with each merchant plug-in/server is implicitly required. Also, that merchant plug-ins can be implied as feeding into each core module.
Mr Boutorabi similarly made inferences, for example at [32] of his second declaration, about merchants’ use of Secure Suite.
It may be that Secure Suite relates to payment security solutions for on-line transactions as cardholders shop on-line. It may therefore be implicit that Secure Suite also relates to interactions with a merchant when cardholders shop on-line. On the other hand, I think it is quite a stretch to suggest the architecture for the interactions between the transacting parties is implicit in exhibit BB-22, much less that the architecture is as claimed in the present application. It is also noteworthy that Secure Suite is principally a card issuer and cardholder security solution.
I conclude the claims of the present application are novel over Secure Suite.
Payment Gateways
The description of the function of payment gateways in evidence appears to be of some relevance to the claimed invention. Some of the evidence appeared to suggest third party payment gateways had functionality for managing authentication including the determination of relevant authentication protocols to use.
Mr Storey at the outset indicated that his discussion of the state of the art was in relation to payer authentication up to the priority date of the application.
Mr Storey at [26] described payment gateways as third party systems that served as a conduit between the merchant and the acquiring bank. At the front end, payment gateways dealt with merchants. The gateways would first receive transaction requests containing payment information and finally return the processed result to confirm whether the transaction has been approved and, where relevant, authenticated. At the back end, payment gateways exchanged information with the acquiring banks, converting and routing transaction requests from merchants to the appropriate acquiring institution on the basis of identifiers in the payment information. On the merchant side, the responsibility for establishing authentication belonged to the acquiring bank although the banks would generally certify gateways. Commonly then, payment gateways enabled the merchant to conduct authenticated transactions.
Mr Storey further noted at [28] that Visa and MasterCard supported different message elements and protocols differently. He stated that consequently the bulk of Internet merchants in Australia used third parties to establish payment processing functionality. More often than not, the processing service was provided by payment gateway operators. By providing a comprehensive solution for all aspects of Internet payments (authorisation, authentication and clearing) and on-going maintenance and upgrades of the solution, payment gateway providers enabled Internet merchants to outsource the payment processing function. At [29], Mr Storey concluded it was common for payment gateways to be able to interpret transaction requests in relation to Visa and MasterCard and then work out where to send them.
Mr Boutorabi at [7] of his second declaration stated that claim 1 of the application described a system which enables a merchant to collect payment information from a customer and transmit it over a communications network to a payment gateway provider. The provider is then able to decide, from the payment information, which authentication protocol will be used. At [17] Mr Boutorabi stated, in respect to claim 5, that this claim described the collecting of payment information from a first party, notionally a merchant, transmitting that over a communications network to a second party, notionally a gateway provider, which is able from the payment information to decide which authentication protocol will be used.
Mr Boutorabi’s correlation at [17] of the defined first and second parties with a merchant and a payment gateway provider, respectively, appears to be in error. The claim itself clearly defines the first and second party relationship being one for conducting a commercial transaction between the parties over a communications network. The context of a commercial transaction would appear to refer to a trading relationship between the parties. A payment gateway provider would consequently not appear to qualify as the second party as claimed. Rather, the context suggests a merchant-customer, vendor-buyer, supplier-user relationship and the like. In any case, in respect to the provision of payment gateways for authentication though, Mr Boutorabi appears at both [7] and [17] to infer this was known before the priority date of the application.
Mr O’Sullivan, with reference to Mr Storey’s evidence, submitted that payment gateways operated between merchants and their acquiring banks and did not communicate with card issuers or have authentication before the priority date as understood in the field.
Mr Boutorabi noted though in his evidence in reply at [82], in response to assertions of Verified by Visa’s authentication method that a merchant or payment gateway did not communicate with the issuer, that such interpretation unnecessarily broke the process down into discrete parts without regard to the overall effect of the process. He stated it was clear that merchants communicated with issuers, albeit through a browser. The issuer provided an authentication determination to merchants again through a browser. The fact that information is passed through an intermediary does not change the fact that the merchant, or the payment gateway, and the issuer are communicating with each other to authenticate the cardholder.
While Mr Boutorabi has put the position somewhat loosely perhaps, it is clear from the evidence that communication between merchants, payment gateways and card issuers was a common part of on-line payment processing. For example, both Visa’s 3D Secure and Mastercard’s SPA architectures illustrate data traffic through the merchant, payment gateway, acquiring bank and issuing bank, principally for payment transactions. While at least for SPA there is also routing of authentication tokens through the payment gateway, both of these architectures involved authentication being conducted elsewhere. In any case, this discussion is about authentication processing with individual protocols. Mr Storey and Mr Boutorabi may well assert that payment gateways determined which of multiple authentication protocols to use. On the other hand, there appears to be limited, if any, corroborating evidence before me of that before the priority date.
Mr O’Sullivan further cited Mr Badran’s evidence, at [11] and [12], noting that Mr Badran was not encouraged before the priority date to adopt the Verified by Visa or SPA authentication programs as part of his company’s service offering. Mr Badran cited the reasons of investment and resource commitments to support the authentication programs without knowing what the value would be.
It was later, namely in August 2002, that Mr Badran sought authentication technology that would compliment his company’s payment gateway [15]. Mr Badran further stated, at [10], that he was responsible for the introduction of authentication services into the company’s on-line payment gateway in December 2002. Both of these dates, significantly, were shortly after the priority date of the present application.
Mr Friedman at [35b] suggested an alternative to merchant plug-ins was that third parties could host the merchant’s payment side for authorising and authenticating on behalf of the merchant. He specifically mentioned payment gateways but also stated no payment gateway he was aware of had implemented authentication before the priority date of the application.
Mr Keresman at [11] and [12] referred to a GPayments paper (exhibit MK-4). He noted it was publicly available on the Internet around March 2002, that is, a few months before the priority date. Mr Mott evidenced the publication date as 1 March 2002. Mr Keresman stated the paper described a URL model, an “on-behalf-of-hosting” model, of authentication by a payment gateway on behalf of the merchant. The paper describes the URL model as one where the merchant uses hyperlinks to redirect customers to the payment gateway, hosted by the acquirer, or a third party, for entry of the customer’s credit card details. Mr Keresman noted though, at [13] onwards, that this model did not interact with other system features as claimed in the present application. For example, there is no disclosure of receipt of payment instrument identifying information through a connection layer, and there is no disclosure of a plug-in layer or distribution layer. Mr Keresman also noted, at [19] and [20], that there is no disclosure that the payment gateway, using the URL model, determines the protocol prescribed and selects that protocol, nor that the payment gateway returns an authentication determination to the merchant, especially for different authentication protocols. I concur.
I find the evidence is insufficient about determination of relevant authentication protocols being handled by payment gateways or other third parties remote from the merchant site before the priority date of the present application.
I conclude the claims of the present application are novel.
INVENTIVE STEP
Under subsection 7(2) of the Patents Act, an invention is taken to have an inventive step unless it would have been obvious to a person skilled in the art in light of the common general knowledge in the patent area before the priority date of the claims. Under subsections 7(2) and 7(3) the common general knowledge may be considered either on its own, or together with prior art information which the skilled person could, before the priority date of the claim, be reasonably expected to have ascertained, understood and regarded as relevant.
Wellcome Foundation Ltd v VR Laboratories (Aust.) Pty Ltd, (1981) 148 CLR 262 at 280, states the question is whether the invention would have been obvious to a hypothetical skilled addressee armed with the common general knowledge at the priority date. Also from that decision at page 286, an appropriate test is whether a person skilled in the relevant field, and faced with the same problem, would have taken as a matter of routine whatever steps might have led from the prior art to the invention.
The High Court in Aktiebolaget Hassle v Alphapharm Pty Limited, (2002) 56 IPR 129 at [50]-[53], appears to approve of the Wellcome (supra) test. In discussing what was meant by a matter of routine the High Court noted and accepted an affinity with the approach in Olin Mathieson Chemical Corporation v Biorex Laboratories Ltd, (1970) 87 RPC 157, of whether the person skilled in the art would directly be led as a matter of course to try what was claimed in the expectation that it might well produce a useful alternative. In Lockwood Security Products Pty Ltd v Doric Products Pty Ltd [No. 2] (2007) 235 ALR 202, general principles regarded to be of continuing relevance, at [50]-[52], were that “obvious” means “very plain”, a scintilla of invention remains sufficient to support the validity of a patent, there must be some difficulty overcome, some barrier to be crossed, and an invention must be beyond the skill of the calling.
In the present case, the specification describes the invention as relating to the art of authentication. More particularly, the specification mentions facilitating the authentication of an individual to conduct a secure commercial transaction with credit or debit card over a communications network, for example the Internet.
The specification expresses the problem of the prior art as placing considerable burdens on merchants that participate in authentication initiatives. Merchant plug-ins can be overly burdensome, particularly for merchants that participate in a plurality of authentication programs for multiple credit card networks.
Person Skilled in the Art
Mr Storey conveniently described at [32] the persons in the industry, for which Internet payment authentication protocols needed to cater, as those involved in electronic funds transfers, credit card infrastructures and other non-cash payment systems, principally in a technical capacity. He particularly indicated the industry encompassed:-
(a)any merchant who was an early adopter of selling things via the Internet;
(b)people consulting to these merchants, for example, payment gateway operators;
(c)telecommunications providers and ISPs;
(d)technology companies; and
(e)some consulting firms.
I think groups (d) and (e) are somewhat vague, generic groups and seemingly diverge beyond the present field. On the other hand, in keeping with the above identification of those involved in electronic funds transfers and credit card infrastructures, I would add card scheme administrators, such as Visa and MasterCard, and card scheme members, such as banks and other financial institutions, to the list. No significant alternatives were offered by other declarants. Consequently I accept Mr Storey’s groups (a), (b) and (c), and the card scheme administrators and members as appropriate persons skilled in the present art.
I am satisfied all the expert declarants in this opposition were appropriate persons skilled in the art.
Common General Knowledge
Mr Dimitriadis submitted, at [76] of his written submissions, that the specification indicated an acceptance that the following was common general knowledge before the priority date of the application:-
(a)the use of payment instruments such as credit and debit cards for Internet or e-commerce transactions;
(b)the concerns arising in relation to authentication, including in relation to security, privacy and commercial viability;
(c)different on-line authentication protocols including Visa’s 3D Secure and MasterCard’s SPA;
(d)the above-mentioned problems of the prior art, including the burden imposed by the size of plug-ins used by merchants, and the need for separate plug-ins for different authentication initiatives; and
(e)the periodic changing of authentication protocols by credit card networks such that plug-ins need to be changed.
Mr Dimitriadis also submitted at [77] that the evidence of Mr Boutorabi, Mr Weller and Mr Storey supported this was common general knowledge. As the specification discusses the above as clearly known background material and since CardinalCommerce has not challenged those assertions, I am prepared to accept the above matters were common general knowledge before the priority date.
Mr Dimitriadis further submitted at [77] - [83] that the content of various documents in evidence was common general knowledge before the priority date. He specifically referred to the GPayments papers and presentations and Cyota’s Secure Suite.
The British Acoustic Films Ltd v Nettlefold Productions decision, (1936) 53 RPC 221 at page 250, considered whether material disclosed in publications would constitute common general knowledge in the art. This decision held that:
“a piece of particular knowledge as disclosed in a scientific paper does not become common general knowledge merely because it is widely read, and still less merely because it is widely circulated. Such a piece of knowledge only becomes common general knowledge when it is generally known and accepted without question by those who are engaged in the particular art.”
The General Tire & Rubber Company v Firestone Tyre & Rubber Company Ltd decision, (1972) 89 RPC 457 at page 483, regarded the words “accepted without question” as putting the position rather high. This decision held the words, “generally regarded as a good basis for further action”, would be more appropriate.
In the present case, while there may have been some level of distribution of the GPayments papers and a level of attendance by other parties at the GPayments presentations, the establishing of those disclosures as common general knowledge before the priority date of the application would appear, from the above decisions, to require more than that. Firstly, this material was not of a type like scientific papers. Secondly, there is little corroborating evidence on the degree of dissemination, knowledge, regard or acceptance of the GPayments material in the industry. For Secure Suite, there is little provided in the evidence beyond the Web-Archive URL establishing public availability before the priority date. In both cases, it seems it could not be fairly said that the material was so generally known and regarded in the industry as to constitute common general knowledge. Furthermore, for both prior art sources, it is noteworthy that the disclosures thereof only became publicly available less than 12 months before the priority date. Whilst it may be stated that this industry was progressing rapidly in a technological sense or that rapid dissemination of information occurred, the first availability of the disclosures so close to the priority date would appear a detriment to that material being common general knowledge at the time.
I conclude the evidence before me is insufficient to establish the GPayments papers and presentations and Cyota’s Secure Suite were matters of common general knowledge before the priority date of the application.
In summary, referring again to subsections 7(2) and 7(3) of the Patents Act, the claimed invention needs to be assessed for inventive step in the light of the common general knowledge alone, as expressed above at points (a) to (e), or together with appropriate prior art.
Whether there is an Inventive Step
The common general knowledge, expressed at (a) to (e) above, principally relates to long commonly known use of credit and debit cards for on-line transactions, concerns with authentication of cardholders, and issues with multiple authentication protocols and updates thereof. There is nothing in the common general knowledge alone about methods or systems for enabling authentication processing with capacity to efficiently handle multiple protocols and regular updates of protocols. Still further, there is nothing in the common general knowledge alone that comes close to the particular authentication processing arrangements of the claims of the present application.
I conclude that, on the available evidence, the claimed invention has an inventive step over the common general knowledge alone as it stood before the priority date of the application.
In respect to available prior art in evidence, the Active Access/Active Merchant system appears most pertinent. Under subsection 7(3), it firstly needs to be established that a skilled person in the field could, before the priority date, be reasonably expected to have ascertained, understood and regarded this prior art as relevant.
As mentioned earlier, Mr Boutorabi indicated that Active Access/Active Merchant was made publicly available before the priority date through prior existence in the Australian market and through presentations by GPayments to potential clients. Mr Dimitriadis submitted at [128] that, on this basis, the skilled person could, before the priority date of the claims, be reasonably expected to have ascertained, understood and regarded as relevant the Active Access/Active Merchant information. Mr Dimitriadis also stated that in the context of the present technical field of electronic commerce and its primary concern with the Internet, skilled persons in this field could be expected to immediately and routinely consult the Internet to search for relevant material.
The degree of dissemination in respect to Active Access/Active Merchant does not appear to be as much as made out by Mr Dimitriadis. There appears to be no evidence from declarants besides Mr Boutorabi readily to hand about prior knowledge or prior use of Active Access/Active Merchant. This could infer prior knowledge and use in the field was limited. Mr Boutorabi has stated throughout that the presentations were made to potential or existing clients. While that may indicate dissemination among certain groups in the industry, the level and diversity of audience attendance have not been provided in evidence. In fact, with several exhibits related to the Active Access/Active Merchant material, Mr Boutorabi initially pointed out the commercial sensitivity if that information were made publicly available.
Mr Dimitriadis’ point about the industry’s primary concern with the Internet, and consequential expectation for skilled persons in the field to consult the Internet to search for relevant material, appears to be a little lost in respect to Active Access/Active Merchant. While GPayments clearly had a web presence at least in respect to Active Merchant before the priority date (see for example Mr Keresman’s declaration at [30] and [31]), there appears to be no evidence readily to hand of the Active Access/Active Merchant presentations or papers being disseminated via the Internet before the priority date.
I conclude Visa has not clearly established that a skilled person in the field could, before the priority date of the claims, be reasonably expected to have ascertained the Active Access/Active Merchant information, nor as a consequence then have understood and regarded it as relevant.
Even if I am wrong in the above assessment, it appears Visa’s assertion of obviousness of the claimed invention is somewhat difficult. On the one hand, Mr Boutorabi, for example, stated at [49] of his first declaration that the concept of creating a single solution, which combined all existing authentication protocols, was a natural corollary of more than one protocol existing. He further asserted there was no technical difficulty in establishing the relevant authentication protocols to use and routing authentication requests accordingly. This was achieved through specific identifiers within a card number. Mr Weller similarly asserted at [39] of his first declaration that the integration of several protocol plug-ins into a single solution for merchants was not technically difficult and did not involve any new technological developments or know-how. On the other hand, Mr Boutorabi’s and Mr Weller’s discussion is primarily directed at single solutions in merchant systems for multiple authentication protocols. The evidence is absent of indications that persons in the industry had directed any significant attention to the stated problem of the burdens on merchants of managing authentication with merchant plug-ins before the priority date of the application.
It may seem obvious that, to relieve such burdens on merchants, a solution could have been to have an expert third party manage the whole authentication process remote from the merchant site, including the determination of the relevant authentication protocols to use as claimed in the application. However this would involve engaging in the ex post facto analysis often warned against. See for example Minnesota Mining and Manufacturing Co v Beiersdorf (Australia) Ltd, (1980) 144 CLR 253. The evidence before me suggests that very little seems to have actually been done about the problem before the priority date of the application. Work on simplifying authentication, specifically providing single solutions for multiple protocols, appeared, in the main, to be directed to merchant systems.
I accept that Active Access/Active Merchant is closely related art to that of the claimed invention. As noted earlier though, the evidence of Active Access/Active Merchant does not clearly indicate determination of relevant authentication protocols being made in a distribution layer or by a universal platform server remote from the merchant site as claimed in the present application. Any suggestion in this case of that having been an obvious step to make in an industry where activity, before the priority date, for initial handling of multiple authentication protocols, appeared to be directed mostly at the merchant site would appear difficult to sustain.
I conclude the claims of the present application have an inventive step.
MANNER OF MANUFACTURE
Mr Dimitriadis indicated in his written and oral submissions that the manner of manufacture issue was largely analogous to the inventive step issue in this case. As Visa has failed on the inventive step ground, it seems the manner of manufacture ground would also fail. Mr Dimitriadis’ written submissions went further to challenge for lack of manner of manufacture on the basis that at least the method claims 5 - 13 merely defined a scheme which makes use of known components for which their known properties make them suitable.
The method claims clearly relate to supporting authentication processing of on-line commercial transactions involving several physical steps in a networked environment. The claims are not directed merely to a scheme.
I conclude the claims of the present application are for a manner of manufacture.
CONCLUSION
I have found the opposition fails on all grounds argued by the opponent. Claims 1-14 of the application are novel, inventive and for a manner of manufacture on the available evidence presented in the opposition.
COSTS
100. Both parties principally submitted that costs should follow the event. I see no reason to vary this practice. Visa has been unsuccessful in this opposition. I award costs in accordance with Schedule 8 against Visa.
M. G. Kraefft
Delegate of the Commissioner of Patents
1
5
0