Block, Inc.
[2023] APO 21
•21 April 2023
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Block, Inc. [2023] APO 21
Patent Application: 2020273349
Title:Mobile device payments
Patent Applicant: Block, Inc.
Delegate: Tim Gillett
Decision Date: 21 April 2023
Hearing Date: Written submissions filed on 15 September 2022
Catchwords: PATENTS – section 45 – examiner’s objection – inventive step – manner of manufacture – payment system – cardless payment transaction – credit card – text message - short message service (SMS) – smartphone – feature phone – approval code – no patentable subject matter in application – inventive step not decided – application refused
Representation: Patent attorney for the applicant: FB Rice Pty Ltd
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2020273349
Title:Mobile device payments
Patent Applicant: Block, Inc.
Date of Decision: 21 April 2023
DECISION
The claims of the application, as proposed to be amended are not for a manner of manufacture. I cannot see any subject matter in the specification which could be used to overcome this issue and as such I refuse the application.
REASONS FOR DECISION
Background
Patent application 2020273349 (‘the application’) was filed on 20 November 2020 in the name of Block, Inc (initially Square, Inc). This is the fourth application in a string of related applications commencing from ‘great grandparent’ application 2014233712 which is a national phase entry of PCT/US2014/02608.
Eleven examination reports have been issued across the series of national applications. Each report objected that the claims are not directed to a manner of manufacture and are either not novel or not inventive. Other objections have been raised during the course of examination but are no longer outstanding.
The present application received two examination reports. Both reports suggested that the applicant request to be heard. The applicant requested to be heard on 2 May 2022 and was subsequently invited to provide submissions by 16 September 2022. The applicant provided those submissions on 15 September 2022.
Amendments to the specification have been proposed on 20 November 2020 and 4 March 2022. No objection was taken to these amendments during examination and I cannot see any reason for which they would not be allowable. Noting the conclusions I have reached this issue is moot and as such I will not make a decision about the amendments. All further references to the specification will be to that as proposed to be amended on 4 March 2022.
The examination of the present application is governed by the Patents Act 1990 (‘the Act’) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 (‘the Raising the Bar Act’) as the application was filed after 15 April 2013. Thus, the standard of proof that applies in the present case is the balance of probabilities (subsection 49(1)). I must accept the application if satisfied on the balance of probabilities that the application complies with the Act. If I am not so satisfied, then I can refuse the application.
Specification
The specification is titled ‘Mobile device payments’ and notes the technical field as relating to ‘processing payment transactions’. Page 1 provides a thorough background to the invention with the following:
In a conventional point-of-sale electronic credit card transaction, the transaction is authorized and captured. In the authorization stage, a physical credit card with a magnetic stripe is swiped through a merchant's magnetic card reader, e.g., as part of a point-of-sale device. A payment request is sent electronically from the magnetic card reader to a credit card processor. The credit card processor routes the payment request to a card network, e.g., Visa or Mastercard, which in turn routes the payment request to the card issuer, e.g., a bank. Assuming the card issuer approves the transaction, the approval is then routed back to the merchant. In the capture stage, the approved transaction is again routed from the merchant to the credit card processor, card network and card issuer, and the payment request can include the cardholder's signature (if appropriate). The capture state can trigger the financial transaction between the card issuer and the merchant, and optionally creates a receipt. There can also be other entities, e.g., the card acquirer, in the route of the transaction. Debit card transactions have a different routing, but also require swiping of the card.
Many transactions require that the customer sign a physical receipt, electronically approve a transaction, e.g., by pressing an approve button on a user interface, electronically sign for the transaction, e.g., with a stylus or finger on an electronic signature capture device with a touch sensitive pad, or enter an authorizing personal identification number (PIN).
Noting that the transaction is described as conventional, this suggests that it falls within the common general knowledge of the person skilled in the art.
The specification summarises the invention with the following on page 1-2:
The specification describes how a system can conduct cardless payment transactions using text messaging. A smartphone can run applications that can make cardless payment transactions possible. However, if a phone is not Internet enabled, the system can allow the phone to make cardless payment transactions using text messaging. A payment service system can receive a request to conduct a payment transaction on behalf of a merchant. The request can identify a user having a user account with the payment service system. The system can then request approval of the payment transaction by sending a text message to a mobile phone number associated with the user account. The user can approve the payment transaction by responding with a text message, allowing the payment service system to complete the payment transaction.
I note that the scope of the term ‘text message’ is not immediately apparent. I will return to this later, but for now, I have construed the term broadly.
10. The specification then describes ways in which the invention can be used for a range of transaction types. Merchant initiated, user initiated, and user to user. These are each represented by figure 2, figure 3, and figure 4.
11. I note that the term ‘user’ could be understood to mean a ‘user of the system’ thus including a merchant too. The specification uses the word to mean non-merchant users of the system though. In the embodiment with two users this means there are two users and no merchant. I will use the term as it has been used in the specification, i.e., users are non-merchant users of the system. Where the term ‘customer’ has been used it should typically be read the same as ‘user’.
12. Moving on to the detailed description the specification mentions two problems being addressed. The ability of users to interact with the system in a range of settings as well as the ability to work with both a ‘smartphone’ and a ‘feature phone’. See for example on pages 4-5 of the specification:
As an overview, the system allows a user to conduct cardless payment transactions using a text message sent from a mobile device, e.g. a mobile phone. The system allows the user (also called a customer or payer) to purchase items from a merchant while either physically present at the merchant, e.g., at the point of sale, or online, e.g. through a merchant's website, but using a cardless payment transaction. The system also allows the user to pay or request payment from other users of the system using a cardless payment transaction.
By providing the ability to conduct cardless payment transactions using a text message, the system allows users having mobile phones with only basic text messaging capabilities to conduct cardless payment transactions. Such devices with only basic text messaging capabilities may be referred to as “feature phones” to distinguish them from “smartphones,” although any device with text messaging capability can carry out cardless payment transactions in this way.
13. The specification discusses registration of users on page 7 with the following text:
Before a transaction between users or between a user and a merchant can be performed using the cardless payment system, each user must create a user account with the payment service system 108 and the merchant must create a merchant account with the payment service system 108.
14. Registration of merchants is described in more detail on page 8 noting that the merchant will need to download ‘a merchant application’ prior to the transaction. The merchant application itself is not explained, however, presumably the person skilled in the art would have been familiar with such applications and would be able to implement one by routine. Whilst the merchant must also be verified, the specification notes that the system may not have the merchant’s financial account information prior to the transaction:
At some point prior to the transaction, a merchant application is downloaded to the merchant device 102, e.g., through an application store. Creation of the merchant account can be handled through the merchant application, or through another application, e.g., a generic web browser.
Eventually, in order to receive funds from the transaction, the merchant will need to enter financial account information into the payment service system sufficient to receive funds…
15. The specification notes that if either party to a transaction is not verified then the transaction will fail with a notification being issued. For example, on page 12:
If either the merchant or the user does not have a verified account, the payment service system notifies the user device that the transaction has failed (branch to 306). For example, the payment service system can send a text message to the user device indicating that the transaction has failed. The user device can then provide a failure notification to the user, e.g. by presenting the text message (308).
16. The specification also describes sending a failure notification if the code is not verified. Notably this notification is sent to one or both sides of the transaction depending on who initiated the transaction and why the failure occurred.
17. The specification describes initiating the transaction in various ways. Each of the methods described align with either of figures 2, 3, or 4. The present claims align with that shown in figure 3 only. Previously submitted claims aligned with figures 2 and 4, however, they have been removed via amendment.
18. The embodiment of figure 3 has the transaction initiated by the user. The user sends a message 302 to the payment service system identifying the merchant. No approval message is described, presumably because the initial message sent by the user constitutes approval.
19. As noted, the embodiments of figures 2 and 4 correspond to different embodiments from that of the claims as they stand, nevertheless I will briefly discuss these for completeness.
20. The embodiment of figure 2 has the transaction initiated with a message 202 sent from the merchant to the payment service system. That message is sent via the merchant device and can be sent over a range of communication means, but typically over the internet. This is followed by an approval code which is sent to the user.
21. The embodiment of figure 4 shows that a first user initiates the transaction with a second user by sending a message 402 to the payment service system. The specification notes that this could be either to send or receive funds and notes an approval code being sent at step 410.
22. All embodiments include a message which is sent by the user that is releasing funds.
23. The specification addresses the content of relevant messages with the following on page 10. I note that this is in relation to the embodiment shown in figure 2, however, it gives some context as to how the text messages and approval codes function:
The user device presents the approval code to the user (212). The approval code can be presented as part of a text message that includes instructions for approving the payment transaction. In some implementations, the text message identifies the merchant and the amount of the purchase transaction. For example, the text message can be “Respond to this message with 'yes' to approve your purchase of $7.89 at Joe's Sub Shop.” In this example, the approval code, “yes,” if received by the payment service system, indicates that the user has approved the purchase transaction. The approval code can be any combination of alphanumeric or other characters supported by the particular text messaging protocol being used. For increased security, for example, the approval code can be a random or pseudorandom string of letters.
The user device sends a responsive message to the payment service system (214). The user device can for example repeat the approval code in a text message to the payment service system. The user can send a responsive text message by replying to the phone number of the original received text message that included the approval code. The user can decide to either approve the transaction or void the transaction by providing the appropriate approval code to the payment service system. For example, if the amount of the payment transaction initiated by the merchant is too high, the user can decline the transaction by sending a text message with an approval code that does not match.
24. Interconnections are shown in figure 1 and discussed on pages 6-7 with various implementations mentioned including WLAN, Wifi, 3G/4G and others for Networks 106 and connectivity with networks such as VISA and Mastercard for Card Payment Network 116. I consider this material to be well known to the person skilled in the art.
25. The specification mentions personally identifiable information which may add to the security of the system. For example, presenting a picture of the user to the merchant for them to verify is discussed on page 9.
…In some implementations, through the GUI of the merchant application, the merchant can select items that the user has sought to purchase… Before or after the user authorizes payment for the transaction, the merchant verifies the user's identity. In some implementations, the merchant ensures that the image displayed on the merchant device matches the user who is present at the point of sale. Assuming that the image matches, the merchant selects the transaction using the GUI of the merchant application. In some implementations, the merchant can ask the user for more identifying information before processing the transaction such as the user's birthday, address, or other personal identifying information. After verifying the user's identity, the merchant interfaces with the merchant application to continue processing the transaction, e.g. by sending the approval code to the user device (210).
26. As noted earlier, the scope of ‘text message’ is not immediately apparent. The term has been discussed many times in the specification, however, it falls short of providing a dictionary definition.
27. In looking for a plain meaning I have noted various well-known dictionaries that define the term as follows:
Macquarie: noun a message sent by mobile phone using SMS.
Oxford: a written message that you send using a mobile phone
Merriam-Webster: a short message sent electronically usually from one cell phone to another
Collins: A text message is a written message that you send using a mobile phone.
28. These support a broad construction whereby text message is essentially any written message sent from a mobile phone. This could extend to those sent from an electronic device more broadly, however, the distinction is unimportant for this decision so I will not address it.
Claims
29. The specification includes 20 claims with claims 1, 7, and 14 being independent. For the purposes of this decision, in relation to manner of manufacture, claims 1, 7, and 14 are similar to the extent that any decision made in relation to claim 1 will apply equally to claims 7 and 14. The dependent claims do not add material that is likely to have a substantial effect on the outcome either. As such, rather than discussing each claim, my analysis will focus on claim 1 alone with any conclusion reached being applied to all claims.
30. Claim 1 reads as follows:
A computer-implemented method for performing a cardless payment transaction via text message, the computer-implemented method comprising:
receiving, at a server system of a payment processing service, a text message from a mobile device of a user, the text message including a code identifying a merchant;
verifying, by the server system, identities of the merchant and the user based at least in part on:
identifying, by the server system and from a plurality of merchant accounts stored in association with the payment processing service, a merchant account of the merchant from the code included in the text message; and
identifying, by the server system and from a plurality of user accounts stored in association with the payment processing service, a user account of the user based on the text message;
providing, from the server system and to a merchant computer of the merchant and based at least in part on verifying the identities of the merchant and the user, user information associated with the user account;
receiving, at the server system and from the merchant computer, a request to authorize the cardless payment transaction;
obtaining, at the server system and from a computer system of a payment network, authorization for the cardless payment transaction using account information associated with at least one of the merchant account or the user account; and
providing, from the server system and to the merchant computer, notification of the authorization of the cardless payment transaction.
31. Claim is 1 is directed to a computer-implemented method, that method being for (capable of) performing a cardless payment transaction via text message. The term cardless would likely be understood by the person skilled in the art, however, it has been explained on page 5 of the specification:
A cardless payment transaction is one where a user conducts the transaction with a merchant or another user by using a financial account without physically presenting a payment card to the merchant at the point of sale or without otherwise providing payment card information. In fact, the merchant or other user need not receive any details about the financial account, e.g., the credit card issuer, credit card number, and the like is not provided to the merchant or the other user.
32. This explanation seems to imply that a cardless transaction is limited to credit card transactions. However, on page 7 the specification notes the following:
…Before a transaction can be performed, the user also enters financial account information sufficient to conduct the transaction into the payment service system 108. For example, in the case of a credit card account, the user can enter the credit card issuer, credit card number and expiration date into the payment service system 108; the card validation value and mailing address may also be required. However, the financial account could also be associated with a debit card or pre-paid card, or another third party financial account.
33. This suggests to me that cardless should be understood to mean any transaction in which neither a payment card, nor the details of a payment card are provided. As such it includes all types of transaction which meet those criteria, for example, an electronic funds transfer.
34. Following this are a series of features of the method which appear to be presented chronologically (although no order is claimed explicitly). Initially a text message is received by the system from the mobile device of the user.
35. Both the user and the merchant are then verified and identified. The server system then provides user information to a merchant computer. Notably, the claim does not explicitly include any further information in this communication, for example a transaction amount, goods/services provided etc. The claim then specifies that a request to authorise the cardless payment transaction is received at the server from the merchant computer.
36. I will first focus on manner of manufacture and address the examiner’s and applicant’s positions as follows.
The examiner’s objection
37. There are two outstanding objections, items three & four from examination report two dated 30 March 2022. These are directed to Manner of Manufacture and Inventive Step respectively. Starting with objection 3 which reads as follows:
Objection 1 of the previous report is maintained. I have carefully considered your response and amendments. However, the response and amendments are not persuasive.
Claims 1 to 20 still do not define a manner of manufacture within the meaning of Section 18(1)(a) of the Patents Act 1990. In general, the principles set out in D'Arcy v Myriad Genetics Inc [2015] HCA 35 (Myriad), Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (RPL) and other cases require analysing whether the claimed invention, as a matter of substance rather than form, is suitable subject matter for a patent.
The substance of the claimed invention is to be determined by considering the claimed invention’s actual or alleged contribution to the art.
It is submitted in your response page 2 paragraph 2 that “the present methods and systems and the contribution provided thereby are clearly technical in nature. The claims are directed to the implementation of a client-server architecture distributed across a user mobile device, merchant computer, payment network and payment processing server. Further, the ability to complete a financial transaction via text message, such as the lightweight data transfer protocol known as short message service (SMS) is also inherently technical. In the Applicant’s sincere opinion, there can be no disputing that the described embodiments and their contributions are technical in nature”.
Firstly, as stated in the previous reports, it is part of the state-of-the-art to conduct cardless payment transactions using mobile phones in a secure authorisation process, wherein the secure authorisation process includes verifying users and/or merchants by the information in a text message (as exemplified by D1 which is discussed in more detail with regard to the inventiveness). Thus it is considered that existing systems at the priority date already implemented the process of completing a financial transaction via SMS messages. Sending the transaction information in a SMS message is not considered to travel beyond the state of the art. Therefore, such feature cannot be the technical contribution to the art and thus are not the substance of the invention.
Secondly, the substance of the invention lies only in the scheme of processing a payment transaction. Implementing such scheme by utilising generic computer technology for its well-known and well understood functionality (e.g. client-server architecture with serval servers and the mobile phones as client devices) does not define subject matter suitable for a patent.
The applicant further asserts the similarity between the current application and the Facebook (Facebook, Inc. [2020] APO 19 (Facebook)) by stating “the technical solution of sandboxed applications on mobile devices and the lightweight nature of SMS messages are similar, as they are technical limitations that are brought about by the very design and implementation of the technology of mobile devices”.
It is considered that there is a clear distinction between the inventions in Facebook and the present arrangement. In the decision of Facebook, the technical solution of sandboxed applications on mobile devices was described as “a technical improvement in the device” because the “utilisation of the shared memory requires code that is downloaded with the app itself in order to access the shared memory. The first app then access that shared memory and sends the information back to an online system along with user data”. On the contrary, in the present application, utilizing SMS messages in mobile phones to transfer financial information is merely sending specific data by utilizing conventional devices and does not involve any ingenuity in the way in which the mobile device is utilised.
Furthermore, with regard to your assertions based on Jagwood Pty Ltd [2020] APO 38 (Jagwood)) and Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 (Aristocrat), I confirm that the assessment of a manner of manufacture is not whether the invention employs generic computer technology, but whether the substance of the invention is of sufficient technical character. This is also set out by RPL decision at para [099]: “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 … 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”.
When considering the claimed features in combination, the specification as a whole, and the state of the art, it is apparent that the substance of the invention lies only in the scheme of processing a cardless payment transaction. The additional elements or the combination of elements, such as the server systems, merchant computers and mobile phones amount to no more than implementing the scheme using well-known aspects or functions of the computer technology, and do not change the fundamental character of the application. Therefore, I maintain that the claimed invention, as a matter of substance, does not define the subject matter suitable for a patent.
The applicant’s submissions
38. The applicant has addressed both objections three & four. Again, starting with objection three the applicant has made the following comments:
Relevant case law
The recent High Court decision in Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 (Aristocrat) has provided some clarity around the approach to determining whether a claimed invention is for a manner of manufacture.
In quoting Myriad[1], the High Court affirmed that a claimed invention should be characterised “by reference to the terms of the specification having regard to the substance of the claim and in light of the common general knowledge.”[2] The High Court further asserted that “[t]he claimed invention takes its character, as an invention, from those elements of the claim which are not common general knowledge.”[3]
[1] D'Arcy v Myriad Genetics Inc (2015) 258 CLR 334 at 342-343 [12], 385-388 [138]-[145]
[2] Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 at [73]
[3] ibid
At [68], the High Court quoted paragraph [109] N V Philips, which in part states “…the primary or threshold requirement of a ‘patentable invention’ is that it be an ‘invention’. …It simply means that, if it is apparent on the face of the specification that the quality of inventiveness necessary for there to be a proper subject of letters patent under the Statute of Monopolies is absent, one need go no further.”
The High Court further held at [77]:
In conformity with the decision in N V Philips, the issue is whether the implementation of what is otherwise an unpatentable idea or plan or game involves some adaption or alteration of, or addition to, technology otherwise well-known in the common general knowledge to accommodate the exigencies of the new idea, plan or game.[4]
[4] Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 at [77]
Examiner’s objection
The examiner alleges:
When considering the claimed features in combination, the specification as a whole, and the state of the art, it is apparent that the substance of the invention lies only in the scheme of processing a cardless payment transaction. The additional elements or the combination of elements, such as the server systems, merchant computers and mobile phones amount to no more than implementing the scheme using well-known aspects or functions of the computer technology, and do not change the fundamental character of the application. Therefore, I maintain that the claimed invention, as a matter of substance, does not define the subject matter suitable for a patent.
As is now clear from the recent Aristocrat decision, the substance of the invention is not characterised vis-à-vis “the state of the art”, but vis-à-vis the common general knowledge.
The examiner argues:
Firstly, as stated in the previous reports, it is part of the state-of-the-art to conduct cardless payment transactions using mobile phones in a secure authorisation process, wherein the secure authorisation process includes verifying users and/or merchants by the information in a text message (as exemplified by D1 which is discussed in more detail with regard to the inventiveness).
This approach is clearly erroneous. The Aristrocrat decision affirms that a claimed invention takes it character, as an invention, from those features those elements of the claim which are not common general knowledge. And although the examiner alleges that D1 is the state of the art, she has not asserted, nor demonstrated, that D1 could be considered the common general knowledge.
Surely, such a step is necessary for a proper lack of manner of manufacture objection to be made out. Notwithstanding this, D1 does not actually disclose a secure authorisation process involving verifying users and merchants using a text message which includes a code identifying a merchant, as claimed in the independent claims of the present application.
As explained above, D1 does not actually disclose the following claim features:
Ø receiving, at a server system of a payment processing service, a text message from a mobile device of a user, the text message including a code identifying a merchant
Ø verifying, by the server system, identities of the merchant and the user based at least in part on:
i.identifying, by the server system and from a plurality of merchant accounts stored in association with the payment processing service, a merchant account of the merchant from the code included in the text message;
ii.identifying, by the server system and from a plurality of user accounts stored in association with the payment processing service, a user account of the user based on the text message;
Ø providing, from the server system and to a merchant computer of the merchant and based at least in part on verifying the identities of the merchant and the user, user information associated with the user account;
In fact, D1 addresses the problem of mitigating fraud in transaction processing in a completely different way. D1 is concerned about mitigating risk of security breaches at the merchant server, and to combat that, discloses techniques whereby the customer provides their account details directly to the payment processing network and not to the merchant sever.
The contribution to the art provided by the claimed invention, including the distinguishing features over D1, is that of an improved cardless payment transaction handling system and process that mitigates fraudulent behaviour when cardless payment transactions are being processed.
The claimed invention solves this technical problem though the combination of a customer initiated payment process whereby a message identifying a merchant is received from a customer at the server system of a payment processing service via a text message, and a verification process whereby the identities of the customer and merchant are verified using merchant and customer accounts stored in association with the payment processing service.
Once verified, user information is provided to the merchant, a request to authorise the payment is received from the merchant and authorisation for cardless payment transaction is obtained.
Therefore, the claimed invention provides for an adaption or alteration of the technology of the common general knowledge and to the prior art of D1 (which again the applicant does not concede to be common general knowledge) to accommodate the exigencies of mitigating fraud in transaction processing.
And furthermore, the proposed independent claims recite a specific technical implementation that solves the technical problem of how to provide more secure processing of cardless payment transactions which mitigates fraud.
The claims therefore define a manner of manufacture.
Manner of manufacture: legal principles
39. S18(1)(a) of the Patents Act 1990 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;
40. The broad principles to consider manner of manufacture have been set out in National Research Development Corporation v Commissioner of Patents [1959] HCA 67 (‘NRDC’). At [14]:
The right question is: “Is this a proper subject of letters patent according to the principles which have been developed for the application of s. 6 of the Statute of Monopolies?”
41. Further guidance was provided in D'Arcy v Myriad Genetics Inc [2015] HCA 35 (‘Myriad’) to look for the substance of the invention. This is reflected in [87] & [88] by the majority and repeated by the minority at [144] quite succinctly:
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.
42. Aristocrat Technologies Australia Pty Limited [2016] APO 49 (‘Aristocrat ‘16’) summarised considerations appearing in Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150 (‘Research Affiliates’), and Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (‘RPL’) at [35] as follows:
I conclude that it is relevant to consider a range of matters. Without seeking to be exhaustive, these include:
othere must be more than an abstract idea, mere scheme or mere intellectual information;
ois the contribution of the claimed invention technical in nature;
odoes the invention solve a technical problem within the computer or outside the computer;
odoes the invention result in improvement in the functioning of the computer, irrespective of the data being processed;
odoes the application of the method produce a practical and useful result;
ocan it be broadly described as an improvement in computer technology;
odoes the method merely require generic computer implementation;
ois the computer merely an intermediary or tool for performing the method while adding nothing of substance to the idea;
ois there ingenuity in the way in which the computer is utilised;
odoes the invention involve steps that are foreign to the normal use of computers; and
odoes the invention lie in the generation, presentation or arrangement of intellectual information.
43. These seem to summarise a well-tested approach to assess patentability for computer implemented inventions. I note that later Full Court decisions including Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161 (‘Encompass’), and Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223 (‘Repipe’) have not diverted from this approach in any meaningful way.
44. In relation to Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 (17 August 2022) (‘Aristocrat ‘22’), since there was no majority decision the outcome was determined according to s22(a) of the Judiciary Act 1903 (Cth). Further, as a result of the split decision there is not necessarily any usual binding precedent so care should be used in relying upon individual paragraphs of Aristocrat ’22.
Considerations
45. In determining what the substance of the invention is, the examiner’s objection references D1[5] (‘CARLSON’) to exemplify the state of the art. The applicant has critiqued this approach discussing both the disclosure of CARLSON and whether it is state of the art or common general knowledge that should be considered. I note that this critique focusses on the disclosure of CARLSON as opposed to whether the relevant features would have been common general knowledge or not.
[5] US2008/0319869 A1 CARLSON et al. 25 December 2008
46. CARLSON is directed toward providing payment information to a trusted third party rather than a merchant. It is about who the payment information is sent to whereas the present invention is about how and when it is sent (pre-registration and text message confirmation).
47. Reviewing previous examination reports I have also noted D2[6] (‘QAWAMI’) was maintained for several reports. There was some discussion of QAWAMI in the response dated 21 September 2020 for parent application 2019240563 after which the citation has no longer been mentioned.
[6] US2012/0290421 A1 (QAWAMI et al.) 15 November 2012
48. To avoid entering a de facto assessment of inventive step I will not remark on CARLSON or QAWAMI any further at this point.
49. The applicant has noted the following in relation to the present invention:
The claimed invention solves this technical problem though the combination of a customer initiated payment process whereby a message identifying a merchant is received from a customer at the server system of a payment processing service via a text message, and a verification process whereby the identities of the customer and merchant are verified using merchant and customer accounts stored in association with the payment processing service.
Once verified, user information is provided to the merchant, a request to authorise the payment is received from the merchant and authorisation for cardless payment transaction is obtained.
Therefore, the claimed invention provides for an adaption or alteration of the technology of the common general knowledge and to the prior art of D1 (which again the applicant does not concede to be common general knowledge) to accommodate the exigencies of mitigating fraud in transaction processing.
And furthermore, the proposed independent claims recite a specific technical implementation that solves the technical problem of how to provide more secure processing of cardless payment transactions which mitigates fraud.
50. This characterisation is remarkable noting that the specification does not mention the word ‘fraud’ at all. Further, the word ‘secure’ is mentioned only on page 6 to note that the information must be kept secure. A prima facie review of the specification demonstrates that whilst fraud mitigation may be and probably is a consideration, it clearly does not form part of the substance of the invention. I will note that my decision is unlikely to turn on this point in any case since fraud prevention per se is not an inherently technical issue.
51. Turning to the touchstones from Aristocrat ’16, I note the considerable overlap in these. Consequently, I have considered those which provide, in my view, for non-redundancy in considering substance of the invention whilst still allowing for a proper determination of the substance of the same.
Is the contribution of the claimed invention technical in nature?
52. Point-of-sale transactions are not new. The specification is clear on this point from the outset whereby it notes the problem being addressed is to improve cardless transactions. This part of the specification also discusses including multiple parties in the transaction and routing information between them. For example, VISA/Mastercard and the card issuer who approves the transaction.
53. The specification describes prior art attempts to secure this transaction with steps such as swiping the payment card, signing a receipt, entry of a PIN etc. The present invention apparently contributes to the prior art by routing text messages between the user and the payment processing system. I note that this text message performs essentially the same function of a PIN, presenting the payment card, or signing a receipt. Providing a level of assurance that the intended account holder is seeking to release funds.
54. The decision to secure the transaction by communicating with the user is not technical, it is a risk assessment used in doing business. It is a business decision with considerations such as the risk of approving a fraudulent transaction vs the level of impact on the user. I note that the invention uses a text message for the exact purpose a text message is designed; to convey a written message between parties.
55. I have also noted a secondary aspect of the invention as described which is to send the text message via SMS thus including the feature phone user as well as smart phone user. However, this too is a non-technical matter. There is no modification to the underlying SMS and other technology used – it used for its well-known ability to communicate information.
56. In both cases there does not appear to be any technical difficulty to overcome nor technical contribution. The specification does not discuss any technical difficulties of any kind in implementing the invention. As such I conclude that the contribution is not technical in nature.
Does the invention solve a technical problem?
57. The problem described is to provide a more accessible payment system. This exists in two ways, both providing a cardless payment system which can be used in a variety of settings and that cardless transactions of the prior art require a smartphone to participate, leaving feature phone users excluded. Neither problem is inherently technical though. It is a decision to cater for user needs.
58. Instead, I consider that the problem being addressed is that prior art carless payment arrangements are not as accessible as they could be. The solution is to use a different, more accessible means, text messaging. Cast in this light no technical problem is solved. Instead, the solution simply utilises a well-known service which is convenient for users.
Does the application of the method produce a practical and useful result?
59. As a result of this method, users have more options to undertake a cardless transaction. This is clearly a useful and practical result.
Does the method require only generic computer implementation?
60. The specification does not discuss any specific type of computing equipment required to implement the invention. I consider that it only requires well known computer equipment used in a typical manner. As discussed above, the systems and hardware used are simply off the shelf technologies that are well-known, with there being no modification of these in a technical sense to achieve the claimed invention.
Is there ingenuity in the way in which the computer is utilised?
61. There is ingenuity in a business sense that users may respond well to a convenient payment system and choose to use it. Text messaging is a tool which users typically have access to. However, there is no ingenuity in the operation of that message per se, it involves using text messaging in precisely the way they have been designed, sending and receiving written information.
62. For these reasons I consider that there is ingenuity in determining that the existing system was cumbersome to some users. However, this is ingenuity in a business sense, recognising that there is a gap in the market as opposed to technical ingenuity.
Summary
63. The invention is a method of handling a cardless transaction using text messaging to authorise the funds transfer. In deciding whether the present invention is for a manner of manufacture, whilst considering all factors, the lack of technical problem and/or a technical solution as a matter of substance is a strong factor. Combined with the fact that the present invention operates on well-known computer technology operating in a typical fashion strongly suggests the true nature of the invention is non-technical.
64. I have considered various other factors such as the invention being useful and practical. However, the utility is in a business sense that offering a convenient system for the user is more likely to be successful. It is smart business sense to offer convenient services rather than necessarily being a technical challenge.
65. While I have noted that the invention does appear to involve ingenuity, this is limited to recognising a need to cater various users. Whilst the technology was there to do it, it is possible that no one would have implemented a text message based service, not because they could not, but because they have chosen not to invest in the required equipment. This I think is the crux of the issue, the substance of the invention is a decision to engage in a particular business practice rather than an overcoming a technical issue. As such, I do not consider that the application is directed to a manner of manufacture.
66. Looking through the specification I have not found any subject matter which could overcome this issue. The various further features that have been described contribute to the functionality of the system, however, they do not change the nature of the invention as a matter of substance, which is a business innovation. I also note that the applicant has not made a case that there is any additional patentable material in the specification. I consider that refusal is appropriate based on this defect.
67. I note here that inventive step remains outstanding. Noting that manner of manufacture is terminal I do not intend to make any decision in relation to inventive step. I will note briefly that QAWAMI appears to be highly relevant, however, noting that manner of manufacture is an insurmountable issue any conclusion I reach about inventive step will be moot. I also note that the applicant has not been invited to provide submissions as to the relevance of QAWAMI.
Conclusion
68. For the above reasons I find that claims 1-20 are not for a manner of manufacture.
69. Further, there is not any subject matter in the specification which could be introduced to overcome this issue. As such, I refuse the application.
Tim Gillett
Delegate of the Commissioner of Patents
0
10
0