Block, Inc.

[2023] APO 27

IP AUSTRALIA

AUSTRALIAN PATENT OFFICE

Block, Inc. [2023] APO 27

Patent Application:             2021200597

Title:Processing a mobile payload

Patent Applicant:                Block, Inc.

Delegate:Greg Powell

Decision Date:  10 May 2023

Hearing Date:  Written submissions filed on 5 April 2023

Catchwords:  PATENTS – examiner objections – clarity – inventive step – manner of manufacture – amended claims overcome examiner’s clarity objection but remain unclear – amended claims overcome examiner’s inventive step objection – claims are not directed to a manner of manufacture – no patentable subject matter identified in the specification – application refused

Representation:                   Patent attorney for the applicant: FB Rice Pty Ltd

IP AUSTRALIA

AUSTRALIAN PATENT OFFICE

Patent Application:             2021200597

Title:Processing a mobile payload

Patent Applicant:                Block, Inc.

Date of Decision:                10 May 2023

DECISION

The clarity and inventive step objections raised by the examiner cannot be sustained in light of the amended claims.

Claims 3, 9 and 15, as proposed to be amended, are not clear.

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

1. Patent application 2021200597 (the present application) was filed by Square, Inc. on 29 January 2021.  Square, Inc. subsequently changed its name to Block, Inc. (the applicant).  The present application was filed as a divisional application of patent application 2017322412 (the parent application).  The parent application was filed as a PCT application (PCT/US2017/050719) on 8 September 2017.  Ultimately, the present application claims priority from several US applications, with the earliest being filed on 12 September 2016.

2. The present application was filed after 15 April 2013.  The fate of the present application is therefore governed by the Patents Act 1990 (the Act) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012.  These amendments included the introduction of new section 49(1).  Under this provision, I must accept the present application if satisfied on the balance of probabilities that it complies with the requirements of the Act.  If I am not so satisfied, I can refuse the present application.

3. A first examination report was issued on 13 September 2021 raising objections in relation to section 40 and inventive step.  The applicant responded to the first examination report on 12 January 2022 by way of written submissions and proposed amendments to the description and claims.  A second examination report issued on 9 February 2022 containing a section 40 objection but reserving opinion on novelty and inventive step.  A response was filed on 20 May 2022 with further arguments and amendments to the claims.  On 1 June 2022 a third examination report issued containing objections with respect to manner of manufacture, section 40, and inventive step.  On 12 September 2022, the applicant requested to be heard.  On 5 April 2023 the applicant filed written submissions (“written submissions”) along with amended claims. 

4. Five amendments were proposed during examination.  While the claims that were supplied with the written submissions were not accompanied by a separate Statement of Proposed Amendments, it is clear from the written submissions that the amendment being sought is to replace the claims that were on file (being those dated 20 May 2023) with the new claims accompanying the written submissions.

5. No objection was raised by the examiner to the allowability of the amendments.  I do not see any issues around allowability either.  In this decision I am considering the specification as proposed to be amended by the statements of proposed amendments up to and including proposed amendment five filed on 20 May 2023, as well as containing the proposed claims filed with the written submissions.  Wherever I refer to the specification, it is a reference to the specification as proposed to be amended.

6. Finally, while the final date for acceptance of the present application was 13 September 2022, the time for gaining acceptance is extended by 3 months from the date of the present decision (see reg 13.4(1)(g)), or longer if appropriate (see reg 13.4(3)).

   The invention as described

7. The specification notes[1] the difficulties that can exist when attempting to send money through a variety of online services, such as online checking accounts or online payment methods.  It notes that online payment methods can be a complex and time-consuming process requiring the input of various pieces of financial and recipient information that the payor may not know.  For example, the payor may only know a recipient’s mobile number and not their account number.  The specification notes that a payor may be communicating with a recipient using a messaging or social networking app on their mobile phone, but would have to open a different app to send a payment to the recipient.  The specification points out[2] that standard SMS and MMS apps for messaging between mobile devices are not useful mechanisms for transferring funds between individuals, even though the instant communications afforded by such apps would make them potential candidates for real-time transfer of funds or other data.

   [1] Specification at [0001a]

   [2] Ibid at [0008]

8. The specification states that there exists a problem of how to send payments easily and securely to another party as the current methods for sending payments between mobile devices did not provide flexibility and ease.  The specification states that there was a need for a technical solution for this problem and that the embodiments sought a system for secure and easy payments using a mobile device and existing telecommunications and IP-based infrastructures.

9. The specification observes[3] that existing protocols (e.g., SMS, MMS) and applications using the protocols were only capable of transmitting simple messages or graphics from one device to the other and had no means of conducting a fund transfer.  However, the specification notes that new communication technologies had been introduced which permitted more sophisticated data transfers and interactions between the devices through a conventional instantaneous text messaging medium.  The specification states that the embodiments provided in the present application were directed to systems that united the financial institution networked systems that facilitated funds transfers between large scale financial systems with an instantaneous messaging system that facilitated data transfers between mobile devices.

   [3] Ibid at [0010]

10. As described, the payor’s mobile device’s instant messaging application sends a payment request to a payment processing server (PPS).  The payment request may contain information such as an amount to be paid and identification of the payor.  The messaging system can keep the recipient’s device information or identifier (e.g., phone number, MAC address, IP address) secret, such that the PPS does not receive or transmit any identification data associated with the recipient.  The PPS communicates with a financial account held at a financial institution so that the PPS can decrement the payor’s account.  The PPS creates an escrow account and increment the balance of this account based on the payment request.  The PPS generates a token string related to the escrow account.  This token string can contain an alphanumeric string based on a random value generator.  The PPS generates a payload with a hyperlink containing one or more of the token string, an image associated with the amount of the payment request, and text to be transmitted via the instant messaging service.  This payload is transmitted to the instant messaging application of the payor’s mobile device following the request for transfer to the recipient.

11. The request process can use a third-party application on the mobile device.  The third-party application is associated with the PPS.  In use, the payor’s mobile device has a user interface that allows the payor to execute the third-party application on their device, allowing them to input information in relation to the payment request.  The device transmits the payment request and identification of the payor to the PPS and receives back from the PPS a payload comprising a hyperlink containing a token string, an image based on the amount of payment request, and/or text instructions for the payment request.  The payor’s mobile device transmits this payload in an instant message to the recipient as the payload may not include information regarding the recipient.

12. Having received the message from the payor containing the payload, the recipient activates the payload by clicking on the hyperlink that contains the token contained within the payload.  This causes the recipient’s mobile device to transmit instructions to the PPS to release funds from the escrow account to a designated financial institution account system.  The PPS confirms the activation of the payload and the amount of the payment in a database of the PPS, and then the PPS facilitates the transaction by releasing the funds to the designated financial institution account system associated with the recipient.

13. The overall process followed to facilitate payment is illustrated in figure 2:

14. Furthermore, Figure 3 sets out the process followed by the payor’s device to generate and transmit the payload:

    These figures are generally self-explanatory. 

15. An embodiment of a system to carry out the process is shown in Figure 1.  The description notes that Figure 1 shows a two-party scheme where a payor sends payment to a single recipient, while also noting (but not describing) that:

    “Other embodiments of this disclosure may similarly function with different schemes involving more than two parties.”[4]

    [4] Ibid at [0015]

16. Figure 1 is:

17. In the system, the payor’s mobile device 101 is able to communicate (111) with the recipient’s mobile device 102 via the mobile device network 111, and communicates with the PPS via PPS network 110.  The PPS 103 contains a server 104, an Application Programming Interface (API) 106 and one or more databases 107a–107n.  Server 104 may use API 106 to communicate with the mobile devices belonging to the payor or the recipient over network 110.  Server 105 is a system of record server associated with a financial institute through either being hosted by the financial institute or by a third party that provides a service to the financial institute.  Server 104 receives transmissions regarding payment requests that occur between the payor’s mobile device 101, the recipient’s mobile device 102 and system of record server 105.  Upon receiving a payment request from the payor and generating a payload, server 104 may forward the transaction to system of record server 105, or may directly contact the financial institute so as to facilitate the payment request and transaction.

18. System of record server 105 maintains information regarding the balance of an account of the payor and/or the recipient at the financial institute.  Server 104 forwards information associated with a payment request to system of record server 105, which forwards it to the financial institute.  The financial institute generates an authorisation response confirming that the payor or recipient may complete the payment transaction and forwards it to the system of record server 105, and eventually to the server 104.  Alternatively, the server 104 may create its own authorisation, thereby assuming the risk that an account holder does not have sufficient funds to fund a transaction, until the system of record server 105 authorizes the transaction.

19. When the payor wishes to make a payment, the mobile device server 109 generates instructions to the payor’s mobile device 101 to provide a user interface that presents a screen to receive commands to transmit an instant message to a message service server and generate a payment request.  The interface can display a portion that allows the payor to access a third-party application.  This application could be the PPS API 106 and sends information regarding payment (e.g. payor information, amount, payload images) to the PPS server 104, which then generates messages with a payload with a hyperlinked token string.  In the embodiment, information regarding the recipient does not need to be sent to the PPS server.  The PPS might not receive any information regarding the recipient until the payload is activated and accessed by the recipient mobile device 102.

20. Having created it, the payload is transmitted to the payor’s mobile device 101 and the mobile device server 109 instructs the mobile device to create a message to the recipient which contains the received payload.  The payor’s mobile device 101, utilising network 111, communicates the payment request and other relevant information to the recipient’s mobile device 102 via an instant messaging application.  The mobile device network can treat the payload being delivered as a black box whose contents are unknown and the security procedures and protocols native to the mobile device network could be relied upon as a fraud protection method.

21. Having received the message, the recipient 102 “activates” the payload.  The specification states that:

    “A non-limiting example of activating a payload may be tapping or clicking the payload, activating the hyperlink, or visiting a Uniform Resource Locator (“URL”) embedded within the payload.”[5]

    [5] Ibid at [0031]

22. Following activation, the PPS server 104 is notified and receives an instruction to increment an account associated with recipient 102.  The PPS may not have any information regarding the recipient until the payload is accessed and activated by the recipient mobile device.  If, upon searching its database, the PPS server 104 does not find any information associated with recipient, the recipient may be prompted to update their financial information associated with the PPS API 106.  Upon updating, the PPS server increments an account associated with recipient and decrements the escrow account.  The PPS server may also send a confirmation to payor’s mobile.

23. It is worthwhile noting that the level of technical detail in the specification rises no higher than what I have presented above.  Figure 1 is a high-level schematic diagram with necessary pieces to implement a method.  Elements are mentioned in very broad terms and exemplified by entirely generic examples of that element.  The described mode of operation uses terms such as “generate”, “determine”, “receive”, “utilise”, and the like.  The techniques applied are mentioned by name only with little to no explanation of what they are or do.  The actual implementation is left entirely up to the reader.  There is no detail provided as to the form of the API, the communication processes or the process involved in the creation of the payload.  It is reasonable to conclude that the implementation of the various steps of the process is well within the normal skill of the person skilled in the art and involves the use of well-known computer components operating in their well-defined ways.

    Invention as claimed

24. The specification, as proposed to be amended, ends with 18 claims.  The entire claim set is set out in the Annex to this decision.  Claim 1 is directed to a method, claim 7 is directed to a non-transitory machine-readable storage medium following the same arrangement of features as claim 1 and claim 13 is directed to a system following the same arrangement of features as claim 1.  Given the essentially identical form of claims 1, 7 and 13, within this decision any comment that I make with respect to any independent claim should be construed as a comment with respect to the other independent claims as well, unless I specifically state otherwise.

25. I will set out claim 1 in full:

    “1       A method comprising:

    receiving, by a payment server and from a messaging application executing on a first mobile device operated by a first user, a request to initiate a payment transaction from a payment application executing on the first mobile device of the first user, wherein the request to initiate a payment transaction comprises a payment amount and a first user identifier associated with the first user, wherein the request to initiate a payment transaction does not identify a recipient of the payment transaction;

    identifying, by the payment server and in a data store maintained by the payment server, a financial account associated with the first user based on the first user identifier;

    facilitating, by the payment server and in the data store, a first adjustment to a balance associated with the financial account of the first user based on the payment amount;

    incrementing, by the payment server, a balance of an escrow account associated with the payment server based on payment amount;

    generating, by the payment server, a hyperlink associated with the first adjustment;

    transmitting, by the payment server, a payload comprising the hyperlink to the first mobile device, wherein the payload is configured to be transmitted from the first mobile device to a second mobile device as part of a request to transmit a payment message, via a message service server;

    wherein the request to transmit the payment message comprises the payment message and a second user identifier, wherein the payment message comprises the payload, and wherein the payload does not comprise the second user identifier;

    receiving, by the payment server from the second mobile device, subsequent to the second mobile device receiving the payment message from the first mobile device via the message service server, instructions to decrement the escrow account and increment an account associated with the second user; and

    wherein the payload is further configured such that activation of the payload at the second mobile device causes the second mobile device to transmit the instructions, and wherein activating the payload comprises activating the hyperlink.”

26. In claim 7, the non-transitory computer-readable storage medium is defined as storing instructions that, when executed, will cause a computing system to perform the method of claim 1.  For system claim 13, the hardware claimed for the system is minimal.  The system is defined as having a payment server containing memory and a processor configured for carrying out the method that is claimed in claim 1.

27. Although I note that the messaging application is not necessarily an instant messaging application described, I do not consider that this claim is inconsistent with the description.

    Examination

28. In the first report of 13 September 2021 the examiner raised lack of inventive step and lack of clarity against claims that had slight differences in wording to those presently before me.  The inventive step objection was taken in light of the combined disclosures of US 2016/0132863 (D1) and US 8751379 (D2).  The examiner stated that D1 disclosed the claimed features with the exception of facilitating an adjustment by the payment amount of a balance of a financial account of the recipient when the recipient interacted with the link within the message they received via their messaging application.  The examiner stated that such a feature was disclosed in D2 and that the person skilled in the art (PSA) would combine the disclosures of each of documents D1 and D2 to address the problem, thereby arriving at the claimed solution.

29. The applicant responded on 12 January 2022 with arguments and amendments to the description and claims.  The amendment to the claims consisted of clarifying that the link in the message sent to the recipient was a hyperlink.  This addressed the examiner’s clarity objection in their first report.  With respect to the inventive step objection, the applicant argued that:

    (i)the PSA would not be motivated to combine D1 and D2; and

    (ii)even if that combination was made, the PSA would not arrive at the claimed method. 

1. With respect to (ii), the applicant submitted that the link described in D2 was to the website of the recipient’s financial institution, while the present invention did not require the recipient to navigate to any further websites to confirm the transaction.  The recipient’s financial account was adjusted accordingly once the recipient had interacted with the hyperlink. 

2. The examiner considered that the amended claims were unclear and issued a second adverse report on 9 February 2022, noting that there seemed to be no relationship between the hyperlink received by the recipient and the adjustment to the payor’s account.  The examiner considered this a substantial clarity issue and reserved their opinion on the novelty and inventive step of the claims.

3. The applicant responded on 12 April 2022 with amendments to the claims, but then requested that these amendments not be considered and filed a further response with amendments to the claims on 20 May 2022.  In their response the applicant stated that the amendments clarified that the hyperlink received by the payor’s mobile device from the PPS is sent from that mobile device to the recipient’s mobile device, and is the link that the recipient interacts with to send an indication of that interaction to the PPS.

4. The examiner continued to have objections and issued a third adverse report.  The objections in that report are as follows (bolding, italics, underlining and strikethroughs in original):

   “Patentable subject matter

   Claims 1-20 does not define a manner of manufacture within the meaning of Section 18(1)(a) of the Patents Act 1990. From reading your application as a whole the substance of the alleged invention is to a payment transaction scheme performed by a first and second mobile device via a messaging application wherein a hyperlink associated with a transaction is transmitted to both device by a payment server upon adjustment of the first user’s account.  This is not patentable subject matter.

   The claims define the use of mobile computing devices for performing steps of the claims.  However, the contribution of the claimed invention is neither in an improvement to the operation of the computer nor in its application in the working of the scheme.  Consequently, as per Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150 and Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 the alleged invention is not a manner of manufacture.

   The subject matter of the present application does not become patentable merely because it is operated in whole or part using a computer system in the normal or an unspecified way.  Rather some improvement in the operation of the computer or the way the computer carries out the scheme is required.

   I apologize for any inconvenience caused by not raising this objection at an earlier examination report.  The amendments submitted on 20 May 2022 further clarified the substance of the invention and is found to be not to a patentable subject matter.

   Section 40 (support, disclosure, clarity, lack of unity)

   Claims 1, 8 and 15 are not clear because it defines the feature, “subsequent to the first mobile device causing a payload containing the hyperlink to be sent to a second mobile device”, which appears to have a step is [sic] missing prior to the first mobile device causing a payload containing the hyperlink to be sent to a second mobile device.

   I have purposively construed this feature to read “subsequent to interacting with the hyperlink, the first mobile device causes a payload containing the hyperlink to be sent to a second mobile device” based on teaching from the specification particularly fig 4 and paragraph [0045].

   Novelty and inventive step

   Claim 1 lacks an inventive step in light of D1.

   D1 discloses, a method comprising: receiving, by a payment server and from a messaging application executing on a first mobile device operated by a first user, a request to initiate a payment transaction from a payment application executing on the first mobile device of the first user, wherein the request comprises a payment amount and an identifier associated with the first user (abstract, paragraph [0137]; fig 5: step 502, 504);

   identifying, by the payment server and in a data store maintained by the payment server, a financial account associated with the first user based on the identifier; facilitating, by the payment server and in the data store, a first adjustment to a balance associated with the financial account of the first user based on the payment amount (paragraph [0137]) fig 5: 508, 510);

   generating, by the payment server, a hyperlink notification associated with the first adjustment (fig 5: 524);

   transmitting, by the payment server, the hyperlink notification to the first mobile device (fig 5: 528);

   and subsequent to interacting with the hyperlink, the first mobile device causing a payload containing the hyperlink notification (paragraph [0139], [0143], fig 5: 516, 520, fig 6: 604; wherein the payload is construed as per paragraph [0027] of the description as, an electronic representation of the payment request) to be sent to a second mobile device (paragraph [0138]; fig 5: 518),

   and upon receiving, by the payment server and from a second user operating a messaging application executing on the second mobile device of the second user, an indication that the second user has interacted with the hyperlink within the messaging application (paragraph [0139]; selecting associated URL),

   facilitating a second adjustment of a balance of a financial account of the second user according to the payment amount (paragraph [0140]; wherein payee account has been credited).

   Claim 1 is distinguished from D1 in that, claim 1 defines the notification as a hyperlink and the step of communicating with the first device prior to the second device.

   However, these features are considered mere matters of design choice.  The person skilled in the art would recognize to implement a notification comprising a hyperlink to the first user and the order of communicating said notification to the first and second user is merely a design consideration.

   A similar reasoning as per claim 1 is applied to claims 8 and 15.

   Furthermore, appended claims 2-7, 9-14 and 15-20 add only features that are either disclosed in D1 or are considered mere matters of design choices and which therefore cannot contribute to providing a patentable invention.

   For example, additional feature defined in claim 2, 9 and 16 is disclosed in paragraphs [0059], [0139], [0143].”

5. Obviously, the claims before me (see the Annex) differ somewhat from what was before the examiner when they issued these objections.  Nevertheless, I will address the proposed claims under the headings of the examiner’s report.

   Clarity

   The law

6. The claims must be clear and succinct according to s40(3) of the Act.  The requirement for the claims to be clear does not mean that terms used in claims must be precise or absolute, as noted in Flexible Steel Lacing Company v Beltreco Ltd:

   “Lack of precise definition in claims is not fatal to their validity, so long as they provide a workable standard suitable to the intended use … The consideration is whether, on any reasonable view, the claim has meaning … In determining this, the expressions in question must be understood in a practical, common sense manner … Absurd constructions should be avoided … and mere technicalities should not defeat the grant of protection …”[6]

   [6] [2000] FCA 890 at [81]; (2001) 49 IPR 331 at 349 (and cited with approval in Austal Ships Sales Pty Ltd v Stena Rederi Aktiebolag [2008] FCAFC 121; (2008) 77 IPR 229) (Austal Ships)

7. In particular, the claims are considered to provide a “workable standard” if a third party could, without difficulty, determine whether an act falls within the scope for the claim; see Monsanto Company v Commissioner of Patents:

   “There will, I think, in the present case be no difficulty in a third party ascertaining whether or not what he proposes to do falls within the ambit of the claim … For these reasons I do not regard the use of the adjective “substantial” as giving rise to any uncertainty.”[7]

   [7] (1974) 48 ALJR 59 (Monsanto) at 60-61

8. Nevertheless, where terms in claims are unclear, recourse may be made to the specification to resolve the ambiguity; see Interlego AG v Toltoys Pty Ltd:

   “If the expression is not clear it is then permissible to resort to the body of the specification to define or clarify the meaning of words used in the claim without infringing the rule that clear and unambiguous words in the claim cannot be varied or qualified by reference to the body of the specification …” [8]

   [8] [1973] HCA 1 at [14]

9. This was also reiterated by the Full Federal Court in H Lundbeck A/S v Alphapharm Pty Ltd when they stated, when discussing the approach to construing claims:

   “… the words in a claim should be read through the eyes of the skilled addressee in the context in which they appear.  Words used in a specification, including the claims, are to be given the meaning which the person skilled in the art would attach to them, having regard to his or her own general knowledge and to what is disclosed in the body of the specification … It is not permissible to read into a claim an additional integer or limitation to vary or qualify the claim by reference to the body of the specification … However, terms in the claim which are unclear may be defined or clarified by reference to the body of the specification ...”[9] (my emphasis)

   [9] [2009] FCAFC 70 at [118]-[120]

   Applicant’s submissions

10. The applicant referred to the fact that the claims had been amended to include several specific steps instead of the single step previously claimed.  The applicant submitted that the claims were now clear, and that the objection had been overcome.

    Consideration

    Examiner’s clarity objection

11. I agree with the applicant.  The claims before me no longer have the clarity problem that the examiner identified.  The passage objected to by the examiner has been replaced with other words.  I will, however, observe that the examiner’s clarity objection could not have been sustained against the now-deleted passage.  While I understand the examiner’s confusion given the somewhat unusual wording that had been used in the claims, I would have found that previous claims 1, 8 and 15 provided a workable standard.

    Clarity issues with claims as proposed to be amended

12. Notwithstanding this finding, I have concerns about a lack of clarity regarding claim 3 of the amended claim set.  Claim 3 (which is appended to either of claims 1 or 2) defines:

    “…identifying, by the payment server and based on information provided by the messaging service, a financial account associated with the second user based on information provided by the messaging service application”. (bolding and italics added)

    There are numerous issues here.

13. Firstly, neither claim 1 nor claim 2 (which only further characterises the hyperlink) define “a messaging service”.  Claim 1 does define “a messaging application executing on a first mobile device”.  It might be said that “the messaging service” of claim 3 is the messaging application which executes of the first mobile device.  However, claim 3 requires that the messaging service provide information that allows the payment server to identify “a financial account associated with the [recipient]”, and claim 1 is quite clear that information about the recipient is not supplied by the messaging application.  Claim 3 seems to be defining a fundamentally different concept which is inconsistent with claim 1.

14. Secondly, taking “the messaging service” of claim 3 to refer to “a message service server” of claim 1 encounters the same issue.  While the message service server of claim 1 appears to be used to send the payment message to the recipient, it does not appear to be used to contact the payment server and, therefore, provide information that can identify the recipient’s financial account.  This is inconsistent with claim 1.

15. Thirdly, even assuming that there can be a resolution as to what application/server is being referred to in claim 3, a further clarity issue exists.  This issue arises because claim 3 defines that the financial account of the recipient is identified “based on information provided by the messaging service” and “based on information provided by the messaging service application”.  It is not clear what is used to identify the recipient’s financial account. 

16. Recourse to the description is of no assistance.  The description has the following passages pertaining to identifying a financial account associated with the second user:

    “…The PPS server may also receive identification information from the recipient’s mobile device and identify the recipient using existing data stored in the PPS databases.  If the PPS server does not have any existing stored financial information regarding recipient’s accounts, the PPS server may generate a message to the recipient, inquiring such information.  For example, the PPS server may ask the recipient to insert an account for the payment to be transmitted to.”[10]

    “… In some implementations, the payor’s mobile device may transmit a recipient identifier to the PPS server.  The recipient identifier may contain information regarding the recipient’s mobile device, the payor’s mobile device, recipient’s account, and/or other information regarding the payment request.”[11]

    To my mind, neither of these passages clarifies which is used.  They cover different scenarios, neither of which appear to match what is claimed.

    [10] Specification at [0034]

    [11] Ibid at [0043]

17. It follows that claim 3, being fundamentally inconsistent with claim 1, is not clear.

    Dependent claims 9 and 15 define the same features as claim 3.  Therefore, given the close correspondence of the independent claims, it follows that claims 9 and 15 are also inconsistent with claims 7 and 13, respectively.  Therefore, claims 9 and 15 are also not clear.

    Inventive step

18. The test for obviousness is whether it would have been a matter of routine to proceed to the claimed invention:

    “The test is whether the hypothetical addressee faced with the same problem would have taken as a matter of routine whatever steps might have led from the prior art to the invention, whether they be the steps of the inventor or not.”[12]

    [12] (Wellcome Foundation Ltd v VR Laboratories (Aust) Pty Ltd [1981] HCA 12 at [45]

19. The High Court in Aktiebolaget Hässle v Alphapharm Pty Ltd[13] also approved the approach taken in Olin Mathieson Chemical Corporation v Biorex Laboratories Ltd in which Graham J had posed the reformulated Cripp’s question:

    “Would the notional research group at the relevant date in all the circumstances directly be led as a matter of course to try [the claimed invention] in the expectation that it might well produce a useful [desired result]?”[14]

    [13] [2002] HCA 59 at [51] – [53]

    [14] [1970] RPC 157 at 187

20. In the third report, the examiner raised an objection that the claims lacked an inventive step in light of US 2016/0132863 (D1).  It is appropriate at this stage to discuss what D1 discloses.

    US 2016/0132863 (D1)

21. D1 is directed to a system and method for a payment process through the composition by the payor of a text message.  Broadly, in the disclosed invention, a message, such as a SMS message, containing identifying information of the recipient and an amount to be paid is sent from the payor to a payment processing system, which debits an account of the payor, credits an account of the payee and may notify either or both of the parties that the money has been transferred.

22. It is also envisaged that the method can include placing the payment in escrow and crediting the account of the payee only after escrow conditions have cleared.  That condition could be as simple as the payor sending a command to the payment processing system to release the funds.

23. Another embodiment described sees the payor communicating their identity and a payment amount with a device (e.g. a vending machine) via a non-messaging pathway (e.g. Bluetooth), with the device then communicating with the central payment system.  This approach sees the cash transfer occurring without needing the payor to send a message to the central payment system, thereby avoiding any charges that the payor might otherwise incur for sending a text message.

24. Figure 1B of D1 shows one example of the flow of messages in the payment system:

25. In Figure 1B payor 14 transmits a message A to a central system (of which the central payment system 12 is a part) to achieve the transfer of funds from the payor to the recipient 16.  The message can be part of a simple text message having a predetermined format.  An example format given in D1 is:

    “"gpay"<optional space> <recipient phone or other ID> <mandatory space> <dollar amount>”,

    where “gpay” in the example indicates to the central system (which may receive other text messages related to requests for other information such as driving directions, or search results) that the message is intended for the central payment system 12.  The message could also include information such as the good or service being purchased, the vendor, etc.

26. When the message is received, it is parsed apart to extract information.  The information is used to identify an account 18 of the payor 14 to be debited by an amount (which may be just the “dollar amount” or that amount plus additional processing fees, taxes, penalty fees, etc), and the dollar amount is sent B to the recipient’s account 20 to be credited.  Once the central payment system 12 has carried out the transaction, it may send notification messages C1 C2 to the parties indicating that a certain amount of funds have been added to the recipient’s account.  The message C1 to the recipient 16 does not have to include information identifying the payor to the recipient over and above that which is necessary for the recipient to confirm the transfer, and could be as simple as conveying the fact that money has been added to the recipient’s account. 

27. The architecture of the system of D1 is shown in Figure 2:

28. The operation of the system 200 would be self-evident to the person skilled in the art.  The payment processor 202 sends and receives messages to and from various devices 222 via various communication towers 220 and mobile switching centres 218.  Financial services processor 226 is accessed through a financial gateway or router 224.  The financial services processor 226 can comprise servers or mainframes used by a financial services organisation to carry out on-line electronic transactions, such as wire transfers and the like.  Interface 214, which may be comprised of one or more web servers and/or text message servers, can be provided with a parser for differentiating messages relating to payment processing from messages relating to other services provided by the larger system of which the payment processor 202 is a part, and properly routing payment messages or information from such payment messages.

29. Once payment messages are forwarded, the authenticator 204 checks whether the information is accurate using information from the database of user information 212, and whether the request can be acted upon.  For example, the user information 212 might have a field or fields for a user that indicate(s) that certain transactions with the user are prohibited (e.g., the user may receive money but may not spend it).  If authentication is successful, the transaction is passed to the transaction module 206 which, drawing upon transaction rules 230 (e.g. maximum transfer amount, maximum daily transactions, etc) is responsible for carrying out a funds transfer, and for confirming the transaction with the users.  The transaction module carries out changes in the ledger module 208.  The ledger module 208, drawing on user information, (e.g. user identification numbers) locates the payor and recipient accounts to permit the transfer.  Once the transfer is done, the transaction module 206 can cause confirmatory messages to be sent to the user devices 222.  The messages may be generated by components in interface 214, such as an SMS server, controlled by, and using information passed from, the transaction module 206. 

1. Figure 3B shows a detailed operation of this process:

   Not much more needs to be said other than it is clear that the system requires the recipient to be identified in some manner in the original message.

2. It is also worth noting the screens/messages that are displayed.  These are shown in figure 6 of D1:

3. Graphical interface 602 shows a form that may be generated by a program operating on a mobile device of a payor.  The interface allows for entry of information the boxes in a graphical interface, and the program can assemble the entered information into an SMS text message.  As shown, the payor is prompted to enter an identifier for a recipient of a payment, along with an amount of the payment.

4. Once the payment is made, the recipient receives a message 604.  The text message tells the recipient that payment has been received, the amount of the payment, and the payor (although, as noted above, this information may have been omitted to make the transaction more anonymous).  In addition, the message includes text instructing the user how to perform follow-up actions, such as pressing a * key or a # key.  D1 states that, alternatively, the message may include a URL or may instruct the recipient with other information.  D1 indicates[15] that undertaking this follow-up action could allow the recipient to confirm that the transaction occurred.  It is important to note that message is received by the recipient once the transfer of funds has been completed. 

   [15] D1 at [0032]

   Applicant’s submissions

5. The applicant submitted that D1 did not disclose four specific features of the amended independent claims:

   (i)the payment request does not identify a recipient;

   (ii)the step of transmitting a payload containing a hyperlink to the payor’s mobile device, where the payload can be transmitted from the payor’s mobile device to the recipient’s mobile device as part of a payment message, where the hyperlink is associated with the payment;

   (iii)that the payment message from the payor’s mobile device to the recipient’s mobile device (see (ii) above) comprises the payment message and a recipient’s identifier, where the payment message comprises the payload, and the payload does not include the recipient’s identifier; and

   (iv)a payment server receiving from the recipient’s mobile device instructions to decrement an escrow account by the payment amount and to increment an account associated with the recipient by the payment amount.

   Consideration

6. I agree with the applicant that these features are not disclosed by D1.  With respect to feature (i), as is clear from my discussion of D1 above, the text message sent by the payor to the payment server of D1 specifically identifies the recipient.  As to features (ii) and (iii), D1 does not disclose anything equivalent to the payload defined in the claims.  As such, D1 does not disclose a payload having the capability of being sent by the payor to the recipient.  Moreover, D1 teaches that the transfer payment is complete without requiring any action by the recipient.  Consequently, with respect to feature (iv), D1 does not disclose the payment server of D1 receiving instructions from the recipient’s device to decrement an escrow account by the payment amount and to increment their account.

7. The examiner stated in their report that D1 did not disclose:

   “the notification as a hyperlink and the step of communicating with the first device prior to the second device”.

   The examiner then stated:

   “However, these features are considered mere matters of design choice.  The person skilled in the art would recognize to implement a notification comprising a hyperlink to the first user and the order of communicating said notification to the first and second user is merely a design consideration.”

8. Putting to one side the fact that the claims have been amended and there are now more than these just these two features missing from D1, the system of D1 does not have the payment server receiving a communication from the recipient and then undertaking an adjustment of the recipient’s account balance.  Certainly, D1 discloses that the recipient might interact with a URL, but that does result in any adjustment.  The adjustment to the recipient’s account balance has already occurred by the time the recipient receives a message containing the URL.  As I noted above, this is said to be an option available to the recipient to confirm that the transaction occurred.

9. Moreover, I do not think the claimed step could be said to be arrived as a matter of simple design choice by the person skilled in the art when seeking to implement the system of D1.  As was stated by the applicant is their submissions:

   “… the systems and methods of D1 act entirely independently of the [recipient’s] device 16.  So that a user, interacting with the [payor’s] device 14, can effectuate the transfer of funds entirely without the input of a [recipient], who would notionally be interacting with the [recipient’s] device.  The only role that the [recipient] would have, outside of the creation of an account in response to an attempted transaction, would be to passively receive notification C1, notifying them that they have received funds.”

10. What is claimed by the present application is fundamentally different.  D1 actively teaches away from the communication method that is claimed.

    The inventive step objection in light of D1 is not sustainable.

    Manner of manufacture

    The law

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

12. In National Research Development Corporation v Commissioner of Patents[16], the High Court provided a statement of the law regarding manner of manufacture:

    “… 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”.[17]

    [16] [1959] HCA 67, (1959) 102 CLR 252 (“NRDC”)

    [17] NRDC at page 275

13. The High Court though was not laying down a precise formulation that can be applied unthinkingly.  In D’Arcy v Myriad Genetics Inc the Court stated:

    “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.”[18]

    [18] [2015] HCA 35 (“Myriad”) at [23]

14. That case-by-case approach must have regard to the substance of the claimed invention, not simply the form of the claim.  The point was made succinctly in the Myriad case by Gageler and Nettle JJ:

    “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.”[19]

    [19] Myriad at [144]

15. To further guide the determination of patentable subject matter in the context of computer implemented inventions, a range of principles have been developed by the Full Federal Court in Commissioner of Patents v RPL Central Pty Ltd[20], Research Affiliates LLC v Commissioner of Patents[21], Encompass Corporation Pty Ltd v InfoTrack Pty Ltd[22], and Commissioner of Patents v Rokt Pte Ltd[23].

    [20] [2015] FCAFC 177 (“RPL Central”)

    [21] [2014] FCAFC 150 (“Research Affiliates”)

    [22] [2019] FCAFC 161 (“Encompass”)

    [23] [2020] FCAFC 86 (“Rokt 2”)

16. Thus, the assessment as to patentable subject matter in this context requires a consideration of the substance of the invention.  The principles of law that apply to the present matter are themselves substantially uncontroversial, although, on a case-by-case basis, they can be difficult to apply at times.  The principles of law that apply to the present matter in the context of computer implementation appear to be well reflected in that summarised and generally accepted by Robertson J in Rokt Pte Ltd v Commissioner of Patents[24] as follows:

    [24] [2018] FCA 1988 (“Rokt 1”)

    “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].”[25]

    [25] Rokt 1 at [189]

17. The Full Federal Court decision in Rokt2 confirmed and applied these principles.  It appears a sensible approach, consistent with the above principles for considering patentability, to consider whether the invention constitutes a technical solution and/or solves a technical problem.

18. This approach remains relevant in view of subsequent decisions.  In Commissioner of Patents v Aristocrat Technologies Pty Limited[26], it was found that a game implemented on an electronic gaming machine was not patentable.  After first identifying the claimed invention as involving a mere game which was unpatentable, the Full Court asked whether the claimed invention was a computer-implemented invention before determining that for the claims to be patentable, there needed to be “an advance in computer technology”.

    [26] [2021] FCAFC 202 (Aristocrat ‘21)

19. On appeal to the High Court, in Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents[27] the Court was evenly split, and via section 23(2)(a) of the Judiciary Act1903 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 confirmed the decisions of the Full Federal Court in RPL Central, Research Affiliates, Encompass, and Rokt 2 were correct. The High Court at [77] also discussed the idea that an “adaptation or alteration of, or an addition to, technology otherwise well-known in the common general knowledge to accommodate the exigencies of a new idea or plan or game” would give rise to patentable subject matter. Such an idea appears consistent with the principles articulated in Rokt 1 which seeks patentability in the form of something more than, for example, merely generic computer implementation; generally being steps which are foreign to the normal use of computers and where the computer is more than merely the intermediary, adding substance to the idea.

    [27] [2022] HCA 29 (Aristocrat ‘22)

    Applicant’s submissions

20. The applicant submitted that the problem to be solved was how to provide an improved system/method for processing a transaction.  They stated that the proposed amended claims solved this problem by providing a system/method that used a generated hyperlink as an identifier of the transaction.  The contention was that this allowed the transaction to be conducted more securely and efficiently.  In the solution, the payment server generated the payload and sent the payload to the first mobile device, with the payload being configured to be sent from the first mobile device to the second mobile device for activation to complete the transaction, without the payload requiring or comprising the second user identifier.

21. The applicant submitted that the substance of the invention related to an improved method/system for processing a transaction using a generated hyperlink as both an identifier of the transaction, and as a trigger to process the transaction.  As such, the present case did not relate to a business method but, instead, solved a technical problem outside of a computer.  As such, they contended that the decisions with respect to computer-implemented schemes (such as Research Affiliates and RPL Central) would not be of assistance in determining patentability of the present invention.  The applicant also submitted that the subject matter of the present application is closer to that of the invention the subject of the Commissioner’s decision in Jagwood Pty Ltd[28] and that the claimed invention met the manner of manufacture threshold set out in Aristocrat ‘22.

    [28] [2020] APO 38 (Jagwood)

22. The applicant also stated:

    “The improved method/system for processing transactions is achieved by the present invention’s alleviation of three key problems, these problems being the privacy problem, the accuracy problem, and the efficiency problem.  The privacy problem and accuracy problem are both at heart security problems that are associated with known transaction methods, while the efficiency problem is directed to the streamlined execution of transactions.”[29]

    Similarities with Jagwood

    [29] Written submissions at page 10

23. The applicant noted that the claims at issue in Jagwood “were directed to an application using a uniform resource identifier (URI) to link an electronic payment to a financial document”[30], (bolding in original) and that the allowable claims in Jagwood were comparable to the claims of the present application, as both improved the efficiency of the process of performing payment transactions by the use of a digital identifier, being a URI in Jagwood and the hyperlink in the present case.  The applicant submitted that the dual purpose of the present hyperlink of being the identifier and a trigger of a transaction, was analogous to the dual purpose of the URI in Jagwood of providing the location of a financial document and the payment reference in an electronic payment system.  They note that the delegate had stated that the URI provided a technical solution to identified problems.

    [30] Ibid at page 13

    Aristocrat ‘22

24. The applicant noted that Aristocrat ‘22 set out differing approaches when assessing manner of manufactured.  Notwithstanding this, the applicant submitted that, regardless of which test was followed, the claimed invention was for a manner of manufacture.

25. The applicant stated that:

    “Justices Kiefel, Gageler and Keane set out that if a claimed invention did not disclose an adaption or alteration of, or an addition to, apparatus well known in the common general knowledge to accommodate the exigencies of the new idea, it is not patent eligible.”[31]

    The applicant submitted that the claimed invention did involve such an adaptation, alteration or addition to a well-known apparatus; this being a configuring of the PPS to send a hyperlink to the payor’s device, which could then be sent, via any appropriate messaging application, to the recipient’s device for activation by the second user. 

    [31] Ibid at page 15

26. The applicant then stated that:

    “Justices Gordon, Edelman and Steward set out that the question to be asked is whether the subject matter is (i) an abstract idea which is manipulated on a computer; or (ii) an abstract idea which is implemented on a computer to produce an artificial state of affairs and a useful result; the latter being patent eligible.  They further clarified that the method of carrying out the idea need not be inventive or ingenious; the ingenuity may lie only in the idea, but when the idea is applied to produce an artificial state of affairs and a useful result, there will be a manner of manufacture.”[32]

    The applicant submitted that the invention produced an artificial state of affairs and a useful result as it provided an improved method and system for performing transactions.

    [32] Ibid at page 16

    Privacy problem

27. The applicant noted that people who transact are not always known to each other, but that, when it comes to transacting, sensitive data must be exchanged creating privacy concerns.  The applicant submitted that this privacy problem arose from:

    “… the technical limitations of known transaction methods; mainly that specific identifying information is required to ensure security of funds, and cannot be easily or readily circumvented by prior art solutions.”[33]

    [33] Ibid at page 10

28. The applicant submitted that the present invention addressed this by separating the act of initiating the transaction from the act of completing the transaction.  The applicant states that:

    “… the present invention solves the technical problem of privacy when conducting transactions by removing the need for a payor to identify a recipient when initiating a transaction, by using the hyperlink as both the identifier of the transaction, and as a trigger to process the transaction.”[34]

    [34] Ibid at page 11

29. The applicant also submitted that privacy is also addressed by having the payload containing the hyperlink being sent to the payor’s mobile device to forward to the recipient in whatever manner they might want.  This allows the transaction to be completed with minimal information exchange between the parties.

    Accuracy problem

30. The applicant submitted that:

    “… known methods of executing a transaction commonly require long numeric codes to be located by a recipient, communicated to a payor and then subsequently entered into a payment system, such as a banking application installed on a mobile device, to execute a transaction.”[35]

    [35] Ibid at page 11

1. In the applicant’s opinion, this would frequently lead to incorrect entry, possibly voiding transaction, or transferring funds to the wrong recipient.  The applicant submitted:

   “The use of long and random strings of numbers is a technical requirement of known transaction systems and methods, which at worst may not be avoided, or at best be replaced with another burden, such as an alphanumeric string, for example an email address, which share the same accuracy problems as account numbers.”[36]

   [36] Ibid at page 11

2. The applicant submits that this problem is overcome:

   “… by removing the requirement for a payor to include a payee identifier, such as an account number or an email address to instantiate a transaction.  This is achieved by using the hyperlink as both the identifier of the transaction, and as the trigger to process the transaction.  The hyperlink, sent by the payor via any suitable messaging application, comprises all the necessary components, including an identifier of the transaction, that are required to complete the transaction.”[37]

   [37] Ibid at page 12

   Efficiency problem

3. The applicant submitted that, in terms of carrying out a transaction, the steps that might have to be performed could be:

   (i)        retrieving payee identification information;

   (ii)       communicating (i.e. sending and receiving) payee identification information;

   (iii)      accessing a financial application, which may include a multi-stage log-in process;

   (iv)      initiating a transaction request;

   (v)entering the relevant transaction details, including the payee identification information and at least an amount to be transferred; and

   (vi)potentially several stages of confirming the transaction, including an initial confirmation, and a two-factor confirmation.

4. The applicant submitted that this complex and burdensome task could easily disincentivise a payor from carrying out the transaction.  The applicant submitted that using the hyperlink as both the identifier of the transaction, and as the trigger to process the transaction, freed the payee having to communicate their identification information to the payor, and freed the payor from having to accurately enter the received information into a financial application, and confirming the transaction.  The applicant submitted that, accordingly, the present invention required fewer steps to be taken by both the payor and the payee to complete a transaction.  It was also alleged that, by using the hyperlink as both the identifier and the trigger of the transaction, the invention eliminated the need for the transaction participants to exit out of the messaging application to interact with additional applications, such as a banking platform, or a third-party payment platform, to process a transaction.

   Consideration

   Similarities with Jagwood

5. As noted above, in their submissions the applicant provided an analysis of similarities between the claimed invention and the inventions at play in Jagwood, with both involving a hyperlink in some way.  While it might be said that there are similarities with the invention in Jagwood, I do not find the applicant’s reference to the decision of assistance.  This approach would appear to be suggesting that an invention should be a manner of manufacture because a similar invention was found to be a manner of manufacture.  In this regard, the observation of the Delegate in Accenture Global Services Limited is of relevance:

   “As far as the Applicant may be suggesting some reliance on the outcome of prior decisions, such as eBay, it is perhaps worth noting that the decisions issued by the Australian Patent Office do not form part of the case law and, as such, do not establish any legal principles or precedent.  In each individual decision, the Deputy Commissioner or a delegate of the Commissioner applies the principles developed by the Courts to the facts of the case to reach a conclusion.  While I acknowledge that, in eBay, the Delegate reached the conclusion that, in that particular case, the invention was a manner of manufacture, I cannot see how this could help the Applicant given that each case is decided on its own merits in light of the legal principles developed by the Courts.”[38]

   [38] [2023] APO 10 at [104]

6. As such, it is not the role of the Commissioner to distinguish the invention before her from any invention that was said to be a manner of manufacture in another of her decisions.  Such an approach seeks to use decisions of the Commissioner to effectively supplant the principles developed by the Courts.  To further clarify, I do not consider that providing reasoning with respect to the instant invention should necessarily require discussing the invention considered in Jagwood.

   Aristocrat ‘22

7. I note the applicant’s submission that the claimed invention involved an adaptation, alteration or addition to a well-known apparatus.  I do not take the applicant as saying that any “adaption or alteration of, or an addition to” a machine or device results in a manner of manufacture.  Clearly this would be inconsistent with Aristocrat ‘22 which, in my opinion, does not create any new principles over and above those of the Federal Court decisions that the High Court explicitly agreed with.  If it were the case that any adaptation was sufficient, then the inventions of Research Affiliates, RPL Central, Encompass and Rokt 2 would have been found to be a manner of manufacture since they involve the modification of standard computers to do novel things.  Clearly, adaptions, alterations, or additions to systems must be of the right character to confer patentability.  The applicant indicated that their adaptation was a configuring of the PPS to send a hyperlink to the payor’s device, which could then be sent, via any appropriate messaging application, to the recipient’s device for activation by the second user, with the hyperlink being an identifier of the transaction, and a trigger or the completion of the transaction. 

8. I also note the applicant’s submissions that the invention produced an artificial state of affairs and a useful result as it provided an improved method and system for performing transactions.  While it could be said that the “state of affairs” of the present invention is artificial, and that the result may well have use to consumers, the presence of these by themselves is not necessarily sufficient to confer patentability.  Again, the same statements with respect to artificial states and useful result could be made with respect of the inventions in Research Affiliates, RPL Central, Encompass and Rokt 2.  The character of these factors is what is important.

   Privacy problem

9. As an initial point I note that the specification does not mention the word “privacy” at all.  As such, it is difficult to get an understanding of the “technical limitations” of the “prior art solutions” that the applicant refers to in their submission (while providing no detail of these solutions).  While privacy may be (and very likely is) a consideration in a transaction, it is difficult to see it as being part of the substance of the invention.  Nevertheless, whether the specification mentions privacy or not, I do not see the claimed invention as solving the privacy problem in any technical way.

10. While it may be the case that the payor does not supply this information to the PPS, the fact remains that such information must be supplied for the transaction to be carried out.  In the claimed invention, whatever information necessary to identify the recipient to allow the PPS to direct the payment amount to the recipient’s bank account is supplied by the recipient.  Clearly this addresses some privacy concerns.  However, it is not addressed in a technical way.  Instead, the issue of privacy is addressed by the administrative rule of having the relevant information supplied by two parties rather than just one.  The payor supplies information when initiating the transaction, and the recipient supplies the remaining necessary information when activating the payload.  In this regard, I take the payload to be analogous to the “I accept” button that appears in many well-known applications.  It is, in my opinion, not distinct from the common general knowledge and, as such, its presence does not alter the character of the invention. 

11. While it might be said that the present invention uses minimal identifiers from each party to carry out the transaction (although it is not clear from the specification that this is the case), the amount of information is not a technical advance.  It is simply a decision from an administrative perspective of how much data will be required from the parties.  I am not aware of any technical consideration that plays a part in this decision.

12. As an aside, noting that the applicant gave as an example of an unacceptable piece of information the email addresses of the participants to a transaction[39], I observe that the invention does not exclude email as a “messaging application” that could be used for the payor to send the recipient the payload.

    [39] Written submissions at page 10

    Accuracy problem

13. As with the privacy problem, the specification does not mention anything to do with “accuracy”.  Moreover, I do not understand how accuracy is an inherently technical issue in the present invention.  Indeed, as noted above, the applicant’s submissions point to a party having difficulty in locating, and entering, account numbers, long numeric codes and/or alphanumeric strings.  These are not technical problems.  They are more aligned with cognitive issues.  Moreover, as with the privacy problem, and for similar reasons, I do not see the claimed invention as solving the accuracy problem in any technical way.

14. As with the privacy problem, regardless of whether the information is supplied by the payor, the fact remains the information must be supplied to the PPS for the transaction to be competed.  Whether that information is entered by one party, or by both parties to the transaction, does not avoid the accuracy problem.  Either party could still make a data entry mistake.  Moreover, the requirement that the information is not added by a single party, but by both parties to the transaction, is an administrative rule.  It is not a technical solution.  There is nothing in the specification that even hints at a technical problem here.  As I noted above, the level of technical detail in the specification is high-level schematic diagrams of necessary pieces to implement the method.  Elements are mentioned in very broad terms and exemplified by entirely generic examples of that element and the actual implementation is left entirely up to the reader. 

15. The provision of a hyperlink to enable the information to be sent to the PPS does not represent a technical solution to a technical problem.  As with the privacy problem, it is analogous to an “I accept” button.  Moreover, noting that the specification states that activating the payload could result in the recipient visiting a URL via a web browser, the payload is no different to any hyperlink that appears in any message or document as is notoriously well-known in many arts.  As such, its presence does not alter the character of the invention.

    Efficiency problem

16. To my mind, the applicant’s submissions on this point rely on an entirely hypothetical construct.  The process that is put forward as one which the present invention seeks to simplify by, for example, reducing the number of steps to take, is not described.  The applicant’s position is that the claimed process is more efficient over a hypothesised worse interface. 

17. Even accepting the hypothesised interface, each step that the applicant put forward would, in some form, have to be carried out for the transaction of the present invention to occur.  Recipient identification information needs to have been retrieved at some point and communicated to the PPS.  In the present invention, this is done by the recipient.  Otherwise, there is no way to determine which account the money from the payor is to be sent.  Furthermore, the present invention does not exclude the need for at least one of the parties to access a financial application, with a possible multi-stage log-in process.  The specification talks of visiting a URL, but it does not limit the URL to one which is not that of a financial institution.  Also, it goes without saying that there will always be a need to initiate a transaction request and specify the amount to be transferred.  Moreover, it is also clear that the present invention requires that payee identification information be entered at some point by the recipient and at least an amount to be transferred.  The present invention also does not prohibit any confirmation of the transaction from including potentially several stages of confirming the transaction (including an initial confirmation, and a two-factor confirmation).

18. The described arrangement of the steps for providing the necessary information and initiating transactions is not a technical arrangement.  It is administrative.  I cannot conclude that any efficiencies are gained.

    Conclusion

19. It follows that the invention as claimed in the independent claims is not a manner of manufacture.  It is, in substance, an administrative scheme for providing information to enable the completion of a monetary transaction 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.

20. For completeness, I note that this finding is not avoided by any of the dependent claims.  The contents (for want of a better word) of the hyperlink being associated with an escrow account (as per claims 2, 8 and 14), identification of the recipient’s financial account based on information (as per claim 3, 9 and 15), and requiring the recipient to visit a URL when they have activated the payload (as per claim 6, 12 and 18) are mere administrative options operating on the internet, which is a well-known, and well-understood, technical environment .  Moreover, the fact of the messaging application being either native or not native to the operating system of the payor’s mobile device (as per claims 4, 5, 10, 11, 16 and 17) is simply defining conventional technology of messaging applications, adding nothing to the substance of the invention.

    Conclusion

21. The clarity and inventive step objections raised by the examiner cannot be sustained in light of the amended claims.

    However, claims 3, 9 and 15, as proposed to be amended are not clear.

22. 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.  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 refuse the application.

    Greg Powell

    Delegate of the Commissioner of Patents

    Annex

    1.        A method comprising:
    receiving, by a payment server and from a messaging application executing on a first mobile device operated by a first user, a request to initiate a payment transaction from a payment application executing on the first mobile device of the first user, wherein the request to initiate a payment transaction comprises a payment amount and a first user identifier associated with the first user, wherein the request to initiate a payment transaction does not identify a recipient of the payment transaction;

    identifying, by the payment server and in a data store maintained by the payment server, a financial account associated with the first user based on the first user identifier;

    facilitating, by the payment server and in the data store, a first adjustment to a balance associated with the financial account of the first user based on the payment amount;

    incrementing, by the payment server, a balance of an escrow account associated with the payment server based on payment amount;

    generating, by the payment server, a hyperlink associated with the first adjustment;

    transmitting, by the payment server, a payload comprising the hyperlink to the first mobile device, wherein the payload is configured to be transmitted from the first mobile device to a second mobile device as part of a request to transmit a payment message, via a message service server;

    wherein the request to transmit the payment message comprises the payment message and a second user identifier, wherein the payment message comprises the payload, and wherein the payload does not comprise the second user identifier;

    receiving, by the payment server from the second mobile device, subsequent to the second mobile device receiving the payment message from the first mobile device via the message service server, instructions to decrement the escrow account and increment an account associated with the second user; and

    wherein the payload is further configured such that activation of the payload at the second mobile device causes the second mobile device to transmit the instructions, and wherein activating the payload comprises activating the hyperlink.

    2.        The method according to claim 1, wherein the hyperlink comprises a token string, and wherein the token string is generated by the payment server and is associated with data records of the escrow account.

    3.        The method according to claim 1 or claim 2, further comprising: identifying, by the payment server and based on information provided by the messaging service, a financial account associated with the second user based on information provided by the messaging service application.

    4.        The method according to any one of claims 1 to 3, wherein the messaging application is native to an operating system of the first mobile device.

    5.        The method according to any one of claims 1 to 3, wherein the messaging application is not native to an operating system of the first mobile device.

    6.        The method according to any one of claims 1 to 5, wherein activating the payload further comprises visiting a Uniform Resource Locator embedded within the payload.

    7.        A non-transitory computer-readable storage medium storing instructions that, when executed by a computing system, cause the computing system to perform operations comprising:

    receiving, by a payment server and from a messaging application executing on a first mobile device operated by a first user, a request to initiate a payment transaction from a payment application executing on the first mobile device of the first user, wherein the request to initiate a payment transaction comprises a payment amount and an identifier associated with the first user wherein the request to initiate a payment transaction does not identify a recipient of the payment transaction;

    identifying, by the payment server and in a data store maintained by the payment server, a financial account associated with the first user based on the identifier;

    facilitating, by the payment server and in the data store, a first adjustment to a balance associated with the financial account of the first user based on the payment amount;

    incrementing, by the payment server, a balance of an escrow account associated with the payment server based on payment amount;

    generating, by the payment server, a hyperlink associated with the first adjustment;

    transmitting, by the payment server, a payload comprising the hyperlink to the first mobile device, wherein the payload is configured to be transmitted from the first mobile device to a second mobile device as part of a request to transmit a payment message, via a message service server;

    wherein the request to transmit the payment message comprises the payment message and a second user identifier, wherein the payment message comprises the payload, and wherein the payload does not comprise the second user identifier;

    receiving, by the payment server from the second mobile device, subsequent to the second mobile device receiving the payment message from the first mobile device via the message service server, instructions to decrement the escrow account and increment an account associated with the second user; and

    wherein the payload is further configured, such that activation of the payload at the second mobile device causes the second mobile device to transmit the instructions; and wherein activating the payload comprises activating the hyperlink.

    8.        The non-transitory computer-readable storage medium according to claim 7, wherein the hyperlink comprises a token string, and wherein the token string is generated by the payment server and is associated with data records of the escrow account.

    9.        The non-transitory computer-readable storage medium according to claim 7 or claim 8, wherein the operations further comprise: identifying, by the payment server and based on information provided by the messaging service, a financial account associated with the second user based on information provided by the messaging service application.

    10.      The non-transitory computer-readable storage medium according to any one of claims 7 to 9, wherein the messaging application is native to an operating system of the first mobile device.

    11.      The non-transitory computer-readable storage medium according to any one of claims 7 to 9, wherein the messaging application is not native to an operating system of the first mobile device.

    12.      The non-transitory computer-readable storage medium according to any one of claims 7 to 11, wherein activating the payload further comprises visiting a Uniform Resource Locator embedded within the payload.

    13.      A system for processing a payment request from a client mobile device comprising:

    a payment server, comprising a memory and a processor, the payment server being configured to:

    receive, from a messaging application executing on a first mobile device operated by a first user, a request to initiate a payment transaction from a payment application executing on the first mobile device of the first user, wherein the request to initiate a payment transaction comprises a payment amount and an identifier associated with the first user wherein the request to initiate a payment transaction does not identify a recipient of the payment transaction;

    identify, in a data store maintained by the payment server, a financial account associated with the first user based on the identifier;

    facilitate, in the data store, a first adjustment to a balance associated with the financial account of the first user based on the payment amount;

    incrementing, by the payment server, a balance of an escrow account associated with the payment server based on payment amount;

    generate a hyperlink associated with the first adjustment;

    transmit a payload comprising the hyperlink to the first mobile device, wherein the payload is configured to be transmitted from the first mobile device to a second mobile device as part of a request to transmit a payment message, via a message service server;

    wherein the request to transmit the payment message comprises the payment message and a second user identifier, wherein the payment message comprises the payload, and wherein the payload does not comprise the second user identifier;

    receiving, by the payment server from the second mobile device, subsequent to the second mobile device receiving the payment message from the first mobile device via the message service server, instructions to decrement the escrow account and increment an account associated with the second user; and

    wherein the payload is further configured, such that activation of the payload at the second mobile device causes the second mobile device to transmit the instructions; and wherein activating the payload comprises activating the hyperlink.

    14.      The system of claim 13, wherein the hyperlink comprises a token string, and wherein the token string is generated by the payment server and is associated with data records of the escrow account.

    15.      The system according to claim 13 or claim 14, wherein the payment server is further configured to: identify, based on information provided by the messaging service, a financial account associated with the second user based on information provided by the messaging service application.

    16.      The system according to any one of claims 13 to 15, wherein the messaging application is native to an operating system of the first mobile device.

    17.      The system according to any one of claims 13 to 16, wherein the messaging application is not native to an operating system of the first mobile device.

    18.      The system according to any one of claims 13 to 17, wherein activating the payload further comprises visiting a Uniform Resource Locator embedded within the payload.