Visa International Service Association - [2023] APO 31

IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Visa International Service Association [2023] APO 31
Patent Application: 2017218390

Title:Methods and systems for using digital signatures to create trusted digital asset transfers

Patent Applicant: Visa International Service Association

Delegate:Greg Powell

Decision Date: 31 May 2023

Hearing Date: Written submissions filed on 27 April 2023

Catchwords: PATENTS – examiner objection – manner of manufacture – substance of the invention is an administrative arrangement – substance is not a manner of manufacture – no patentable subject matter identified in the specification – application refused

Representation: Patent attorney for the applicant: FPA Patent Attorneys Pty Ltd

IP AUSTRALIA
AUSTRALIAN PATENT OFFICE

Patent Application: 2017218390

Title:Methods and systems for using digital signatures to create trusted digital asset transfers

Patent Applicant: Visa International Service Association
Date of Decision: 31 May 2023
DECISION

The claims of the application, as proposed to be amended, do not define a manner of manufacture.
I do not see any subject matter in the body of the specification from which valid claims could be drafted to overcome this finding.
I refuse the application.
REASONS FOR DECISION

Background

Patent application 2017218390 (the present application) was filed by Visa International Service Association (the applicant) on 27 January 2017 as a PCT application (PCT/US2017/015498). The present application claims priority from two US applications, with the earliest being filed on 12 February 2016.
The present application was filed after 15 April 2013. It 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 s 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.
A first examination report was issued on 6 January 2022 raising objections in relation to manner of manufacture, s 40, novelty and inventive step. The applicant responded to the first examination report on 24 March 2022 by way of written submissions and proposed amendments to the description and claims. A second examination report issued on 30 March 2022 containing manner of manufacture and inventive step objections. A response was filed on 12 July 2022 with further submissions and amendments to the description and claims. On 3 August 2022 a third examination report issued containing an objection with respect to manner of manufacture. Another response was filed on 22 November 2022 with further submissions and amendments to the description and claims. A fourth report issued on 12 December 2022 objecting that the claims did not define a manner of manufacture. On 5 January 2023, the applicant requested to be heard. On 27 April 2023 the applicant filed written submissions (“written submissions”). I also note that the applicant filed a divisional application (2023200072) from the present application on the day after they requested a hearing on the present application.
Six amendments were proposed during examination. No objection was raised by the examiner to the allowability of the amendments. I do not see any immediate 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 six filed on 22 November 2022. Wherever I refer to the specification, it is a reference to the specification as proposed to be amended.
Finally, while the final date for acceptance of the present application was 6 January 2023, 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
The invention relates to a process of transferring a digital asset representing something of value from an issuer to a recipient. The digital asset is variously described in the specification as “a promise of value”[1], and could be something like “an access entry code for a restricted area, tickets to an event, login credentials for accessing secured information”[2], “ownership data”[3], etc. The specification focusses (as will I in this discussion) on the transfer of a currency value when discussing the processes of the invention, but nothing turns on this specificity.
[1] Specification at [0021]
[2] Ibid at [0032]
[3] Ibid at [0035]
The specification notes that people (and organisations) often transfer value to others, with such transfers typically accomplished by providing value from an issuer’s account at the issuer’s financial institution to a recipient’s account at the recipient’s financial institution. Noting that a reduction in the issuer’s account value results in a gain for the issuer’s financial institution (as their liability is reduced), and an increase in the recipient’s account results in a loss for the recipient’s financial institution (as their liability is increased), it is common for the financial institutions to engage in an equal and opposite transaction via a correspondent bank relationship, where the issuer’s financial institution has an account at the recipient’s financial institution, and/or vice versa. The equal and opposite transaction, which is often called “settlement”, frequently involves debiting the issuer’s financial institution’s account at the recipient’s financial institution by the same value that is credited to the recipient’s account and vice versa (thereby eliminating any net balance change for the recipient’s financial institution).
Because financial institutions only have a few correspondent bank relationships, the specification states that, for something like an international wire transfer, it is likely that the issuing financial institution does not have a direct correspondent bank relationship with the recipient financial institution. As such, it is relatively common for the issuing financial institution to indirectly transfer the value to the recipient financial institution by, for example, the issuing financial institution transferring the value to a third (intermediary) financial institution with which it has a correspondent bank relationship, and the third financial institution may then be able to transfer the value to the recipient financial institution (assuming they have a correspondent bank relationship). Consequently, an international transfer may involve one or more domestic transfers in the issuer’s country, an international transfer, and one or more domestic transfers in the recipient’s country before finally reaching the recipient’s account.
The specification provides an example of an international transfer in which Alice seeks to pay an invoice sent to her by Bob, where Alice resides in America (US) and Bob is located in the United Kingdom (UK). The process can be represented by the following steps:
·Bob sends his invoice to Alice.
·Alice instructs her financial institution to send an amount of money (matching the invoice charge) from her account to Bob’s account at Bob’s UK financial institution.
·The amount (in USD) is debited from Alice’s account.
·Alice’s financial institution sends a message to their correspondent US bank instructing them to pay the amount (in GBP) into Bob’s account at his UK financial institution.
·The correspondent US bank “bills” (in USD) Alice’s financial institution the amount which is equivalent to the GBP amount sought to pay. This bill is paid by taking USDs from Alice’s financial institution’s correspondent account at their correspondent US bank, and this is taken to be the settlement between these banks.
·The correspondent US bank sends a message to their correspondent UK bank instructing them to pay the amount (in GBP) into Bob’s account at his UK financial institution.
·The correspondent UK bank “bills” the correspondent US bank and the required amount (in GBP) is taken from the correspondent US bank’s correspondent account at the correspondent UK bank, and this is taken to be the settlement between these banks.
·The correspondent UK bank sends a message to Bob’s UK financial institution instructing them to pay the amount (in GBP) Bob’s account.
·Bob’s UK financial institution “bills” the correspondent UK bank and the required amount (in GBP) is taken from correspondent UK bank’s correspondent account at Bob’s UK financial institution, and this is taken to be the settlement between these banks.
·The amount (in GBP) is credited to Bob’s account.
The specification notes that this type of transfer can take a long time. It could be the case that (i) each correspondent bank will not send the next payment instruction to the next bank until the funds are received during settlement, and/or (ii) each settlement step could be deferred until a net settlement process at the end of a day, thereby adding extra days for the funds transfer. Time zone differences can also be a factor. Furthermore, as fees could be charged for each message by each correspondent bank, and for foreign currency exchange, the funds may have been significantly reduced (by an unpredictable amount) during the transfer process. Given different transfer agreements between correspondent banks, along with the use of multiple regional wire transfer networks, each with their own rules and protocols, the specification notes that any participating bank could be unaware of how much time the transfer will take, the rules governing each transfer step, the status of a pending transfer, whether the corresponding banks will correctly record the details of the transaction, and whether the transfer will even be successful. The specification states:
“Thus, after Alice’s bank sends the first funds transfer to the first correspondent bank, and (sic) Alice’s bank is no longer in control, and just has to hope that the fund transfer will be completed appropriately.”[4]
The invention seeks to address these issues.
[4] Ibid at [0007]
The proposed solution uses a network which is used by “enrolled” participating entities, each with a unique identification, allowing them to communicate with, and transfer digital assets directly to, any other financial institution enrolled with the network. Each entity has access to a node on the network. The network is controlled by a central administration (having its own administrator node(s)) which, via its rules around enrolment, can validate financial institutions and other entities during enrolment, ensure that enrolling entities are legitimate organizations that are screened for compliance to network rules, and implement standardized messaging procedures for enrolled entities. In addition, the specification describes that digital assets are digitally signed by an issuing entity and an administrative entity. The issuer’s signature indicates that the digital asset was legitimately sent by the designated sender, and the administrator’s signature can indicate that the digital asset was approved and/or recorded by the administrator having validated the bona fides of the issuer. Recordation of asset transfers is done in a ledger, with the ledger being a distributed ledger like blockchain, and each transfer forming a new block on the blockchain.
Broadly, to initiate an asset transfer, the process involves a user (or an institution representing the user) instructing an issuer node in the asset transfer network to generate and provide the digital asset. The issuer node (or, alternatively, an interaction platform associated with the issuer node) generates and digitally signs the digital asset. The issuer node obtains approval and a second digital signature from an administrative node. Then, the issuer node provides the digital asset to a recipient node (possibly directly, or through network-wide distribution). The recipient node then provides the digital asset to the recipient (or an institution representing the recipient).
Figure 1 shows the schematic of the network:
The transfer of an asset from a user to a resource provider, such as a merchant, access device, secure data access point, etc, involves the creation (or “minting”) of a digital asset by the sending institution computer 160 upon a request being received from the user computer 110. The asset is digitally signed and sent, via the issuer node computer 165, to an administrative node computer 150 for the application of a second digital signature. In other embodiments, the minting and signing of the digital asset is performed by the issuer node computer 165, or by the interaction platform 154, upon request of the sending institution computer 160.
Digital signatures that are applied are described as being achieved using public key encryption whereby the digital signature is a unique value generated from a message and a private key of the issuer using an encrypting algorithm. The authenticity of the signature can then be verified using the public key corresponding to the private key and distributed throughout the network. The specification notes that:
“[p]ublic and private keys may be in any suitable format, including those based on RSA or elliptic curve cryptography (ECC). In some embodiments, a key pair may be generated using an asymmetric key pair algorithm. However, a key pair may also be generated using other means, as one of ordinary skill in the art would understand.”[5]
[5] Ibid at [0047]
The key pair for the issuer (which is received when the party enrols in the network) could be stored in a hardware security module of the sending institution computer 160. However, the specification also states that the key pair could be stored in the hardware security module of another entity such as the issuer node computer 165 or the administrative node computer 150. The keypair for the second digital signature is stored in the administrative node computer 150.
The specification remarks:
“The high level of network trust and digitally signed digital assets can allow recipient financial institutions to make a received digital asset value immediately available in the recipient account, even if the value as (sic) not yet been settled. This means that a transferred value can be available almost immediately.”[6]
[6] Ibid at [0028]
The specification indicates that the value can be settled between the accounts at a later time. In figure 1, settlement service computer 155 is tasked with facilitating the actual exchange of funds (i.e. settlement) between the sending institution computer 160 and the recipient institution computer 140. The specification discusses a central settlement entity which could be a central financial institution having at least one location and one account in each country that it operates. This could mean that, for example, the issuer’s financial institution could have an account with the central settlement entity in a first country, and the recipient’s financial entity can have an account with the central settlement entity in a second country, such that an international transfer can take place by transferring from the issuer’s financial institution to the central settlement entity, and then from the central settlement entity to the recipient’s financial institution. That is, each financial institution that participates in the asset transfer network need only have one external account with the central settlement entity instead of multiple correspondent banking relationships.
Notwithstanding the above description, the specification states that a number of services said to be performed by specific computers or platforms could be performed by other elements of the network. For example, the specification notes that the interaction platform 154 could also generate assets, digitally sign assets, store transactions records, and so on, some of which tasks are said to be performed by the administrative node computer 150. The specification also notes that the interaction platform 154 and the administrative node computer 150 could be combined as a single entity, with both of these computers being operated by the central entity that administrates the whole system 100. It is also envisaged that this entity is associated with, and/or operates several other, entities in the system 100, such as the foreign exchange transaction application interface 152, the settlement service computer 155, the transaction repository 156, and the risk management computer 157.
No real disclosure as to the physical or software aspects of the network and the computers in the network is provided. They are described in the most generic of terms and exemplified at a very high level of generality. It is left to the person skilled in the art to implement the network. The description deals with the functions carried out by the computers and network.
As an example of the level of disclosure, figure 2 shows details of the administrative node computer:
Description of the various modules and databases is in terms of the functions carried out in those modules. The same applies to the description of other networked computers, which have similar modules. As I believe that the functions are obvious from the above paragraphs of my decision, I do not believe it is necessary to provide further description here.
As to the physical aspects of the computers, the specification states:
“Subsystems in the computer system are interconnected via a system bus. Additional subsystems include a printer, a keyboard, a fixed disk, and a monitor which can be coupled to a display adapter. Peripherals and input/output (I/O) devices, which can couple to an I/O controller, can be connected to the computer system by any number of means known in the art, such as a serial port. For example, a serial port or external interface can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or the fixed disk, as well as the exchange of information between subsystems. The system memory and/or the fixed disk may embody a computer-readable medium.”[7]
[7] Ibid at [0205]
Figure 4 shows the network:
The asset transfer network is described as comprising different types of nodes, providing “infrastructure” for providing digital assets in “push” messages. While a direct arrow is provided showing a direct line of transfer of the digital asset, the issuer node computer 165 could broadcast the digital asset information to several, or all, of the nodes in the network and the recipient node computer could identify that it is the target based on the ID associated with the asset.
As to technical specifics, the specification notes:
“Suitable communications networks may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like.
Messages between the computers, networks, and devices may be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), ISO (e.g., ISO 8583) and/or the like.”[8]
[8] Ibid at [0049]–[0050]

Digital assets transmitted in an asset transfer network are recorded in a ledger of transactions, where a ledger of transactions can take the form of a blockchain. One or more administrative nodes may maintain the ledger of digital assets that have been transferred between nodes. The ledger may also be stored at the issuer and/or recipient node computers.
The specification states:
“… embodiments provide an asset transfer network with improved speed, security, reliability, transparency, and efficiency. For example, a universal and permissioned network can be well-organized, and can enable efficient messaging and transfers directly between a sender and a recipient, regardless of location. This organization can reduce the extra communications, as well as remove the mystery of various unknown correspondent bank relationships, present in decentralized legacy systems.
Central enrollment, compliance-screening of participating entities, standardized communications, and universal identifiers that uniquely identify entities can each facilitate a sense of trust in the network and the participating entities. A distributed ledger can instill confidence that each participating entity has the same information about agreements and transfers that have been made. Similarly, digitally signed digital assets can be highly trusted, as the signatures can be validated to confirm that a digital asset is legitimately being transferred.”[9]
[9] Ibid at [0026]–[0027]
Invention as claimed
The specification ends with 18 claims. The entire claim set is set out in the Annex to this decision. Independent claims 1 and 8 are directed to methods to be carried out at an administrative node computer and an issuer node computer, respectively, and claims 17 and 18 are directed to computers having a processor and a computer readable medium to implement the methods of claims 8 and 1, respectively.
I will set out claims 1 and 8 in full:
“1. A method comprising:
enrolling, by an administrative node computer, an issuer node computer and a recipient node computer for participation in an asset transfer network, where the administrative node computer is a trusted central administrator for the asset transfer network, and where the enrolling includes:
generating a first key pair including a first private key and first public key; and
providing the first private key to the issuer node computer;
receiving, by the administrative node computer, from the issuer node computer, a digital asset and a first digital signature for the digital asset, the digital asset including a sender identifier of a sender, a recipient identifier of a recipient, and an amount to pay the recipient by the sender, wherein the first digital signature for the digital asset was generated by the issuer node computer by digitally signing at least some information of the digital asset with the first private key associated with the issuer node computer in response to the issuer node computer receiving a request from a sending institution computer holding a first account of the sender, and wherein the first digital signature serves as a first guarantee by the issuer node computer;
validating, by the administrative node computer, the digital asset by analyzing the sender identifier of the sender, the recipient identifier of the recipient, and the amount;
verifying, by the administrative node computer, authenticity of the first digital signature for the digital asset with the first public key associated with the issuer node computer, the first public key corresponding to the first private key;
after validating the digital asset and verifying the authenticity of the first digital signature for the digital asset, generating, by the administrative node computer, a second digital signature for the digital asset by digitally signing the at least some information of the digital asset with a second private key associated with the administrative node computer, wherein the first digital signature and the second digital signature are both generated by digitally signing the same digital asset but with different private keys, and the second digital signature serves as a second guarantee by the administrative node computer;
generating, by the administrative node computer, a block for a blockchain, the block including information about the digital asset, the first digital signature, and the second digital signature, wherein the recipient node computer obtains the digital asset, the first digital signature, and the second digital signature from the blockchain, wherein the recipient node computer uses the first public key associated with the issuer node computer to verify that the first digital signature was generated by the issuer node computer, uses a second public key associated with the administrative node computer to verify that the second digital signature was generated by the administrative node computer, and wherein the recipient node computer transmits the digital asset to a recipient institution computer holding a second account of the recipient, wherein the recipient institution computer immediately credits the second account of the recipient with the amount indicated in the digital asset even if the amount has not actually been received from the first account of the sender; and
after generating the block, coordinating a transfer of funds including the amount from the first account of the sender to the second account of the recipient.”
“8. A method comprising:
enrolling, by an issuer node computer, with an administrative node computer for participation in an asset transfer network, where the administrative node computer is a trusted central administrator for the asset transfer network, and where the enrolling includes:
receiving a first private key from the administrative node computer;
receiving, by the issuer node computer, from a sending institution computer holding a first account of a sender, a request to transfer an amount from the sender to a recipient;
generating, by the issuer node computer, a digital asset including a sender identifier of the sender, a recipient identifier of the recipient, and the amount to pay the recipient by the sender;
generating, by the issuer node computer, a first digital signature for the digital asset by digitally signing at least some information of the digital asset with the first private key associated with the issuer node computer, the first digital signature serving as a first guarantee by the issuer node computer; and
sending, by the issuer node computer, to the administrative node computer, the digital asset and the first digital signature for the digital asset, wherein the administrative node computer validates the digital asset, verifies authenticity of the first digital signature for the digital asset with a first public key associated with the issuer node computer, the first public key corresponding to the first private key, wherein the administrative node computer, after validating the digital asset and verifying the authenticity of the first digital signature, generates a second digital signature for the digital asset by digitally signing the at least some information of the digital asset with a second private key associated with the administrative node computer, the second digital signature serving as a second guarantee by the administrative node computer, wherein the first digital signature and the second digital signature are both generated by digitally signing the same digital asset but with different private keys, wherein the administrative node computer generates a block for a blockchain, the block including information about the digital asset, the first digital signature, and the second digital signature, wherein the recipient node computer obtains the digital asset, the first digital signature, and the second digital signature from the blockchain, uses the first public key associated with the issuer node computer to verify that the first digital signature was generated by the issuer node computer, uses a second public key associated with the administrative node computer to verify that the second digital signature was generated by the administrative node computer, and wherein the recipient node computer transmits the digital asset to a recipient institution computer holding a second account of the recipient, wherein the recipient institution computer immediately credits the second account of the recipient with the amount indicated in the digital asset even if the amount has not actually been received, and wherein, after generating the block, the administrative node computer coordinates a transfer of funds including the amount from the first account of the sender to the second account of the recipient.”
These claims define the same asset transfer process from two different perspectives. The process follows the broad flow that I set out in [12] above, whereby (i) a digital asset relating to a user’s request to transfer value to a resource provider is created and signed by an issuer, (ii) sent to an administrator to be assessed and signed for a second time (and recorded in a blockchain ledger), (iii) returned to the issuer and then (iv) sent to a recipient, where, upon receipt by the recipient, the value is immediately credited to the resource provider since the digital signatures effectively guarantee the value of what is, in effect, an IOU. Although I acknowledge that these claims do not explicitly define steps (iii) and (iv), in my opinion, such steps are strongly implied by the claims. I any event, nothing turns on this lack of explicitness.
Dependent claims 2, 3, 6, 7, 9, 10, 12 and 15 provide further details about the transfer between the issuer institution computer, the recipient institution computer and the various nodes of the network. For example, claim 2 defines that the recipient node computer provides the first digital signature to the recipient institution computer which holds the recipient’s account, claim 7 defines that the identifiers of the issuer and recipient are globally unique, and claim 10 defines that the issuer node computer receives the digital asset and the second digital signature from the administrative node computer and sends the digital asset to the recipient node computer. Dependent claims 4 and 16 provide further detail around the settlement process using a central; bank at which both the sending and receiving institutions have an account, claim 5 defines that, during the enrolment process, the private and public keys for the enrolling party are provided by the administrative node computer, and claims 11, 13 and 14 define further details of the blockchain utilised for recording the transfer.
While technical elements are present in the claims, it is clear that only generic functions are defined. There is no indication that the computers are operating in any way other than their purely conventional manner, providing well-known and well-understood effects. The known technique of public key encryption for digitally signing assets is being used, along with the known technique of recordation of transactions in a blockchain. The process has been implemented using conventional technology.
Examination
In the first report of 6 January 2022, the examiner raised lack of clarity, lack of novelty, lack of inventive step, and that the claimed invention was not directed to a manner of manufacture. Of relevance to this decision, the examiner stated with respect to manner of manufacture (for somewhat different claims):
“… the claimed invention, as a matter of substance, does not relate to patentable subject matter.
The claimed invention is a computer-implemented scheme (i.e. a set of steps and rules) to validate and record a digital asset, and coordinate a transaction associated with the asset.
This is not a technical solution to a technical problem because the claims do not recite any technical improvement in, for example, verification processes, how digital signatures are generated, how the asset is stored, or how the transaction is coordinated.
As a result, I have concluded that the claimed invention is merely reciting a scheme performed by a computer network that is used for its conventional and well-known functions of sending, storing and receiving data, and executing actions. The claimed invention does not disclose any technical improvement to the functioning of a computer irrespective of the data being processed, and is furthermore only the intermediary through which the scheme is performed.”
The applicant responded with arguments and amendments to the description and claims. With respect to manner of manufacture, the applicant submitted that, noting the issues I have discussed at [10] above that transfers can take a long time, the claimed invention provided significant improvements to the speed, security, reliability, transparency, and efficiency of asset transfers, through the creation of a high level of network trust by using digitally signed digital assets, thereby reducing transaction risk such that the recipient’s financial institutions could be secure in making the digital asset’s value immediately available in the recipient’s account, even if the value had not yet been settled.
In the second report, the examiner maintained the inventive step and manner of manufacture objections, stating with respect to manner of manufacture:
“The problems to be solved are summarised in [0008] and amount to the fact that international wire transfers are completed over a decentralised and non-uniform network of banking relationships. Each additional link in this network increases time, uncertainty, cost, and inefficiency.
The claimed invention allegedly solves this problem by providing an asset transfer network that can allow digital assets to be sent quickly and directly to a recipient through a transparent process, regardless of location and identities of the sender and receiver.
…
… the claimed invention, as a matter of substance, does not relate to patentable subject matter.
The claimed invention is a computer-implemented scheme (i.e. a set of steps and rules) to validate and record a digital asset, and coordinate a transaction associated with the asset.
This is not a technical solution to a technical problem because the claims do not recite any technical improvement in, for example, verification processes, how digital signatures are generated, how the asset is stored, or how the transaction is coordinated.
As a result, I have concluded that the claimed invention is merely reciting a scheme performed by a computer network that is used for its conventional and well-known functions of sending, storing and receiving data, and executing actions. The claimed invention does not disclose any technical improvement to the functioning of a computer irrespective of the data being processed, and is furthermore only the intermediary through which the scheme is performed.”
The applicant responded with arguments and amendments to the description and claims. With respect to manner of manufacture, the applicant submitted that the invention solved a technical problem in computers related to network security and trust which exists when two endpoint node computers may not know or trust one another. The applicant submitted that the problem was addressed by having each endpoint node computer establish a trusted relationship with the administrative node by enrolling with the administrative node computer, having the administrative node computer vet a digital asset to establish that it comes from the issuer node computer and signing the asset as proof to the recipient node computer that the asset came from an authentic node computer. Thus, given the chain of digital signatures, and the immutability of a blockchain, the recipient node computer can trust the authenticity and promise of the digital asset from an unknown issuer node computer. The applicant submitted that this process had the advantage of facilitating a sense of trust in the network and the participating entities, thereby reducing the time required to complete transactions by making a received digital asset value immediately available in the recipient’s account.
The applicant also submitted that:
(i)given the administrative node computer only applies a second digital signature after validation of a first digital signature; and
(ii)given the trust relationship between the administrator and the recipient,
then, unlike previously known systems which required multiple end users to validate signatures each time instead of having a central entity validate the digital signatures, the claimed invention reduced the processing required by typically slower end user devices, which increased the speed of transactions.
In the third report, the examiner maintained the manner of manufacture objection, seeking to “make a distinction between a patentable advance in computer technology and the unpatentable implementation of an improved scheme that merely used the computer as an intermediary.” The examiner maintained that there was no improvement in the functioning of a computer as the computer functionality used to implement the claimed invention was conventional with the use of well-known cryptographic techniques of digital signatures and digital certificates to establish a trusted relationship. The examiner also disagreed that there was any technical contribution stating that:
“It does not appear that the Applicant has overcome any technical limitations present in the art that would otherwise prevent the application of a second digital signature to a digital asset.”
They also stated that:
“… the decision to immediately credit a recipient account is also not a technical matter. Instead, it is an administrative decision made entirely because a trusted relationship is considered to have been established between the sender and recipient computers. What exactly constitutes this trusted relationship appears to be arbitrary – there is no technical reason why it has to be the signing of the digital asset by the sender and administrative node computers, and could theoretically be any number of other cryptographic techniques suitable for establishing a trusted relationship between the sender and recipient computers.”
The examiner concluded that:
“the substance of the claimed invention is a scheme to use a sender computer and administrative node computer digitally sign a digital asset in order to immediately credit a recipient account even if the recipient has not actually received a transaction amount, and to record information about the digital asset and digital signatures on a blockchain.”
In response, the applicant filed further arguments and amendments to the description and claims. The arguments stated the claims provided a technical contribution of an improved system that provided both increased transaction processing security and faster processing of transactions. They noted:
“When a sending institution sends a promise of payment to a receiving institution, the receiving institution may not have any ability to verify or trust that the payment will be fulfilled. As a result, the receiving institution will not make a payment amount available to a recipient until the transaction has been fully completed (e.g., through settlement). Thus, due to a lack of technological processes for establishing transaction trust and security, the transaction fulfilment process is slow.
To address this problem, embodiments provide an asset transfer network with a trusted central administrator. Each endpoint node computer that wishes to participate in the asset transfer network may establish a trust relationship (e.g., through an enrolment process) with the trusted central administrator computer (referred to as the administrative node computer). As a result, even if endpoint node computers do not have relationships with one another, they all have a common connection with the administrative node computer.” (underlining in original)

The applicant submitted that the “unique technological combination” of digital signatures and blockchain proved to the recipient node computer that the digital asset came from an authentic source that is trusted by the administrative node computer. This meant that the transaction fulfilment process could be expedited, as the recipient node computer could be sufficiently confident that the promised value would be honoured that they could credit the recipient’s account before the promised amount had been received from the sending source (i.e. settlement had not yet taken place). That is, the central administrative node computer was known and trusted by the recipient node computer and its added second digital signature effectively guaranteed that the digital asset would be fulfilled, and its publication on a blockchain demonstrated that the digital asset could not be revoked. The applicant characterised this as “the system’s technological mechanism for creating assurance that the digital asset is not simply authentic, but that its promises will be fulfilled.”
The applicant also referred to the decision in Advanced New Technologies Co., Ltd[10] where an invention related to processing transactions in blockchains was found to be patentable. They noted that the decision found that the invention was a manner of manufacture because some of the method steps included technical steps, even though those technical steps used techniques that were well-known.
[10] [2021] APO 29
The examiner remained unconvinced and issued a fourth report objecting to a lack of manner of manufacture. That objection in its entirety is as follows (bolding, underlining and italics in the report):
“Patentable subject matter
I maintain Objection 6 from the previous examination report. Claims 1-18 as proposed to be amended do not define a manner of manufacture within the meaning of Section 18(1)(a) of the Patents Act 1990.
Technical Contribution
The Applicant has submitted that the claimed invention improves:
·Transaction processing security by having a trusted third party digitally sign a transferred digital asset, in addition to the signature already provided by a sender
·Transaction processing security by using the additional authentication provided by the signature of the trusted third party to credit a recipient account with an amount before the amount has actually been received
I do not see how any of these alleged improvements involve any technical contribution.
The central issue at play is one of trust. That is, can the recipient node computer trust the promises (i.e. a future transfer of an amount) made in a digital asset enough to credit a recipient account with the amount before the amount has been received?
Trust is not an inherent attribute of data; it is purely an abstract, subjective opinion that can differ from person to person, or indeed institution to institution. How much trust the recipient node computer places in the issuer node computer and the digital asset therefore depends on the overall needs of the system, or on the needs of the individual node computers and their respective institutions. It is clearly an administrative consideration, not a technical one.
To illustrate this point further, the Applicant in their response also states that:
‘Even if the recipient node computer can verify/trust that the issuer node computer is truly the one that issued a digital asset, whether through the recited “first digital signature” or as the Examiner alleged: “any number of other cryptographic techniques suitable for establishing a trusted relationship between the sender and recipient computers,” this still does not provide recipient node computer with confidence that the digital asset (e.g., a promise of payment) will be fulfilled.’
Why not? What technical limitations are stopping the recipient node computer from having enough confidence? How are the technical limitations overcome?
Instead, the claimed invention simply adds a second digital signature to the digital asset, provided by the administrative node computer. There is no technical reason why the administrative node computer is trusted over the issuer node computer. It is only done so for the purposes of implementing the scheme.
In light of the Applicant’s response and the proposed amendments, I now consider that the substance of the claimed invention lies in the scheme to have an administrative node computer digitally sign a trusted digital asset in addition to a signature already provided by an issuer node computer, so that a recipient node computer can immediately credit a recipient account with an amount even if the amount has not actually been received.
Advanced New Technologies Co. Ltd. [2021] APO 29 (ANT)
The Applicant submits that the claimed invention is similar to the invention of ANT, in that while the individual integers may be known, a technical solution to the problem of trust and security in previously known transaction fulfillment systems is still provided.
The Delegate in ANT found that the invention provided a technical solution within the blockchain involving the use of cryptographic techniques to address the issue of breach of privacy information from a node participating in a blockchain transaction.
The cryptographic techniques of ANT involved the signing of a data abstract by a plurality of transaction nodes. The character string of the data abstract changed after each signature such that the character string depended on the order in which it was signed by the nodes. This ‘nesting’ of the digital signatures was the technical solution.
In contrast, the claimed invention does not recite such a technical solution. Although multiple parties sign the digital asset, they do not ‘nest’ like the invention of ANT such that, for example, the digital signature of the issuer node is used as a hash function for the signature of the administrative node. Instead, the two signatures are entirely independent of each other.
As such, the claimed invention does not provide a technical solution and can be readily distinguished from ANT.
Accenture Global Solutions Limited [2022] APO 49 (Accenture)
Instead, I draw the Applicant’s attention to the decision of Accenture. Similarly to the present application, the invention of Accenture was ‘related to an exchange or transfer of an asset between two parties’ and addressed the problem of ‘security concerns associated with the lack of mutual trust between the exchange parties and certain reluctance by the parties to place assets in the control/custody of a neutral third party facilitating the exchange’ ([59]).
The Delegate of Accenture found what was proposed was a new asset exchange method based on well-known computer technology and encryption techniques. He did not consider this to be a technical improvement and considered that the solution represented a new administrative arrangement utilising existing technology for its well-known and understood functions ([69]).
Likewise, the claimed invention is merely a new administrative arrangement for transferring funds that uses existing and well-known computer technology and encryption techniques.
Therefore, for the above reasons, the claimed invention does not define subject matter suitable for a patent.”
Manner of manufacture
Through all four reports, the examiner has maintained an objection that the claims do not define a manner of manufacture, and this is the only outstanding objection. It is appropriate to summarise the law at this point.
The law
The statutory basis for manner of manufacture is found at s18(1)(a) of the Act which states:
(1)Subject to subsection (2), an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim:
(a)is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies;
In National Research Development Corporation v Commissioner of Patents[11], 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”.[12]
[11] [1959] HCA 67, (1959) 102 CLR 252 (“NRDC”)
[12] NRDC at page 275
The High Court though was not laying down a precise formulation that can be applied unthinkingly. In D’Arcy v Myriad Genetics Inc the High 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.”[13]
[13] [2015] HCA 35 (“Myriad”) at [23]
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.”[14]
[14] Myriad at [144]
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[15], Research Affiliates LLC v Commissioner of Patents[16], Encompass Corporation Pty Ltd v InfoTrack Pty Ltd[17], and Commissioner of Patents v Rokt Pte Ltd[18].
[15] [2015] FCAFC 177 (“RPL Central”)
[16] [2014] FCAFC 150 (“Research Affiliates”)
[17] [2019] FCAFC 161 (“Encompass”)
[18] [2020] FCAFC 86 (“Rokt 2”)
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 the principles summarised and generally accepted by Robertson J in Rokt Pte Ltd v Commissioner of Patents[19] as follows:
[19] [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].”[20]
[20] Rokt 1 at [189]
The Full Federal Court decision in Rokt 2 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.
This approach remains relevant in view of subsequent decisions. In Commissioner of Patents v Aristocrat Technologies Pty Limited[21], 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”.
[21] [2021] FCAFC 202 (Aristocrat ‘21)
On appeal to the High Court, in Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents[22] the Court was evenly split, and via s 23(2)(a) of the Judiciary Act1903 affirmed the Aristocrat ‘21 decision, while appearing to confirm that an advance in computer technology is not per se 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. In Aristocrat ’22, Kiefel CJ et al, at [77], also discussed the concept 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 concept appears consistent with the principles articulated in Rokt 1 when seeking 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.
Applicant’s submissions
[22] [2022] HCA 29 (Aristocrat ‘22)
Claimed invention
The applicant noted the issues that I have set out in [10] above regarding the delays in completion of electronic transactions (such as international wire transfers) using the conventional mechanisms in place and submitted that these “increase the uncertainty, insecurity, and inefficiency in transactions”. The applicant stated that these problems are addressed by the provision of a “new and inventive” asset transfer network which has a trusted central network node (i.e. the administrative node computer) with which each endpoint node computer in the asset transfer network (i.e. the issuer/recipient node computers) has established a trust relationship via an enrolment process with the trusted central network node. The applicant repeated the submission made during examination that the recipient node computer may not directly know or trust the issuer node computer, even if a digital signature proves that the issuer node computer generated the digital asset. However, given that the recipient node computer has a high level of trust in the central network node due to the enrolment process, network rules, etc, the co-signing of the digital asset by the central network node increased the security in the system, and the entering of the digital asset into an immutable blockchain by the central network node established a high level of assurance for the recipient node computer that the digital asset promises would be fulfilled.
The applicant states:
“The claimed invention accomplishes this through a unique technological combination of a chain of digital signatures and blockchain. Before the central network node guarantees the digital asset, it will want verification that the issuer node computer is truly the one behind the digital asset. This is accomplished through verifying the first digital signature with keys that were provided by the central network node during enrolment …
Then, the central network node digitally signs that same digital asset (a second digital signature for the same digital asset), proving to the second node computer that the digital asset is coming from an authentic source that is trusted by the central network node …
Then, the central network node adds the digital signature and blocks to a blockchain. The recipient node computer monitors the blockchain and identifies new digital assets that are now immutably recorded in the blockchain.
Thus, the recipient node computer identifies that the digital asset is immutably recorded in the blockchain and fulfilment is guaranteed with two digital signatures, one of which is from the trusted central network node. The recipient node computer can also verify authenticity of digital signatures and guarantees with public keys …
Thus, through the layered combination of enrolment in a common asset transfer network, shared trust in a central network node, a chain of digital signatures, and the immutability of a blockchain, the recipient node computer can trust the authenticity and promise of the digital asset from an unknown issuer node computer. Thus, the new system and technological process provides an improvement in transaction processing security and trust, as the recipient node computer can be confident through the layered network security that the digital asset will be fulfilled. This then enables the transaction fulfilment process to be expedited, as the recipient node computer can be sufficiently confident to cause the promised payment amount to be credited to the end recipient immediately, even before the promised amount has actually been received from the sending source (e.g., settlement has not yet taken place, but the receiving institution credits the recipient account ahead of the settlement).”[23] (emphasis in original)
[23] Written submissions at [22]–[26]
Substance of the claimed invention is technical in nature
The applicant agreed that merely “putting” software into a computer would not, by itself, meet this requirement for a manner of manufacture if the underlying invention embodied in the claims was a scheme. However, the applicant submitted that, if the substance of the invention lay in a technological innovation (e.g., solving a technical problem within or outside the computer), in the application of computer technology or in an improvement in computer technology, it would generally be considered patent eligible.

The applicant submitted that the claimed invention was directed to a new and improved asset transfer network, including a new central network node, which, in the applicant’s submission was a physical computer network and could not be considered a mere scheme, abstract idea or a business method. In the applicant’s submission, the underlying invention embodied in the claims included specific technical features of the central network node that enabled instantaneous, secure and efficient transactions. The applicant particularly highlighted the combination of a chain of digital signatures and blockchain utilized by the central network node to increase the security and trust in the network. In the applicant’s opinion, the specific combination of the chain of digital signatures and blockchain were not a mere scheme or abstract idea, but were technological steps performed by the central network node.
Contribution made by the claimed invention to the state of the art is technical in nature
The applicant noted that the second signature is only generated by the central network node after the first digital signature had been validated by it. In the applicant’s opinion, given the trust relationship that exists between the operator of the central network node and the recipient institution (given the enrolment process), the recipient could trust the issuer computer without having to validate the digital signature applies by the issuer. The applicant submitted that this feature made a technical contribution to the state of the art of electronic transaction systems because:
“[i]n previously known electronic transaction systems end users had to actively review, agree, and sign contracts before a certificate is generated or any other verification process takes places. Thus, such previously known systems required multiple end users to validate signatures each time instead of having a central entity validate the digital signatures and then advertise that it has validated the digital signatures by applying a second digital signature.”[24] (emphasis in original)
The applicant submitted that, consequently, the claimed invention reduced the processing required by “typically slower end user devices”[25], thereby increasing the speed of the electronic transactions compared to previously known solutions.
[24] Ibid at [37]
[25] Ibid at [38]
Claimed invention solves a technical problem with a technical solution
The applicant appeared to submit that the time taken to settle electronic transactions was a technical problem that existed for previously known mechanisms for conducting electronic transactions. Stating that there were “a number of factors that increase the time taken to settle electronic transactions in previously known electronic transaction systems and affect the security and reliability of electronic transactions”[26], the applicant stated that one factor was the trust (or lack thereof) that the recipient node computer had that the source node computer would fulfil an electronic transaction, with the consequence that the recipient node computer would only perform its functions once the source node computer had finished performing its function. The applicant states that this was addressed “using technical means”[27]. The particular aspect highlighted was that:
“… the central network node (that is known and trusted by the recipient node computer) adds a second digital signature to guarantee that the digital asset will be fulfilled, and publishes a blockchain to demonstrate that the digital asset cannot be revoked.”[28]
[26] Ibid at [40]
[27] Ibid at [41]
[28] Ibid at [41]
Technical advantages
The applicant submitted that the claimed invention had a number of technical advantages. Firstly the applicant states that, because of the central node’s verification process and blockchain entry, the receiving institution can have a high level of trust in the digital asset and make a digital asset amount immediately available in the recipient account, even if the amount has not yet been settled. This was said to greatly reduce the time required to complete a digital transaction compared to transactions in the past.
The applicant also stated that the central enrolment process, compliance-screening of participating entities, standardised communications, universal identifiers uniquely identifying entities, and the use of a distributed ledger, facilitated a sense of trust in the network and confidence that the sending financial institution had performed proper transaction validation, and that a digital asset is legitimately being transferred between the participating entities. The applicant referred to the description which states:
“The high level of network trust and digitally signed digital assets can sufficiently reduce transaction risk to allow recipient financial institutions to make a received digital asset value immediately available in the recipient account, even if the value as (sic) not yet been settled. This means that a transferred value can be available almost immediately after the transfer is initiated. Thus, regardless of how and when settlement takes place, embodiments allow funds to be available much faster than traditional transfer methods (e.g., immediately vs. 3-7 days).”[29]
[29] Specification at [0203]
Similarity to Advanced New Technologies Co., Ltd. [2021] APO 29
As they had done during examination, the applicant also drew my attention to Advanced New Technologies Co., Ltd. [2021] APO 29 (“ANT”) where the delegate found that an invention related to processing transaction requests in blockchain networks was a manner of manufacture. The applicant stated:
“Although the hearing officer considered that the invention did not solve a technical problem (see paragraph 56 of the decision) and merely required generic computer implementation (see paragraph 65 of the decision, where the hearing officer notes that individual integers of the claimed invention were generic), he eventually decided that the invention was a manner of manufacture because some of the method steps included technical steps (e.g., generating the data abstract and obtaining digital signatures) – even though those technical steps used techniques that were well-known (e.g., one-way hash function, digital signatures).”[30]
[30] Written submissions at [50]
While acknowledging that this decision was “non-binding”[31], the applicant submitted that, when considered as a whole:
“the claimed invention provides a technical solution to the problem of trust and security in previously known transaction systems and therefore the balance of consideration weighs in favour of finding that the claimed invention is a manner of manufacture. Moreover, the presently claimed invention solves in a technical manner the technical problems of transaction risk and lack of transaction speed.”[32] (emphasis in original)
[31] Ibid at [48]
[32] Ibid at [52]
Consideration
Notwithstanding the skilled advocacy on behalf of the applicant, I am not convinced that the objection cannot be sustained. I will address the applicant’s submissions under the same headings as used by them.
Claimed invention
To my mind, while technical elements are present in the claims, there is no indication that the computers are operating in any way other than their purely conventional manner, providing well-known and well-understood effects. The known technique of public key encryption for digitally signing assets is being used, along with the known technique of recordation of transactions in a blockchain. Clearly, the process has been implemented using conventional technology. In other words, the underlying hardware of the process involves generic computers interacting in the usual manner with a generic network to transfer data representing a digital asset in a generic way, where that asset has been digitally signed using generic public key encryption, and the transaction has been recorded with generic blockchain processes. The description does not suggest that the invention requires anything other than standard hardware and routine programming, or that it involves any invention in its implementation. Indeed, as evidenced by the passages I have quoted at [15], [22] and [24] above, the opposite is the case.
To the extent that the issue is one of trust, the statement made by the examiner in their fourth report resonates:
“The central issue at play is one of trust. That is, can the recipient node computer trust the promises (i.e. a future transfer of an amount) made in a digital asset enough to credit a recipient account with the amount before the amount has been received?”
In the present case, an increase in the trust that parties to a transaction have with the digital asset of that transaction (i.e. their satisfaction with the validity of the asset) is achieved by an administrative arrangement whereby the parties sign up to a central authority which operates a network over which digital assets can be sent and received. The central authority has established rules around what is required to be provided upon enrolment, as well as rules around actions that have to be taken before a digital asset can be transferred from one enrolled party to another. Those rules require two digital signatures per asset, with one signature being from the central authority because, allegedly, the central authority is more trusted than the issuing authority. This trust seems to be in place solely due to the rules in place around enrolment and asset transfer. In other words, establishing trust does not require any of the technical elements to operate in a way foreign to their normal use.
Substance of the claimed invention is technical in nature
It follows from the above that I do not consider the substance of the invention to be technical in nature. I do not see how the substance of the invention lies in a technological innovation whereby a technical problem is solved within or outside a computer. The combination highlighted by the applicant of a chain of digital signatures and blockchain utilized by the central network node to increase the security and trust in the network does not address a technical problem. To my mind, these results exist due to the rules imposed by the central authority rather than any technical nature of the invention. While there can be no doubt that “technological” steps are performed by the central network node (and, indeed, by the other computers and network elements claimed), it is to address business requirements rather than technical ones. The substance of the invention is an administrative arrangement involving the creation of a centrally controlled conglomeration of banks having specific rules around the transfer of assets between them.
Contribution made by the claimed invention to the state of the art is technical in nature
I disagree with the applicant’s submission that a technical contribution to the state of the art of electronic transaction systems has been made. Putting to one side the fact that the specification does not describe previously known electronic transaction systems, or that they required end users to validate signatures each time a transfer is made, the contribution made by the invention lies in the business arrangement of, and rules associated with, a centrally controlled conglomeration of banks. It is the rules that provide the advantages that may exist. The technological state of the art of electronic transaction systems remains unchanged.
For completeness, I note the applicant’s submission that a central entity validates the digital signatures of issuers and indicates that it has validated the issuer’s digital signature by applying a second digital signature. The submission is that this action absolves the recipient from undertaking the validation of the issuer’s signature, which therefore reduces the processing required by (non-described) “typically slower end user devices”. The conclusion I am invited to draw is that this increases the speed of the electronic transactions compared to previously known solutions. However, this is not borne out by the claims. The claims require the recipient node computer to verify that the first digital signature was generated by the issuer node computer, and to verify that the second digital signature was generated by the administrative node computer. There is no “absolution”.
Moreover, and notwithstanding these comments on the claims, for the invention in general I do not see how the invention’s approach could take less computing resources than the prior art’s approach. For the invention, it is up to the recipient whether they validate the issuer’s signature (for even better security and trust) or not (thus trusting that the central authority has already validated the issuer’s signature). Even if the recipient decides not to validate the issuer’s signature, at least one signature (i.e. that of the central authority) needs to be validated. This is the same number of signatures that need to be validated with the prior art’s supposed approach. In other words, I cannot see how creating two digital signatures instead of one could result in less computing resources being required when only one needs to be validated.
Claimed invention solves a technical problem with a technical solution
Given my conclusion that the contribution to the art is not technical in nature, it is difficult to conclude that the invention solves a technical problem with a technical solution. The problem of a lack of trust by the recipient node computer that the source node computer would fulfil an electronic transaction is not a technical problem. Moreover, I cannot locate anywhere in the specification any mention of a technical problem or technical limitation that was encountered in seeking to increase the trust level of the recipient which might have required a technical solution. What I can see is the business decision to establish a centrally controlled conglomeration of banks with transaction rules that seek to address this trust issue.
The action of a central network node that is, apparently, known and trusted by the recipient (which, as an apparent default position, does not have enough trust in the issuer) of adding a second digital signature and publishing a blockchain are, effectively, business actions of verification and recordation in a ledger, carried out using well-known computers and network elements operating in their well-defined ways. As it stands, the arrangement claimed is not technologically distinct from the common general knowledge technology existing in well-known bank-to-bank networks. What has been added is a business structure of a central authority responsible for enrolment of parties wishing to participate in the banking network. I do not see the claimed invention as solving trust problems in any technical way.
Technical advantages
To my mind, the technical advantages highlighted by the applicant are not technical. The applicant submitted that the receiving institution having a high level of trust in the digital asset because the central authority validated the issuer’s digital signature meant that the digital asset amount could be made available immediately in the recipient account, even if settlement had not yet occurred. The applicant stated that this greatly reduced the time required to complete a digital transaction compared to transactions in the past. However, time for transfer is a product of the rules that are in place for any transaction. Clearly, if the rules are changed, then so is the time taken for the transfer to occur.
In the prior art, the time taken was based upon a lack of trust. The applicant has sought to increase trust in what I see as a non-technical way by changing the business structures involved and the transaction rules. The applicant has not sought to address any limitations in technical elements that were preventing trust being established. Indeed, the lack of details accompanying the discussions around the technical elements of the claim (see [15], [22] an [24] above) reinforce my impression that there are no technical limitations.
Moreover, this impression is further fortified by the applicant’s reference to the central enrolment process, compliance-screening of participating entities, standardised communications, universal identifiers uniquely identifying entities, and the use of a distributed ledger as aspects that reduced the time for transfer. These are clearly business arrangements and requirements. The applicant has developed a business structure.
Similarity to ANT
As I have noted in previous decisions[33], 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 would appear to be seeking to use decisions of the Commissioner to effectively supplant the principles developed by the Courts. That being said, in the present case, whether referring to the principles developed by the Courts, or by comparing the present invention to that in ANT, the outcome is the same. I will, therefore, seek to address the submissions made by the applicant on this decision.
[33] CareFusion 303, Inc. [2023] APO 17 for example
From my considerations above, it is unsurprising that I do not agree with the applicant that the present invention is analogous to the invention considered in ANT. As I have previously stated, the claimed invention does not provide a technical solution to the problem of trust and security in previously known transaction systems. Contrary to the delegate in ANT, I do not consider that any of the method steps of the present invention include technical steps of the kind that establish patentable subject matter.
As noted by the examiner in their fourth report:
“The Delegate in ANT found that the invention provided a technical solution within the blockchain involving the use of cryptographic techniques to address the issue of breach of privacy information from a node participating in a blockchain transaction.
The cryptographic techniques of ANT involved the signing of a data abstract by a plurality of transaction nodes. The character string of the data abstract changed after each signature such that the character string depended on the order in which it was signed by the nodes. This ‘nesting’ of the digital signatures was the technical solution.”
This is very different to the present invention. In the present matter, while the digital asset is signed by the issuer and administrative nodes, unlike the invention in ANT, they are independent. No “nesting” is present. The way the technical features are used in the present claims is not the same as the way technical feature are used in ANT. I cannot see any analogy between the facts of ANT and that of the present application.
Conclusion
It follows that the invention as claimed in the independent claims is not a manner of manufacture. It is, in substance, an administrative arrangement in the form of a business structure of a centrally controlled conglomeration of banks having specific rules around the enrolment of parties into the conglomeration and around the transfer of assets between them. The transfer of assets is accomplished using generic computing technology used for its well-known and well-understood functions. The arrangement is not directed to any technological problem and the implementation does not achieve any technical advantages or effects capable of giving rise to patentable subject matter.
This finding is not avoided by any of the dependent claims. Details about the transfer between the issuer institution computer, the recipient institution computer and the various nodes of the network (as per claims 2, 3, 6, 7, 9, 10, 12 and 15), the settlement process of the business structure (as per claims 4 and 16), the enrolment process (as per claim 5), and the addition of a block to a blockchain (as per claims 11, 13 and 14) are merely further administrative details as to the administrative arrangement that is the substance of the invention. Moreover, claims 17 and 18 effectively define “putting” the administrative scheme defined in these claims “into” a computer. Accordingly, they do not define a manner of manufacture.
Conclusion

The claims do not define a manner of manufacture. The claimed invention is, in substance, a mere administrative arrangement 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.
Additional observation
As to the divisional application 2023200072 that was filed by the applicant shortly after requesting to be heard, while issue estoppel does not apply to proceedings before the Commissioner of Patents, it may be assumed that the present decision will be highly relevant to examination of this divisional application.
Greg Powell
Delegate of the Commissioner of Patents
Annex
1.        A method comprising:
enrolling, by an administrative node computer, an issuer node computer and a recipient node computer for participation in an asset transfer network, where the administrative node computer is a trusted central administrator for the asset transfer network, and where the enrolling includes:
generating a first key pair including a first private key and first public key; and
providing the first private key to the issuer node computer;
receiving, by the administrative node computer, from the issuer node computer, a digital asset and a first digital signature for the digital asset, the digital asset including a sender identifier of a sender, a recipient identifier of a recipient, and an amount to pay the recipient by the sender, wherein the first digital signature for the digital asset was generated by the issuer node computer by digitally signing at least some information of the digital asset with the first private key associated with the issuer node computer in response to the issuer node computer receiving a request from a sending institution computer holding a first account of the sender, and wherein the first digital signature serves as a first guarantee by the issuer node computer;
validating, by the administrative node computer, the digital asset by analyzing the sender identifier of the sender, the recipient identifier of the recipient, and the amount;
verifying, by the administrative node computer, authenticity of the first digital signature for the digital asset with the first public key associated with the issuer node computer, the first public key corresponding to the first private key;
after validating the digital asset and verifying the authenticity of the first digital signature for the digital asset, generating, by the administrative node computer, a second digital signature for the digital asset by digitally signing the at least some information of the digital asset with a second private key associated with the administrative node computer, wherein the first digital signature and the second digital signature are both generated by digitally signing the same digital asset but with different private keys, and the second digital signature serves as a second guarantee by the administrative node computer;
generating, by the administrative node computer, a block for a blockchain, the block including information about the digital asset, the first digital signature, and the second digital signature, wherein the recipient node computer obtains the digital asset, the first digital signature, and the second digital signature from the blockchain, wherein the recipient node computer uses the first public key associated with the issuer node computer to verify that the first digital signature was generated by the issuer node computer, uses a second public key associated with the administrative node computer to verify that the second digital signature was generated by the administrative node computer, and wherein the recipient node computer transmits the digital asset to a recipient institution computer holding a second account of the recipient, wherein the recipient institution computer immediately credits the second account of the recipient with the amount indicated in the digital asset even if the amount has not actually been received from the first account of the sender; and
after generating the block, coordinating a transfer of funds including the amount from the first account of the sender to the second account of the recipient.
2.        The method of claim 1 where the recipient node computer provides the first digital signature to the recipient institution computer holding the second account of the recipient.
3.        The method of claim 1, further comprising:
providing the digital asset and the second digital signature to the issuer node computer, where the issuer node computer provides the digital asset and at least one of the first digital signature and the second digital signature to the recipient node computer.
4.        The method of claim 1, wherein coordinating the transfer of funds includes performing a settlement process between the recipient institution computer holding the second account of the recipient and the sending institution computer holding the first account of the sender according to the digital asset, wherein the settlement process utilizes accounts at a central bank, where the settlement process comprises debiting the amount from a sending institution account at the central bank and crediting the amount to a recipient institution account at the central bank, and where the sending institution account is associated with the sending institution computer and the recipient institution account is associated with the recipient institution computer.
5.        The method of claim 1, further comprising:
providing, by the administrative node computer, to the issuer node computer, the first private key and the first public key during an enrolling process; and
providing, by the administrative node computer, the first public key and the second public key to the recipient node computer.
6.        The method of claim 1, wherein the recipient node computer uses the sender identifier to lookup the first public key.
7.        The method of claim 1, wherein the sender and the recipient reside in different countries, wherein the sender identifier of the sender is a first globally unique identifier, and the recipient identifier of the recipient is a second globally unique identifier.
8.        A method comprising:
enrolling, by an issuer node computer, with an administrative node computer for participation in an asset transfer network, where the administrative node computer is a trusted central administrator for the asset transfer network, and where the enrolling includes:
receiving a first private key from the administrative node computer;
receiving, by the issuer node computer, from a sending institution computer holding a first account of a sender, a request to transfer an amount from the sender to a recipient;
generating, by the issuer node computer, a digital asset including a sender identifier of the sender, a recipient identifier of the recipient, and the amount to pay the recipient by the sender;
generating, by the issuer node computer, a first digital signature for the digital asset by digitally signing at least some information of the digital asset with the first private key associated with the issuer node computer, the first digital signature serving as a first guarantee by the issuer node computer; and
sending, by the issuer node computer, to the administrative node computer, the digital asset and the first digital signature for the digital asset, wherein the administrative node computer validates the digital asset, verifies authenticity of the first digital signature for the digital asset with a first public key associated with the issuer node computer, the first public key corresponding to the first private key, wherein the administrative node computer, after validating the digital asset and verifying the authenticity of the first digital signature, generates a second digital signature for the digital asset by digitally signing the at least some information of the digital asset with a second private key associated with the administrative node computer, the second digital signature serving as a second guarantee by the administrative node computer, wherein the first digital signature and the second digital signature are both generated by digitally signing the same digital asset but with different private keys, wherein the administrative node computer generates a block for a blockchain, the block including information about the digital asset, the first digital signature, and the second digital signature, wherein the recipient node computer obtains the digital asset, the first digital signature, and the second digital signature from the blockchain, uses the first public key associated with the issuer node computer to verify that the first digital signature was generated by the issuer node computer, uses a second public key associated with the administrative node computer to verify that the second digital signature was generated by the administrative node computer, and wherein the recipient node computer transmits the digital asset to a recipient institution computer holding a second account of the recipient, wherein the recipient institution computer immediately credits the second account of the recipient with the amount indicated in the digital asset even if the amount has not actually been received, and wherein, after generating the block, the administrative node computer coordinates a transfer of funds including the amount from the first account of the sender to the second account of the recipient.
9.        The method of claim 8, further comprising:
informing, by the issuer node computer, the sender that the digital asset was sent.
10.      The method of claim 8, further comprising:
receiving, by the issuer node computer, the second digital signature from the administrative node computer; and
providing, by the issuer node computer, the digital asset to the recipient node computer.
11.      The method of claim 8, wherein the administrative node computer generates the block for the blockchain after all transactions in the block have been validated by nodes in the asset transfer network using a Simplified Byzantine Fault Tolerance process.
12.      The method of claim 8, wherein the sender and the recipient reside in different countries.
13.      The method of claim 8, wherein the block is a first block, and wherein the blockchain is a first blockchain, and further comprising:
generating, by the issuer node computer, a second block for a second blockchain, the second blockchain being different than the first blockchain, the second block including the information about the digital asset, the first digital signature, and the second digital signature.
14.      The method of claim 8, wherein the blockchain is part of a global ledger containing transactions conducted with multiple node computers comprising the issuer node computer, wherein the issuer node computer is only able to view transactions on the global ledger that are conducted by the issuer node computer.
15.      The method of claim 8, wherein the sender identifier of the sender is a first globally unique identifier, and the recipient identifier of the recipient is a second globally unique identifier.
16.      The method of claim 8, wherein coordinating the transfer of funds includes performing a settlement process between the recipient institution computer holding the second account of the recipient and the sending institution computer holding the first account of the sender according to the digital asset, wherein the settlement process utilizes accounts at a central bank, where the settlement process comprises debiting the amount from a sending institution account at the central bank and crediting the amount to a recipient institution account at the central bank, and where the sending institution account is associated with the sending institution computer and the recipient institution account is associated with the recipient institution computer.
17.      The issuer node computer comprising:
a processor; and
a computer readable medium, the computer readable medium comprising code, executable by the processor, for implementing the method according to any of claims 8-16.
18.      The administrative node computer comprising:
a processor; and
a computer readable medium, the computer readable medium comprising code, executable by the processor, for implementing the method according to any of claims 1-7.