Mastercard International Incorporated
[2023] APO 42
•2 August 2023
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Mastercard International Incorporated [2023] APO 42
Patent Application: 2020239627
Title:ACH transaction authentication systems and methods
Patent Applicant: Mastercard International Incorporated
Delegate:B. Norman
Decision Date: 2 August 2023
Hearing Date: Written submissions filed on 2 March 2023
Catchwords: PATENTS - examiner objection – whether claims are for a manner of manufacture – substance of the invention is a scheme – claims are not for a manner of manufacture – no patentable subject matter identified in the specification – application refused
Representation: Patent attorney for the applicant: Spruson & Ferguson
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2020239627
Title:ACH transaction authentication systems and methods
Patent Applicant: Mastercard International Incorporated
Date of Decision: 2 August 2023
DECISION
The claims of the application, as proposed to be amended, do not define a manner of manufacture.
I do not see any subject matter in the body of the specification from which valid claims could be drafted to overcome this finding.
I refuse the application.
REASONS FOR DECISION
Background
Patent application 2020239627 (the application) was filed on 21 September 2020 by Mastercard International Incorporated (the applicant) as a divisional application of 2018247245 (the parent). The parent claims priority from US Application 15/806,113 which was filed on 7 November 2017. Hence, the earliest claimed priority date of the application is 7 November 2017.
A request for examination of the application was filed on 2 December 2020, along with a request for the postponement of acceptance.
The first examination report was issued on 26 November 2021 raising objections regarding both manner of manufacture and inventive step, the applicant responding with submissions and proposed amendments to the claims on 20 July 2022. After a second examination report maintaining the objection regarding manner of manufacture was issued on 18 August 2022, the applicant requested to be heard on 3 November 2022.
The applicant was invited to provide written submissions on 2 February 2023, and the applicant subsequently provided them on 2 March 2023.
For the benefit of the applicant, this decision is written with respect to the specification as proposed to be amended, without conclusively considering the allowability of the amendment as this will not affect the outcome of the decision.
Applicable Law
Because the application was filed after 15 April 2013 examination is governed by the Patents Act 1990 (the Act) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012. Accordingly, the standard of proof that applies is the balance of probabilities. This means that if I am satisfied, on the balance of probabilities, that a ground of objection exists, I can refuse the application. However, I will only refuse the application if I am also satisfied that providing the applicant with an opportunity to amend will serve no useful purpose; for example, if I consider that any potential negative findings are not rectifiable by an allowable amendment.
The Invention as Described
The application is directed to payment transactions made over an automated clearing house (ACH) network and specifically the authentication of them. These payments transactions are different to credit and debit transactions, as ACH transactions are a direct transfer of the funds from the payor account to the payee account. Thus, there are no intermediatory parties or escrow in the transaction.
Within an ACH network, there are several roles as explained in the description[1]. Firstly, there is the payee who is receiving the funds, who can be a merchant (e.g., a supplier or seller). There is also an associated acquirer who is responsible for the payee’s account; in the aforementioned example of a payee this would be the merchant’s bank. There is also a user (or a customer) who can be the payor sending the funds. The payor will also hold an account with the issuer, who can be the bank or financial institution whom the payor has an account with. It is implied from the specification that both the acquirer and issuer have access to the ACH network.
[1] Paragraph [0022] of the Description
The specification explains that, in an ACH network, there is no authentication process tying the user to the account number being used and no guarantee of funds availability in the account for such systems. A typical ACH network is illustrated in Figure 1:
Figure 1 depicts what is a standard, non-authenticating ACH network transaction system. The figure shows both the payor account 105, and the payee account receiving the funds 103. The issuer 104 would be the payor’s bank. Thus, when a payee requests (or a payor instructs) payment, provided the account number is correct, then this transaction would be processed in the ACH network by the banks without any interference.
A first embodiment of the invention in Figure 2 shows an authenticating system for an ACH network transaction system.
In the above embodiment, the system includes an authentication computing device 208 which is connected to a database 210 containing information such as: account data, registered payee/merchant listings, registration modules, challenge modules, authentication modules, etc. This is also inclusive of account data that only a legitimate user (such as the payor(s) associated with a payor account 205)) would be familiar with including passwords, security questions and answers, security images, etc[2]. The authentication computing device 208 is also in communication with computing devices associated with the acquirer 202 and issuer 204, as well as client computing devices 212. Furthermore, it is a requirement that the payee be registered with the authentication computing device.
[2] Paragraph [0030] of the Specification
In this embodiment, the system authenticates the transaction by the authentication computing device sending a challenge to the client computing device 212 that made a request for a transfer of funds from a payor account to a payee account; the request including an account identifier associated with the payor account. This challenge can be, for example, the client computing device asking the user for the password to the payor’s account[3]. It can also be other authentication challenge services such as a 3-D Secure® protocol (3DS)[4]. When an authentication challenge response is received from the client computing device 212, the authentication computing device 208 determines whether the request has been authenticated and transmits the response back to the client computing device.
[3] Paragraph [0040] or [0046] of the Specification
[4] Paragraph [0032] of the Specification
The specification also describes that the system can include risk based decisioning (RBD) as part of the authentication device 208 to evaluate the likelihood that a transaction is fraudulent, and thus approve the transaction without requiring authentication if deemed a low risk[5]. This RBD component can assess information about the client device 212, or even account information from the database 210[6]. It may also communicate with the access control system (ACS) of the issuer 204 to make this decision [7].
[5] Paragraphs [0031] of the Specification.
[6] Paragraphs [0033] of the Specification.
[7] Paragraphs [0033] of the Specification.
The specification also describes the operation of the embodiments with reference to figures 3A and 3B.Figure 3A illustrates the flow of data in the system with a single client computing device which makes both the authentication request (with the payor account number) and handles the authentication challenge. It is implied that the user of this device is the payor, although the device
is associated with the payee. Figure 3B illustrates the flow of data in the system with a second client computing device. As per the previous embodiment, the first client computing device 312a makes the authentication request (with the payor account number) and awaits the authentication response. The specification describes this device as being associated with the payee, including POS devices. In this embodiment, the authentication challenge is sent to a second client computing device 312b. The application describes that this device is associated with a ‘user’. Although not described as such, nor required, the user will be the payor themself or representative of the payor (e.g. where the payor is a business). The authentication computing device thus receives an authentication request from the first client computing device, challenges the second client computing device, and based on the challenge response it gets back, then makes an appropriate authentication response back to the first device.In some embodiments the challenge response is input via the second client computing device, but in other embodiments the challenge response can also be input via the first client computing device [8]. It is this embodiment that the claimed invention is now directed to.
[8] Paragraph [0048] of the Specification.
The specification gives examples of client computing devices as being any device capable of interconnecting to the Internet including mobile computing devices such as a laptop or desktop computer, smartphones, tablets, wearable fitness devices, smart refrigerators, or a “smart watch”[9]. An example configuration for a remote or client computing device is depicted in Figure 4:
[9] Paragraph [0034] of the Specification.
The described hardware for the client computing devices would appear to be generic and not specific or unique. No examples of the processor Item 404 architecture or memory Item 406 type are given. The media outputs 408 are described as being generic display devices like a liquid crystal display or audio devices like a speaker[10]. Similarly, the examples listed of the input 412 are generic human interface devices such as a mouse or stylus, as well as other typical sensors used in computing devices such as cameras or touchscreens[11]. The examples of the communication interface Item 414 are also typical interfaces like mobile phone networks or network adapters.
[10] Paragraph [0052] of the Specification.
[11] Paragraph [0053] of the Specification.
Figure 5 is an example of a server used for the described ACH transaction system.
The diagram depicts that the server used has a processor, memory, a storage device and interface, and a communication interface.
The described hardware for the server computing devices would appear to be generic and neither specific nor unique. No examples of processor architecture or communication interface are given. The storage devices would appear to be standard devices with otherwise ordinary interfaces[12]. Similarly, the example of memory for the server appears to be standard types available for use[13] for computing device.
[12] Paragraphs [0058] & [0059] of the Specification.
[13] Paragraph [0060] of the Specification.
The authentication method for transactions is depicted in Figure 6 as step-by-step process:
Finally, I note that the specification describes that the claimed invention addresses at least one of the following, which are described as ‘technical problems’[14]:
“(i) lack of authentication for ACH transactions;
(ii) higher risk associated for a user/payor in providing actual checking or savings account numbers when making ACH payment;
(iii) lack of ACH transaction utilization for retail (e.g., items/goods-based) merchants;
(iv) higher risk associated for a merchant utilizing ACH transactions for payment when no indication of sufficient funds in payor account is available;
(v) longer transaction processing time for merchants and consumers utilizing non-ACH payment methods; and(vi) higher transaction processing costs for merchants utilizing non-ACH payment methods.”[14] Paragraph [0021] of the Description.
The specification further describes[15] that the ‘technical’ effect of the systems and method described can be achieved by performing at least one of the following:
“(i) registering a payee with the authentication computing device;
(ii) receiving an authentication request for an electronic ACH transaction to transfer funds from a payor account to a payee account, the request received from a first client computing device, the request including an account identifier associated with the payor account;
(iii) transmitting an authentication challenge to a second client computing device based on account data associated with the account identifier, the account data being received from an issuer and stored in the memory;
(iv) receiving a challenge response to the authentication challenge;
(v) determining whether the account data has been authenticated based on the received challenge response; and(vi) transmitting an authentication response to the payee based on the determination.”[15] Paragraph [0022] of the Description.
With respect to what the specification[16] describes as the ‘technical’ effects achieved by the systems and the methods, I note they largely corresponded to the ‘technical’ problems referred above.:
“(i) improved authentication for ACH transactions;
(ii) lower risk for users/payors associated with providing actual account numbers when making ACH payments;
(iii) increased ACH transaction availability and desirability for retail (e.g., goods-based merchants);
(iv) lower risk for merchants utilizing ACH transactions by providing a funds amount indicator associated with the payor account;
(v) faster transaction processing time for merchants and consumers by utilizing ACH payment methods; and
(vi) lower transaction processing costs for merchants by utilizing ACH payment methods.”[16] Paragraph [0023] of the Description.
The Invention as Claimed
A proposed amendment was made to the specification during examination to overcome the objections. The specification as now proposed ends with fifteen claims, of which claims 1, 7 and 13 are independent claims.
Claim 1 defines:
An authentication computing device for authenticating an ACH transaction processed over an ACH network, the authentication computing device including a processor in communication with a memory, said processor programmed to:
register a payee with the authentication computing device;
receive an ACH authentication request for an electronic ACH transaction to transfer funds from a payor account to a payee account, the request received from a first application associated with the payee and executing on a first client computing device, the request including an account identifier associated with the payor account;
retrieve, by the authentication computing device, in response to receiving the ACH authentication request, account data from an issuer of the payor account by performing a lookup using the account identifier at a database associated with the issuer, wherein the account data is stored in the memory and is not accessible to the payee;
cause to be displayed, in response to receiving the ACH authentication request, via a second application associated with the authentication computing device and executing on a second client computing device, an ACH authentication challenge prompting the payor to respond to the ACH authentication challenge via the second application,
wherein the second computing device is different from the first computing device and is associated, based on the retrieved account data, with a user of the payor account, wherein the ACH authentication challenge requests account data from the payor that is known to a legitimate payor associated with the payor account and is not known to the payee, and wherein the ACH authentication challenge is not accessible to the payee;
receive, via Internet communication from the first application executing on the first client computing device, an ACH challenge response to the ACH authentication challenge, wherein the ACH challenge response is not accessible to the payee;
determine, by the authentication computing device, whether the ACH transaction is authenticated including determining that the payor is the legitimate payor associated with the payor account by comparing the received ACH challenge response with the account data retrieved from the issuer; and
transmit, from the authentication computing device via Internet communication to the first application associated with the payee, an ACH authentication response based on the determination.When I construe claim 1, I consider it defines an authentication computing device (e.g., server) that communicates with a first client computing device (e.g. POS device or similar), and a second client computing device (e.g. user’s personal device). Key features defined are that the second client computing device is different to the first client computing device and is associated with a user of the payor account. Also, key to the claimed invention is that the authentication response comes from a device different to what the authentication challenge is sent to.
It is implicit from this claim that the first client computing device can be associated with either the payor or payee, although not actually defined. However, the application on this device is defined as being associated only with the payee. The authentication request is made by the first client computing device, and the challenge is issued to an application running on the second client computing device. The authentication challenge response must be sent from the first client device and via internet communication. There is no requirement that the authentication device transfer the funds. It merely determines whether the request is authenticated or not.
Claim 7 defines (paragraph breaks added to ease reading):
A method for authenticating an ACH transaction processed over an ACH network, said method performed using an authentication computing device including a processor in communication with a memory, said method comprising:
registering a payee with the authentication computing device;
receiving an ACH authentication request for an electronic ACH transaction to transfer funds from a payor account to a payee account, the request received from a first application associated with the payee and executing on a first client computing device, the request including an account identifier associated with the payor account;
retrieving, in response to receiving the ACH authentication request, account data from an issuer of the payor account by performing a lookup using the account identifier at a database associated with the issuer, wherein the account data is stored in the memory and is not accessible to the payee;
causing to be displayed, in response to receiving the ACH authentication request, via a second application associated with the authentication computing device and executing on a second client computing device, an ACH authentication challenge prompting the payor to respond to the ACH authentication challenge via the second application,
wherein the second computing device is different from the first computing device and is associated, based on the retrieved account data, with a user of the payor account, wherein the ACH authentication challenge requests account data from the payor that is known to a legitimate payor associated with the payor account and is not known to the payee, and wherein the ACH authentication challenge is not accessible to the payee;
receiving, via Internet communication from the first application executing on the first client computing device, an ACH challenge response to the authentication challenge, wherein the ACH challenge response is not accessible to the payee;
determining whether the ACH transaction is authenticated including determining that the payor is the legitimate payor associated with the payor account by comparing the received ACH challenge response with the account data retrieved from the issuer; and
transmitting, via Internet communication to the first application associated with the payee, an ACH authentication response based on the determination.
When I construe claim 7, I consider it defines a method of authenticating an ACH transaction in a similar vein to the computing device of claim 1. The steps of the method defined in Claim 7 are essentially the same as the steps performed by the processor of the "authentication computing device including a processor in communication with a memory" defined in claim 1.
Claim 13 defines:
A non-transitory computer-readable storage medium having computer executable instructions embodied thereon, wherein when executed by an authentication computing device including at least one processor coupled to a memory, the computer executable instructions cause the authentication computing device to: register a payee with the authentication computing device;
receive an ACH authentication request for an electronic ACH transaction to transfer funds from a payor account to a payee account, the request received from a first application associated with the payee and executing on a first client computing device, the request including an account identifier associated with the payor account;
retrieve, by the authentication computing device, in response to receiving the ACH authentication request, account data from an issuer of the payor account by performing a lookup using the account identifier at a database associated with the issuer, wherein the account data is stored in the memory and is not accessible to the payee;
cause to be displayed, in response to receiving the ACH authentication request, via a second application associated with the authentication computing device and executed on a second client computing device, an ACH authentication challenge prompting the payor to respond to the ACH authentication challenge via the second application, wherein the second computing device is different from the first computing device and is associated, based on the retrieved account data, with a user of the payor account, wherein the ACH authentication challenge requests account data from the payor that is known to a legitimate payor associated with the payor account and is not known to the payee, and wherein the ACH authentication challenge is not accessible to the payee;
receive, via Internet communication from the first application executing on the first client computing device, an ACH challenge response to the authentication challenge, wherein the ACH challenge response is not accessible to the payee;
determine whether the ACH transaction is authenticated including determining that the payor is the legitimate payor associated with the payor account by comparing the received challenge response with the account data retrieved from the issuer; and
transmit, via Internet communication to the first application associated with the payee, an authentication response based on the determination.When I construe claim 13, I consider it defines a software for performing the same method as defined in claim 7, and for programming the processor to perform the steps defined in claim 1.
The appended claims further define additional features of the claimed invention.
Claims 2 and 8 are appended to claims 1 and 7 respectively, and further define that the authentication request is retrieved via a web call.
Claims 3 and 9 are appended to claims 1 and 7 respectively, and further define that the memory is updated on a periodic basis and when account data changes at the issuer.
Claims 4, 10 and 14 are appended to claims 1, 7 and 13 respectively; and further define that the memory stores the funds amount associated with the account identifier.
Claims 5 and 11 are appended to claims 4 and 10 respectively, and further define that the funds amount in the memory is updated periodically.
Claims 6, 12 and 15 are appended to claims 4, 10 and 14 respectively; and further define that, when the account details have been authenticated successfully and the request includes a transaction amount, the response also includes an indicator whether the funds amount is more or less than the transaction amount.
The remaining objection
As noted, the only objection outstanding is that the claims are not for a manner of manufacture.
The examiner characterised the substance of the claimed invention as being:
“… an abstract computer-implemented scheme for authentication of a transaction based on a challenge-response scheme with the challenge incorporating account information”.
The examiner has consistently characterised the substance of the claimed invention as this in the previous examination report, as well as examination reports on the parent.
The applicant’s submissions
The submissions by the applicant, beyond that of providing the background of the claimed invention, was split between responding to the points raised by the examiner in the objection, and addressing the questions normally posed when considering patentability with respect to the case law.
Rather than repeat the submissions verbatim or discuss them in any level of detail now, I will address them as they are relevant to my consideration of manner of manufacture below.
The Relevant Law
The statutory basis for manner of manufacture is found at s18(1)(a) of the Act which states:
“(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 ...”
In National Research Development Corporation v Commissioner of Patents [1959] HCA 67, (1959) 102 CLR 252 (“NRDC”), the High Court provided a statement of the law in this regard. At page 275:
“... a process, to fall within the limits of patentability which the context of the Statute of Monopolies has supplied, must be one that offers some advantage which is material, in the sense that the process belongs to a useful art as distinct from a fine art ...- that its value to the country is in the field of economic endeavour”.
The High Court though was not laying down a precise formulation that can be applied without detailed consideration and noted that a case-by-case approach should be taken. In D’Arcy v Myriad Genetics Inc. [2015] HCA 35 (“Myriad”), at [23]:
“This Court in NRDC did not prescribe a well-defined pathway for the development of the concept of ‘manner of manufacture’ in its application to unimagined technologies with unimagined characteristics and implications. Rather, it authorised a case-by-case methodology.”
In Myriad, Gageler and Nettle JJ at [144] stressed the importance of having regard to the substance of the claimed invention, not simply the form of the claim:
“Whatever words have been used, the matter must be looked at as one of substance and effect must be given to the true nature of the claim.”
The principle of identifying the substance of the invention when determining whether a computer implemented method is patentable has been discussed in multiple decisions. For instance, Commissioner of Patents v RPL Central Pty. Ltd. [2015] FCAFC 177 (“RPL”) at [96] – [98]:
“A claimed invention must be examined to ascertain whether it is in substance a scheme or plan or whether it can broadly be described as an improvement in computer technology. The basis for the analysis starts with the fact that a business method, or mere scheme, is not, per se, patentable. The fact that it is a scheme or business method does not exclude it from properly being the subject of letters patent, but it must be more than that. There must be more than an abstract idea; it must involve the creation of an artificial state of affairs where the computer is integral to the invention, rather than a mere tool in which the invention is performed. Where the claimed invention is to a computerised business method, the invention must lie in that computerisation. It is not a patentable invention simply to ‘put’ a business method ‘into’ a computer to implement the business method using the computer for its well- known and understood functions.
Is the mere implementation of an abstract idea in a well-known machine sufficient to render patentable subject matter? Is the artificial effect that arises, because information is stored in RAM and there is communication over the Internet or wifi, sufficient? Does any physical effect give rise to a manner of manufacture? Are the mere presence of an artificial effect and economic utility, without more, sufficient to determine manner of manufacture?
It is not a question of stating precise guidelines but of deciding, in each case, whether the claimed invention, as a matter of substance not form, is properly the subject of a patent.”
RPL went further with regard to the role the computer plays stating at [107]:
“Simply putting a business method or scheme into a computer is not patentable unless there is an invention in the way in which the computer carries out the scheme or method.”
Similarly, the importance of recognising that there needs to be an improvement in the computer technology per se for an otherwise unpatentable but computer implemented invention to be a manner of manufacture was brought up in Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150 (“Research Affiliates”). The Full Court of the Federal Court noted at [103]:
“… there is a distinction, between mere implementation of an abstract idea in a computer and implementation of an abstract idea in a computer that creates an improvement in the computer.”
Thus, especially in relation to computer implemented inventions, it is necessary to look at the invention as a matter of substance, rather than as a matter of form. If the invention is, as a matter of substance, directed to patentable subject matter, then it follows that it is a manner of manufacture.
In determining the substance of the claimed invention, the Courts have been consistent when approaching claims that are a combination of integers. It is necessary to understand where the inventiveness or ingenuity in the claimed invention is said to lie, and then applying the developed principles with this in mind. At RPL [112]:
“Recognising that the claims are to a method and system comprising a combination of integers, it is necessary to understand where the inventiveness or ingenuity is said to lie. Turning to the integers of the invention as set out at [36] and [38] and summarised at [37] and [39] above, it is apparent that, other than the integers providing that the computer processes the criteria to generate corresponding questions and presents those questions to the user, the method does not include any steps that are outside the normal use of a computer.”
The recent Full Federal Court decisions in Commissioner of Patents v Rokt Pte Ltd [2020] FCAFC 86 (“Rokt 2”) and Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161 (“Encompass”) confirmed and applied the principles from Research Affiliates and RPL. More recently the Full Court in Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 (“Aristocrat ’21”), at [56] – [57] observed in relation to a claim defining an electronic gaming machine (EGM) with a particular feature game:
“What this purpose-specific but extremely common computer does is play the feature game. Consequently, the substance of the invention disclosed by Claim 1 is that feature game implemented on the computer which is an EGM. It is therefore a computer-implemented invention.
As we have already observed, integers 1.10-1.12 embody an abstract idea which may be characterised both as a set of rules defining a family of games and as a business scheme for increasing player interest in an EGM. As such its implementation in the computer which is an EGM cannot constitute patentable subject matter unless it represents an advance in computer technology.”
On appeal to the High Court, in Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 the Court was evenly split, and via s23(2)(a) of the Judiciary Act 1903 affirmed the Aristocrat ’21 decision, while appearing to confirm that an advance in computer technology is not a useful test for patentability. Additionally, the High Court appeared to confirm that the decisions of the Full Federal Court in RPL, Research Affiliates, and Encompass were correct.
The principles of law that apply to the present matter in the context of computer implementation appear to be well reflected in that as summarised by the Commissioner, and generally accepted at [200]-[201] by Robertson J in Rokt Pte Ltd v Commissioner of Patents [2018] FCA 1988 (“Rokt 1”) at [189] as follows:
“17.1 The Court must decide, as matter of substance not form, whether the claimed invention is the proper subject-matter for a patent: RPL Central at [99]; Research Affiliates at [106], [117].
17.2 This requires consideration of both the claims of the Application and the invention described in the body of the specification: RPL Central at [114].
17.3 The assessment is not done mechanically. There are no precise guidelines or mathematical formula. It is ‘a question of understanding what has been the work of, the output of, and the result of, human ingenuity’ and then applying the developed principles: Research Affiliates at [116]. See further RPL Central at [112]:
Recognising that the claims are to a method and system comprising a combination of integers, it is necessary to understand where the inventiveness or ingenuity is said to lie ...
17.4 One well-settled principle is that a distinction exists between a technological innovation and a business innovation. A technological innovation is patentable. A business innovation is not: Research Affiliates at [94]; RPL Central at [100]. Consequently, a business method or scheme is not, per se, a proper subject for letters patent: RPL Central at [96]. Nor are abstract ideas, mere intellectual information, or mere directions for use patentable: Research Affiliates at [101]; RPL Central at [100].
17.5 A computerised business method or scheme can, in some cases, be patentable. However, ‘[w]here the claimed invention is to a computerised business method, the invention must lie in that computerisation’: RPL Central at [96] (emphasis added). This requires ‘some ingenuity in the way in which the computer is used’: RPL Central at [104]. It is not a patentable invention ‘to simply “put” a business method “into” a computer to implement the business method using the computer for its well-known and understood functions’: RPL Central at [96]. In other words, if the ingenuity lies in the business method or scheme alone, the invention will not be patentable despite the computer-implementation.
17.6 Thus, a claimed invention must be examined to ascertain whether it is in substance a scheme or plan, or whether it can broadly be described as an improvement in computer technology: RPL Central at [96]. Contrary to [the applicant’s submissions at [49]], this is a binary distinction: the invention is either an unpatentable scheme or plan, or it is a patentable improvement in computer technology. In conducting the analysis, it is useful to:
17.6.1 ascertain whether the contribution to the claimed invention is technical in nature: RPL Central at [99], Research Affiliates at [114];
17.6.2 consider whether the invention solves a ‘technical’ problem within the computer or outside the computer: RPL Central at [99], Research Affiliates at [103];
17.6.3 consider whether the invention results in an improvement in the functioning of the computer, irrespective of the data being processed: RPL Central at [99], Research Affiliates at [118];
17.6.4 consider whether the invention requires merely ‘generic computer implementation’, as distinct from steps which are ‘foreign’ to the normal use of computers: RPL Central at [99], [102]; Research Affiliates at [101]; and
17.6.5 consider whether the computer is merely the intermediary, configured to carry out the method using program code for performing the method, but adding nothing to the substance of the idea: RPL Central at [99].”
Although Rokt 1 was overturned on appeal in Rokt 2, the Full Court did not criticise Robertson J’s acceptance of these legal principles as summarised above by the Commissioner in their submissions.
Manner of manufacture consideration
A stepped approach for assessing manner of manufacture can be summarised as construing the claim, identifying the substance of the claimed invention, and then asking whether the substance of the claim lies within established principles of what constitutes a patentable invention.
The claimed invention
I have previously construed the scope of the claims as discussed above. Broadly, claims 1, 7 and 13 are directed to an authentication method for an ACH transaction.
To determine the substance of the claimed invention, it is useful to ask the questions laid out in Rokt 1 to identify where the substance lies in contrast to the form of the claims. I note that the Applicant’s submissions aligned with all of these questions, and I have included them in my consideration.
Does the invention as claimed solve a technical problem within the computer or outside the computer?
The applicant concedes that security problems in the ACH environment may appear as business problems. Nevertheless they also submit[17] that the security issues addressed by the invention were also technical problems and directed my attention to paragraph [0021] of the specification which I have already discussed above at Paragraph 24.
[17] Page 5 of the Applicant’s Submissions
As a general position, there is no doubt that security issues can arise from technical problems, and that in resolving the aforementioned issues a technical problem would be solved. However, it is clear to me that none of the problems as presented in paragraph [0021] are technical in nature.
Firstly, a lack of authentication is not a technical problem in and of itself - it is simply an administrative issue. It is analogous to putting an ordinary padlock and bolt on an ordinary door, that had previously been unlocked, because it was decided that the door should now be locked. This is not solving a technical problem. A technical or technological barrier or obstacle preventing standard authentication methods being used for ACH transactions could be a technical problem requiring an equally technical solution. But I could not see any technical problems identified in the specification that prevented of authentication of ACH transactions.
Furthermore, I consider it trite to say higher risks, increased costs and lack of utilisation are in no way technical but are purely business problems.
Lastly, I cannot follow how longer processing times of alternative means of payment are a technical problem. The claimed invention doesn’t reduce the processing times of these alternative means, nor did the lack of authentication create a technical barrier to using ACH transactions. If anything, the length of processing times arises as a result of the administrative arrangements in place for those alternatives, rather than any technical issues. This is at best an administrative problem, if not a business problem.
I am not satisfied the claimed invention is solving a technical problem within or outside the computer.
Is the contribution to the claimed invention technical in nature?
The applicant submits that the contribution of the present invention resides in the authentication computing device being configured to transmit an ACH authentication challenge to a second client computing device and receive an ACH challenge response from a first client computing device from which an authentication request was transmitted. Furthermore, they submit that it is “…not appropriate to simply disregard the requirement for the different first and second computing devices from the claims.”[18] They also submit that this configuration is technical in nature because of the requirement for the first and second computing devices each performing their respective functions.
[18] Page 3 of the Applicant’s Submissions
I agree with the applicant that it is not appropriate to simply disregard the requirement for the different first and second computing devices from the claims when determining the substance of the claims. It is an important part of the claim, and forms part of the substance of the invention being claimed.
However, I consider this difference to be only administrative in nature, and not necessarily technical. Again, to use my previous analogy, putting an ordinary padlock and bolt on an unlocked door is not making a technical contribution, but is merely implementing an administrative decision. Similarly, giving the padlock’s key to a person different to the person(s) travelling through the door is also not a technical contribution. It is an administrative arrangement which may solve a security problem, and it may make a contribution in one sense of the word with respect to security, but it does so only in administrative and non-technical terms. Irrespective of how many padlocks are used and who is given the respective keys, the scheme will remain administrative in nature.
With respect to the method of the claimed invention, the mere number of devices used in the authentication steps, and the number of challenges or types used, is the administrative arrangement.
I am not satisfied that the claimed invention is making a contribution that is technical in nature.
Does the invention result in an improvement in the functioning of the computer, irrespective of the data being processed?
The applicant submits that the implementation of the claimed invention involves an improvement of computer technology. They contend this is because the present invention provides a more secure ACH transaction environment, which is a system that is inextricably linked to computer technology[19]. The conventional computer technology in a conventional ACH transaction environment is configured in a manner that gives rise to those security issues that are sought to be solved by the present invention.
[19] Page 3 of the Applicant’s Submissions
However, I cannot follow how the invention is an improvement in the functioning of the computer. Applying authentication techniques of an administrative nature where there was previously none is not an improvement in the computer. It is simply a decision to employ authentication. I can see nothing to suggest that the computer functions better; merely that ACH transactions are now authenticated whereas before they were not.
As such I cannot be satisfied this is an improvement within the functioning of the computer.
Does the invention require merely ‘generic computer implementation’, as distinct from steps which are ‘foreign’ to the normal use of computers?
Authentication challenges are not foreign to the normal use of computers, even for electronic financial transactions. An authentication challenge is an administrative arrangement using the computer devices to transmit, receive, display, and input information. None of these functions are foreign to the normal use of computers. This is further exemplified in that the specification relies on known and existing authentication challenges to authenticate the transactions and does not offer any new methods of challenging a user.
The Applicant submits that “[t]he configuration of the authentication computing device in the claimed manner was not well known at the priority date.”[20] I find this rather surprising, given how generically the configuration appears to have been described. But in considering the substance of the claims, I do not consider anything turns on whether the configuration is or isn’t well known.
[20] Page 5 of the Applicant’s Submissions
That is, even if it is said that the configuration is not known, the actual configuration arises due to the administrative scheme being implemented, rather than any technical deficiency. That is, while the system and configuration may be new, it is new because the scheme is new. I consider it trite to say that the mere fact that new software is required to implement the claimed invention on a computing device does not confer patentability to it. This can be seen in Court’s decisions of Research Affiliates, RPL Central, Encompass & Rokt 2.
As discussed above with respect to the invention as described, the computing technology used by the claimed invention is only ever described in generalised terms. Furthermore, no code or pseudo code is offered in the specification to implement the method. Similarly, there are no schematics or designs for specialised hardware to facilitate this authentication of transaction. The configurations of the claimed invention presented are entirely generalised and presented at an abstract level.
As such I cannot see how, in implementing the administrative arrangement, the method steps of the claimed invention would be foreign to the normal use of computers. Nor can I see how the claimed invention lies in the manner of how the claimed invention was implemented in the computer devices used.
Thus, I am satisfied that the claimed invention only requires a generic implementation by the skilled addressee to effect it.
Is the computer merely the intermediary in the claimed invention, configured to carry out the method using program code for performing the method, but adding nothing to the substance of the idea?
Although this is not directly relevant to my consideration of the question, I cannot agree with the applicant’s submission that there is no ‘pen and paper’ equivalent to it. To my mind, the invention is analogous to a bank cheque, which, in my opinion, falls into the scope of a ‘pen and paper’ financial transactions.
Cheques have their own authentication ‘challenge’ in the form of signatures, which were signed with a pen on the cheque’s paper. In the days of non-automated clearing houses, every transaction could be verified by signature authorisation of the transaction. Bank employees authenticated the transaction by comparing the signature on the cheque to the one on file before processing the cheque. If the signatures did not match, the bank would not honour the cheque, and thus not authorise the transaction.
Similarly, it was not uncommon for banks to call their account holders to confirm unusual payments or cheques. This has fallen by the wayside with electronic transactions, but it was, nonetheless, a well-known method of validating transactions. In fact, claims 2 and 8 are directed to a similar method using webcalls.
The specification applies these same methods by virtue of computing devices, which offer alternative means of validation to bank staff calling account holders. It is nonetheless the same method of following an administrative arrangement to challenge the user or payor of an ACH transaction request.
In the claimed invention, the computer is being used to carry out the method using ordinary program code which is not even disclosed in the specification. The computer is simply the medium in which these administrative arrangements are being applied. New administrative arrangements may require new or different methods, and thus new code to carry out the steps, but the role of the computer adds nothing to the method and the code itself. Thus, it cannot add anything to the substance of the claimed invention.
I am not satisfied that the computing devices are adding anything to the substance of the claimed invention.
The substance of the claimed invention
Taking into consideration my observations above, I consider the substance of the independent claims lies in the business method of authenticating a request for an ACH transaction received from one computing client device by challenging a second computing client device associated with the payor and confirming a positive challenge response. I consider that this method to validate ACH transactions uses purely administrative authentication means through generic computing devices.
It follows that the invention as claimed in the independent claims is not a manner of manufacture. It is, in substance, a business scheme to validate financial transactions which is implemented using generic computing technology for its well-known and well-understood functions. The scheme is not directed to any technological problem and the method of implementation does not involve any improvement in computer technology or any unusual or unconventional technical method or effect capable of giving rise to patentable subject matter.
Furthermore, I note that this finding is not avoided by any of the dependent claims. Using a web call (claims 2 and 8), updating the database periodically (claims 3, 5, 9 and 11), and tracking funds in the account (claims 4, 6, 10, 12, 14 and 15) are all standard parts of a business method for financial transactions. The substance of the claims doesn’t move beyond the authentication, and thus validation, of the ACH transaction request.
Conclusion
The claims do not define a manner of manufacture. The claimed invention is, in substance, a mere scheme and is not directed to a manner of manufacture. Having considered the body of the specification, I see no prospect for amendments which would overcome the described deficiencies. The broad nature of the specification provides no meaningful technical detail that could be promoted into the claims. Accordingly, I will refuse the application.
B. Norman
Delegate of the Commissioner of Patents
4