Intuit Inc. - [2022] APO 26

IP AUSTRALIA

AUSTRALIAN PATENT OFFICE

Intuit Inc. [2022] APO 26

Patent Application: 2018276025

Title:System for managing transactional data

Patent Applicant: Intuit Inc.

Delegate: Dr W.E. Guinea

Decision Date: 8 April 2022

Hearing Date: Written submissions filed 10 March 2022

Catchwords: PATENTS – standard patent – Examiner objections – manner of manufacture – substance of the invention resides in a scheme for storage and access of financial transaction data – all claims lack a manner of manufacture – no patentable subject matter in application – application refused.

Representation: Patent attorney for the applicant: Davies Collison Cave Pty Ltd

IP AUSTRALIA

AUSTRALIAN PATENT OFFICE

Patent Application: 2018276025

Title:System for managing transactional data

Patent Applicant: Intuit Inc.

Date of Decision: 8 April 2022

DECISION

None of the claims are for a manner of manufacture. There is no material within the application that would lead to a manner of manufacture if made the subject of a claim. The application is refused.

REASONS FOR DECISION

Background

Patent application 2018276025 (the “application”) entered national phase from PCT/US2018/030137 on 15 October 2019, in the name of Intuit Inc. (the “Applicant”). The application has an earliest priority date of 31 May 2017.
Examination of the application was requested on 18 October 2019. The first of four adverse examination reports issued on 19 August 2020, with the second examination report issuing on 4 February 2021, the third examination report issuing on 13 July 2021 and the fourth report issuing on 18 August 2021. All these reports objected to the claims as not being for a manner of manufacture, and this remains the only objection outstanding on the application.
On 19 August 2021, the Applicant wrote to the Commissioner requesting to be heard in relation to the outstanding objection. On 20 January 2022, the Commissioner wrote to the Applicant, advising them that the hearing would be by way of written submissions due to be filed five weeks from that date. The Applicant requested, on 16 February 2022, a further two weeks, for filing submissions, this request being granted. The Applicant subsequently filed their submissions on 10 March 2022 (the “submissions”).
The Applicant also filed proposed amendments with the submissions. As I see no issue with the allowability of these proposed amendments, this decision is made with respect to the specification as currently proposed to be amended.

The Invention as Described

The application deals with what may be broadly understood as a method and system for storing and accessing financial transaction data. As discussed at pages 1 to 2 of the description, the invention apparently seeks to address existing deficiencies regarding access to financial transaction data:
“Current standards for exchanging transactional information (e.g., the Open Financial Exchange (OFX), a framework for exchanging financial transactional data and instructions between customers and their financial institutions) do not support the capability to obtain detailed transactional information associated with users. That is, while aggregate-level transactional information may be accessible (e.g., a payment amount of a transaction), transaction details (e.g., line items purchased) are typically unavailable.
In addition, current standards for exchanging financial transactional data typically require point-to-point connections, which grow proportionally with the number of participating organizations, thereby creating bottlenecks. For example, while a point-to-point architecture may be sufficient to support a user’s interactions with a few financial institutions, when the architecture is opened to an arbitrary number of service providers, a point-to-point architecture may become unwieldy. Furthermore, substantial overhead may be required to authenticate numerous participants and maintain participant accounts.
Accessing detailed transactional information associated with users is typically based on a ‘pull’ model driven by explicit requests (e.g., to financial institutions). The detailed transactions may be dispersed across multiple service providers, and it may be difficult or impossible to collect such detailed transactions in a timely manner. This difficulty hinders access to detailed transaction information, which could be used to support analytics and insights.
It is generally desirable to overcome or ameliorate one or more of the above described difficulties, or to at least provide a useful alternative.”
The nature of the invention as described is best understood by reference to figures 1 to 6B, which are reproduced below where appropriate.
As can be seen on figure 1, the invention comprises a system 100 that links together, for the purposes of storing and accessing financial transaction data, users 102a-102n, service providers 104a-104n and financial institutions 114a-114n using a registry 106, transaction storage devices 108a-108n and access controller 110. The users 102 may be any entity that purchases goods and services from any entity that provides such goods and services i.e. the service providers 104. The financial institutions 114 comprise banks, credit card issuers and the like that provide financial services to the user 102 as known in the art. The transaction storage devices 108 may comprise any type of data storage and can include multiple different storage units or devices. Each of the transaction data storage devices 108 may have a data store 118 that stores information about transactions. The registry 106 may also include any type of data storage known in the art. Each of these components of the system 100 may communicate using a computer network, as outlined, for example, on figure 6B.

Importantly for the working of the invention, the registry 106 comprises a data store map 112 that maps secure identifiers 116a-116x, for each of the users 102a-102n, to respective universal resource identifiers (“URIs”) 120a-120n. The URIs 120 provide some means, for example a network location, for determining a location of a data store 118 that stores detailed transactions (figure 2C, 250) associated with a secure identifier 116. The secure identifiers 116 could nominally be anything that identifies a user 102 in some way, such as a credit card number, telephone number or email address, and could be generated using encryption techniques, for example hashing, or via other ways of processing a user identifier, for example removing blank spaces in an email address. The use of encryption techniques means sensitive user information is not at risk if the registry 106 is compromised.
Thus, it can be seen that a user 102 may be associated with a secure identifier 116, which in turn is associated with a URI of a data store 120 that provides the location of a data store 118 comprising detailed financial transaction 250 information associated with the user 102. As discussed further below, the system 100 provides for storage of and access to, detailed transactions 250 of a user 102 in data store 118.

10. In use the registry 106 can process a variety of requests that enable or make use of the system 100. For example, the user 102 may request to register a URI of a data store 120 with a secure identifier 116, or a service provider 104 may request to look up the URI of a data store 120 associated with a secure identifier 116 and thereby gain access to detailed transactions 250 associated with a user 102. Another example of a request using the system 100 is given in figure 3, reproduced below, where an entity, for example a user 102 or a service provider 104, requests to “push” detailed transaction data 300 i.e. store a detailed transaction 250 corresponding to a secure identifier 116, and the detailed transaction 250 is stored 302 in view of trusting the entity based on a security rule corresponding to a type of secure identifier to the request. Further particular examples of how the system 100 may be used to process a detailed transaction 250 are given on figures 4A and 4B.

11. It is also apparent, from page 18 of the specification, that the data store 118 may also be able to process a variety of requests:

“Returning to FIG. 1, in one or more embodiments, a data store (118a-118n) includes functionality to process a request to push (e.g., store) detailed transactions (250) corresponding to a secure identifier (116a-116n). In one or more embodiments, a data store (118a-118n) includes functionality to process a request from a user (102a-102n) to lookup detailed transactions (250) corresponding to a secure identifier (116a-116n). In one or more embodiments, a data store (118a-118n) includes functionality to process a request from a service provider (104a-104n) to lookup detailed transactions (250) corresponding to a secure identifier (116a-116n). For example, the service provider (104a-104n) may be explicitly authorized by a user (102a-102n) to perform analytics on the detailed transactions (250) corresponding to the user (102a-102n) in the data store (118a-118n).”

12. As illustrated by figure 3, and with reference to figures 2A to 2D, use of and access to the system 100 by an entity may be subject to a variety of “rules” that specify how and when access may be granted. For example, with reference to figure 2A, which is reproduced below, the registry 106 may comprise a security profile 202 that stores identifier types 208a-208n specifying the type of user identifier corresponding to a secure identifier 116 and respective security rules 210a-210n that may specify an access control procedure undertaken by the access controller 110 based on the target 212a-212n of the request. The target could be, for example, the registry 106 or a data store 118. In general, the security rule 210 could specify when a variety of access control procedures apply or the access/use rules in general, for example: a certain form of access control to be used when a specific secure identifier 116 is included in a request; specifying that the target is any or a particular data store 118; or that there are multiple rules associated with an identifier type 208.

13. Some further means as to how the access controller 110 provides for secure access and use of the system 100 is illustrated in figure 2B, which is reproduced below. Here it can be seen that the access controller 110 may also comprise a whitelist 224 of trusted entities 230a-230n, a greylist 226 of entities 230b-230x who have incurred negative events, for example attempting to store invalid data in data store 118, and an access profile 228. The access profile 228 includes information, for example, regarding the access of the various entities 230a-230n to the system 100. This could include the number of requests 236a-236n associated with each of the entities 230a-230n to the registry 106. There may also be tokens 234a-234n associated with each of the entities 230a-230n, which may be used to transmit a challenge in response to an access request by the entities 230a-230n. An example of an access control process, including a challenge, is provided in figures 4C and 4D.

14. Similarly, further features of the transaction storage device 108 are illustrated on figure 2C, which is reproduced below. As discussed, the data store 118 may comprise detailed transactions 250 associated with a secure identifier 116. The transaction storage device 108 also comprises a transaction validator 242 to determine the validity of detailed transaction 250, an alerter 244 to provide an alert in view of a new detailed transaction 250, and a user secure identifier lists 246. The user secure identifier lists may comprise user logins 248u-248w, and a list of secure identifiers 116a-116e, 116k-116q for each of the respective user logins 248u-248w, associated with an account in data store 118 corresponding to a user 102.

15. Figure 2D, which is reproduced below, provides data that may be included in the detailed transaction 250. Most of these data items are self-explanatory and need not be elaborated on. Suffice to state that each line item 260a-260n in each detailed transaction 250 may comprise additional data as indicated in the figure.

16. The preceding discussion outlines the salient features of the invention as described. As indicated, figures 4A and 4B provide flowcharts outlining a process for managing a detailed transaction 250 according to the invention described, for example using the system 100. These figures are reproduced below. I consider that these are largely self-explanatory, in view of the discussion of the system 100 provided above, so no further elaboration is provided here.

17. As also indicated, figures 4C and 4D illustrate an access control process that may be implemented in embodiments of the invention, for example using the system 100. As discussed in the description at page 23, the step “is the entity trusted?” 422 from figure 4B may be determined by the access controller 110 using the process outlined in figures 4C and 4D. These figures are reproduced below. Again, I consider that these figures are self-explanatory in view of the discussion of the system 100, so no further elaboration is provided.

18. Figures 5A to 5C illustrate an example of a particular implementation of the invention described. As discussed at page 28:

“FIG. 5A illustrates, in accordance with one or more embodiments, the relative timing of steps performed by one or more components described in reference to FIG. 1, FIG. 2A, FIG. 2B, FIG. 2C, and FIG. 2D, in accordance with the flowcharts in FIG. 3, FIG. 4A, FIG. 4B, FIG. 4C, and FIG. 4D. These components include: Bright Bookworm, a small bookseller that is a user (502) ((102a-102n) in FIG. 1), Real Retail, a service provider (504) ((104a-104n) in FIG. 1), a registry (506) ((106) in FIG. 1), and Finance Galaxy (508), a financial application with data store capabilities.”

19. Figures 5A to 5C are reproduced below and are, in my view, largely self-explanatory in view of the preceding discussion of the invention as described. Suffice to note that, as seen from figure 5B, registry 560 comprises a data store map 570 (commensurate with data store map 112 of figure 1) including a secure identifier 572 (commensurate with secure identifier 116 of figure 1) and a URI of Finance Galaxy 574 (commensurate with URI of data store 120 in figure 1, noting that Finance Galaxy provides data store capabilities). It should also be noted that figure 5C illustrates a detailed transaction 576 (commensurate with detailed transaction 250).

20. Figure 5D also provides an example of a particular implementation of the invention described, with particular focus on the role of the access controller in the scenario from figure 5A. As indicated at page 30 of the description:

“FIG. 5D illustrates, in accordance with one or more embodiments, the relative timing of steps performed by one or more components described in reference to FIG. 1, FIG. 2A, FIG. 2B, FIG. 2C, and FIG. 2D, in accordance with the flowcharts in FIG. 3, FIG. 4A, FIG. 4B, FIG. 4C, and FIG. 4D. These components include: Real Retail, a service provider (504) ((104a-104n) in FIG. 1), the registry (506) ((106) in FIG. 1), Finance Galaxy, a data store (508) ((118a-118n) in FIG. 1), and an access controller (510) ((110) in FIG. 1). FIG. 5D in particular illustrates the role of the access controller (510) within the context of the scenario shown in FIG. 5A. FIG. 5D in particular illustrates the role of the access controller (510) within the context of the scenario shown in FIG. 5A. FIG. 5D particularly relates to the request by Real Retail (504) to lookup the address of the data store registered with the secure identifier (572) in the registry (506) in Step 528 of FIG. 5A, and the request by Real Retail (504) to push a detailed transaction to Finance Galaxy (508) in Step 534 of FIG. 5A.”

21. Figure 5D is also reproduced below. I consider this figure to be self-explanatory in view of the discussion of the system 100 and within the context of figure 5A, so no further elaboration is provided here.

It is quite clear from the discussion of the invention as described that the implementation of the system 100 is not particularly limited, in terms of structure or function, by this discussion or by the particular examples provided in figures 4A to 5D, and is left entirely up to the skilled addressee. This is exemplified by the following passages:
“While FIG. 1, FIG. 2A, FIG. 2B, FIG. 2C, and FIG. 2D show configurations of components, other configurations may be used without departing from the scope of the invention. For example, various components may be combined to create a single component. As another example, the functionality performed by a single component may be performed by two or more components.” (page 18)
“FIG. 4A shows a flowchart in accordance with one or more embodiments of the invention. The flowchart depicts a process for transaction management. In one or more embodiments, the process described in reference to FIG. 4A is practiced using the system (100) (e.g., the registry (106), a transaction storage device (108), a data store (118), and the access controller (110)) described in reference to FIG. 1, FIG. 2A, FIG. 2B, FIG. 2C, and FIG. 2D above, and/or involving the computing system (600) described in reference to FIG. 6A. In one or more embodiments of the invention, one or more of the steps shown in FIG. 4A may be omitted, repeated, and/or performed in a different order than the order shown in FIG. 4A. Accordingly, the scope of the invention should not be considered limited to the specific arrangement of steps shown in FIG. 4A.” (page 21)
“The following example is for explanatory purposes only and not intended to limit the scope of the invention. FIG. 5A, FIG. 5B, FIG. 5C, and FIG. 5D show an implementation example in accordance with one or more embodiments of the invention.” (page 28)

A virtually identical characterisation to that of figure 4A is provided for figures 4B, 4C and 4D.

23. It is also clear from the specification as a whole, that the technical means used to implement the invention is entirely up to, and is only limited by what is at the disposal of, the skilled addressee. This is quite apparent from the discussion of figures 6A and 6B, which are reproduced below:

“Embodiments disclosed herein may be implemented on a computing system. Any combination of mobile, desktop, server, router, switch, embedded device, or other types of hardware may be used. For example, as shown in FIG. 6A, the computing system (600) may include one or more computer processors (602), non-persistent storage (604) (e.g., volatile memory, such as random access memory (RAM), cache memory), persistent storage (606) (e.g., a hard disk, an optical drive such as a compact disk (CD) drive or digital versatile disk (DVD) drive, a flash memory, etc.), a communication interface (612) (e.g., Bluetooth interface, infrared interface, network interface, optical interface, etc.), and numerous other elements and functionalities.” (page 32)
“The computing system (600) in FIG. 6A may be connected to or be a part of a network. For example, as shown in FIG. 6B, the network (620) may include multiple nodes (e.g., node X (622), node Y (624)). Each node may correspond to a computing system, such as the computing system shown in FIG. 6A, or a group of nodes combined may correspond to the computing system shown in FIG. 6A. By way of an example, embodiments disclosed herein may be implemented on a node of a distributed system that is connected to other nodes. By way of another example, embodiments disclosed herein may be implemented on a distributed computing system having multiple nodes, where each portion disclosed herein may be located on a different node within the distributed computing system. Further, one or more elements of the aforementioned computing system (600) may be located at a remote location and connected to the other elements over a network.” (page 33)

“The above description of functions present only a few examples of functions performed by the computing system of FIG. 6A and the nodes and/ or client device in FIG. 6B. Other functions may be performed using one or more embodiments disclosed herein.” (page 35)

The Claims

24. Several amendments have been proposed to the application during examination. After the latest proposed amendments, the application as proposed to be amended comprises 19 claims, of which claims 1, 7 and 14 are independent claims. Claim 1 is reproduced below. The entire claim set is given at Annex A to this decision.

“A computer system for data exchange between multiple entities, comprising:
a plurality of transaction storage devices, each transaction storage device of the plurality of transaction storage devices comprising a data store configured to:
receive, from a first entity, a request to push a detailed transaction corresponding to a secure identifier,
wherein the secure identifier is generated, using an encoding function, from a user identifier of a user,
wherein the detailed transaction identifies at least one selected from a group consisting of products and services received by the user from the first entity;
validate the detailed transaction using metadata from the first entity; and store the detailed transaction based on a first determination to trust the first entity after validating the detailed transaction;

an access controller configured to:
perform the first determination by applying a first security rule corresponding to a type of the secure identifier to the request to push the detailed transaction; and
determine, based on the first security rule indicating that an identity check should be performed, whether the number of entries corresponding to the first entity in a greylist exceeds a threshold; and

a registry configured to store at least the first security rule; wherein the registry is further configured to:
receive, from the user, a request to register a universal resource identifier (URI) of a first data store with the secure identifier, wherein the registration request is determined to be valid upon presentation of a validation token obtained from a financial institution;
store the URI of the first data store with the secure identifier;
receive, from a second entity, a request to lookup a data store registered with the secure identifier;
retrieve the URI of the first data store in response to the request to lookup the data store; and
transmit the URI of the first data store to the second entity, based on a second determination to trust the second entity, wherein the second determination comprises applying a second security rule corresponding to the type of the secure identifier to the request to lookup the data store, wherein the second determination is performed by the access controller;

a service provider configured to provide the request to push the detailed transaction to the data store when the access controller trusts the service provider.”

The Remaining Objection

25. As noted, the only objection outstanding is that the claims are not for a manner of manufacture. This objection has been pursued throughout all three examination reports. The reasoning presented by the Examiner has remained largely consistent throughout all four reports. The first report provides a detailed basis for the objection, while reports two to four fine tune the arguments in view of amendments and submissions made by the Applicant. It is apparent, from the reports, that the objection may be summarised, in a general way, as alleging that the claimed invention is, in substance, a scheme, that provides for storing financial transaction data based on associating a URI of the data location with an identifier of the user and then providing access based on certain rules. This is perhaps best illustrated by the following passages from the first examination report:

“From reading the specification as a whole, and given that the substance of the present claims lies in a scheme for storing transactional data according to a security rule corresponding to a type of secure identifier, it is clear that the claimed invention adds nothing to the art in terms of technical improvements. The present invention merely makes use of the conventional properties of the involved computer systems in order to carry out the steps of the scheme in the normal and expected way. Therefore it cannot be said that the present invention solves a technical problem within the computer, or that it improves the operation of the computer irrespective of the data being processed, as discussed in RPL at [099].”

The Applicant’s Submissions

26. The submissions cover a number of matters, the bulk of which comprise a discussion of the invention as described and claimed, including the background to the invention, and a discussion of why, in substance, the Applicant considers that the invention is patentable contrary to the Examiner’s conclusions. The submissions on patentability were based, as I understood it, on Full Court authorities such as Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150 (“Research Affiliates”), Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (“RPL”) and Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 (“Aristocrat”), as well as the High Court in D'Arcy v Myriad Genetics Inc [2015] HCA 35 (“Myriad”). I therefore did not take the Applicant as putting forward principles to be applied that are materially different from those I have adopted below. I will address the Applicant’s submissions regarding the application of the relevant principles to the facts of this matter in my assessment of the substance below.

27. Similarly, I did not take the Applicant’s discussion of the invention, either as claimed or described, to extend to anything materially beyond what is discussed earlier in this decision. To the extent necessary I will address these where appropriate below.

28. The remainder of the submissions deal with the allowability of the amendments and a request for further examination if this decision is adverse to the Applicant. As noted, I consider the amendments are allowable, so nothing further need be said on the Applicant’s submissions in that regard. As to the possibility of further examination pursuant to Reg 13.4, I will address that later in this decision if this proves necessary.

Relevant Legal Principles

Manner of Manufacture

29. The statutory basis for manner of manufacture is found at s18(1)(a) of the Patents Act 1990 (the “Act”) which states:

“an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies.”

30. Fundamental principles with respect to manner of manufacture were outlined by the High Court in National Research Development Corporation v Commissioner of Patents [1959] HCA 67 (“NRDC”) at [14];102 CLR 252 at 275:

“It is therefore a mistake, and a mistake likely to lead to an incorrect conclusion, to treat the question whether a given process or product is within the definition as if that question could be restated in the form: ‘Is this a manner (or kind) of manufacture?’ It is a mistake which tends to limit one's thinking by reference to the idea of making tangible goods by hand or by machine, because ‘manufacture’ as a word of everyday speech generally conveys that idea. The right question is: ‘Is this a proper subject of letters patent according to the principles which have been developed for the application of s. 6 of the Statute of Monopolies’”

31. The NRDC decision related to a process for eradicating weeds from crop areas. A test applicable to the facts of this case was given in NRDC at [22], 275:

“The point is that 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 (see Re Virginia-Carolina Chemical Corporation's Application (1958) RPC 35, at p 36) - that its value to the country is in the field of economic endeavour.”

32. In Grant v Commissioner of Patents [2006] FCAFC 120 (“Grant”) the court considered the patentability of what may be generally described as a business system or method directed towards protecting assets via the creation of a trust, this not involving any computer implementation. Their Honours in Grant (at [26]) did not consider the question as to whether a business system is or is not patentable. Rather they found (at [47]) Mr Grant’s claimed systems and methods were not for a manner of manufacture in the sense described in NRDC:

“It has long been accepted that ‘intellectual information’, a mathematical algorithm, mere working directions and a scheme without effect are not patentable. This claim is ‘intellectual information’, mere working directions and a scheme. It is necessary that there be some ‘useful product’, some physical phenomenon or effect resulting from the working of a method for it to be properly the subject of letters patent. That is missing in this case.”

33. More recently the authorities have directly considered the patentability, or otherwise, of computer implemented business methods, most notably in Research Affiliates and RPL. The discussion in RPL referred to the terminology from NRDC, with the observation at [117] that such terminology was apposite but “…not conclusive of patentability”. This observation was given with respect to consideration of a similar conclusion by the majority in Myriad at [23]:

“This Court in NRDC did not prescribe a well-defined pathway for the development of the concept of ‘manner of manufacture’ in its application to unimagined technologies with unimagined characteristics and implications. Rather, it authorised a case-by-case methodology. Consistently with that approach, and without resort to the ‘generally inconvenient’ proviso in s 6 of the Statute of Monopolies, there may be cases in which the court will decide that the implications of patentability of a new class of invention are such that the invention as claimed should not be treated as patentable by judicial decision”.

34. It was in this light that their Honours, at [96] to [98] of RPL, outlined considerations useful in determining whether a computer implemented business method is patentable:

“A claimed invention must be examined to ascertain whether it is in substance a scheme or plan or whether it can broadly be described as an improvement in computer technology. The basis for the analysis starts with the fact that a business method, or mere scheme, is not, per se, patentable. The fact that it is a scheme or business method does not exclude it from properly being the subject of letters patent, but it must be more than that. There must be more than an abstract idea; it must involve the creation of an artificial state of affairs where the computer is integral to the invention, rather than a mere tool in which the invention is performed. Where the claimed invention is to a computerised business method, the invention must lie in that computerisation. It is not a patentable invention simply to ‘put’ a business method ‘into’ a computer to implement the business method using the computer for its well- known and understood functions.
Is the mere implementation of an abstract idea in a well-known machine sufficient to render patentable subject matter? Is the artificial effect that arises, because information is stored in RAM and there is communication over the Internet or wifi, sufficient? Does any physical effect give rise to a manner of manufacture? Are the mere presence of an artificial effect and economic utility, without more, sufficient to determine manner of manufacture?
It is not a question of stating precise guidelines but of deciding, in each case, whether the claimed invention, as a matter of substance not form, is properly the subject of a patent.”

35. Thus, in relation to computer implemented inventions, it is necessary to look at the invention as a matter of substance, rather than as a matter of form. Upon doing so one will then be able to ascertain if this substance provides for a manner of manufacture using the established authorities. Relevantly RPL and Research Affiliates provided principles that assist in determining where the substance of these types of inventions resides and whether that material is patentable. In particular at [99] to [107] of RPL, their Honours reiterated a series of these principles from Research Affiliates (in particular at [94]). I note that the principles from Research Affiliates and RPL were recently cited with approval in Commissioner of Patents v Rokt Pte Ltd [2020] FCAFC 86 (“Rokt”) at [69], in Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223 (“Repipe2”) at [4], in Aristocrat at [29] and [106], and by an expanded Full Court in Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161 (“Encompass”) at [77] et seq.

36. Conveniently the principles concerned have been summarised at [189] of Rokt Pte Ltd v Commissioner of Patents [2018] FCA 1988 (“Rokt Pte Ltd”):

“The respondent submitted that the law as laid out in Research Affiliates and RPL Central held that:
‘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].’”

37. I note that the above principles were explicitly accepted by Robertson J at [201] of Rokt Pte Ltd. While the decision in Rokt Pte Ltd was overturned in Rokt this was not on the basis of any error in the principles listed above, which I accept are correct, noting that [189] of Rokt Pte Ltd represents a convenient summary of the principles from RA and RPL. I also note that essentially identical principles were adopted by McKerracher J in Repipe Pty Ltd v Commissioner of Patents [2019] FCA 1956 (“Repipe1”) at [39(5)], which was upheld in Repipe2, nor was there, as I understand it, any fundamental disturbance of the principles enunciated in Repipe1 as a result of Repipe2.

38. It is perhaps convenient here to note that the Applicant has made arguments, for example at paragraphs [126] to [131] of the submissions, about whether the invention produces a practical and useful result. It is perhaps of some note that “a practical and useful result” does not explicitly appear as one of the considerations in this decision, by virtue of its absence in Rokt, and what impact might have on this decision. In that regard I refer to what I said at [37] to [40] of Amsted Rail Company, Inc. [2021] APO 25 (“Amsted”) and what was said by the Deputy Commissioner in Grzegorz Malewicz [2022] APO 11 at [71] (“Grzegorz Malewicz”), as to the view that “a practical and useful result”, while not irrelevant to the analysis, is not necessarily determinative of patentability in a positive sense. I will return to this later in the context of the submissions concerned.

39. As indicated above, overall, I took the Applicant as accepting that the question is to be answered as a matter of substance, particularly in view of the considerations from RPL cited by the Applicant, and the further discussion of the principles at [68] to [70] of the submissions. While the precise considerations used by the Applicant, at [81] to [133] of the submissions, are expressed rather differently from the considerations in Rokt Pte Ltd, I do not take this to lead to material differences in terms of the conclusion to be drawn, noting that the principles from Rokt Pte Ltd are distilled from RPL and similar authorities.

Stringency of Tests

40. As examination was requested after 15 April 2013, the substantive amendments of the Act brought about by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 apply to the present application. In particular the amendments to s49 of the Act allow the Commissioner to refuse an application if she is not satisfied on the balance of probabilities that the invention, so far as claimed, satisfies the criteria of s18(1)(a). Notably, as I already mentioned, the criteria outlined at s18(1)(a) is that the invention, so far as claimed in any claim “is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies”.

Do the Claims Comprise a Manner of Manufacture?

41. I will initially consider this question with regard to independent claim 1 and will further consider the other independent claims and dependent claims as appropriate.

Claim 1

42. It is perhaps trite, but the fundamental question I need to answer is what does the claimed invention comprise as a matter of substance? I will now consider whether the claimed invention is patentable by recourse to the considerations at [189] of Rokt Pte Ltd. I will also consider, where appropriate, the Applicant’s submissions regarding factors outlined in the submissions. Where appropriate, I have tried to address the Applicant’s submissions as relevant for each of the factors I have outlined below, even where the Applicant has discussed these in connection with a different factor. References to the “claim” in the following discussion mean claim 1.

Is the contribution to the claimed invention technical in nature?

43. To assess this requires an understanding of the technical features of the invention, both individually and collectively, and the effect of carrying out the invention.

44. There are clearly individual features encompassed within each of the integers of the claim as identified above, that are either technical in nature or make use of technical features. For example, the computer system for data exchange between multiple entities that encompasses the remainder of the claim is clearly a computerised device. There are also various sub-elements within the claim that are expressions of computerised technology, in the form of hardware and/or software, such as the transaction storge devices, access controller and the registry. There are also actions undertaken within the claim, that make use of the ability of computers to exchange, process and store data, for example the “request to push a detailed transaction corresponding to a secure identifier”, determining “…based on the first security rule indicating that an identity check should be performed, whether the number of entries corresponding to the first entity in a greylist exceeds a threshold” and the “request to register a universal resource identifier (URI) of a first data store with the secure identifier”.

45. However, the computerised device(s) in the form of the computer system, the transaction storage devices, the access controller and the registry are not specified in any way in the claim. Selection of these is entirely up to the skilled addressee, who may utilise any such device or devices as known in the art using any suitable arrangement of these that may be devised by the skilled addressee. Similarly, the actions performed using the computerised devices simply relate to the processing, exchange or storage of data using the capabilities of computer systems as known in the art, particularly in view of the non-descript nature of the computerised devices as defined in the claim. I therefore take it that performing the actions concerned merely extends to the use of computer technology as well known in the art.

46. Consequently, to the extent there are individual technical features in, or made use of by, the claim, these merely extend to “…computer technology that is utilised for its basic, typical or well-known functions” (Rokt at [89]), and do not provide in substance a technical contribution to the invention.

47. It is now necessary to consider whether the claim as a whole or several sub features of the claim interact to provide a technical contribution. I do not see any collection of sub features that interact in such a way to provide for this. There is clearly interaction between several of the sub features in that some actions are dependent on other actions, for example registration of the URI of a first data store with a secure identifier needs to occur before that URI can be transmitted to the second entity. However, at the level of generality provided in the claim, these are merely logical dependencies between quite generalised steps in the claimed invention, in much the same way one needs to unlock their door before entering their house. No technical effect per se is apparent in such dependencies, merely steps to be followed. In addition, none of the interactions between or within the steps requires anything beyond the normal use of standard computing technology.

48. This leaves whether the claim, when considered as a whole, provides for a technical contribution. It is quite clear that the claim comprises a series of steps that involve the exchange, processing and storage of data that allows for financial transaction data of a user to be stored and accessed using a system whereby a URI of the storage location of where financial transaction data is stored/to be stored is linked to a secure identifier of the user, and the ability to store or access the financial transaction data is subject to particular security rules. Registering of a URI with the secure identifier is validated via presentation of a token from a financial institution, while the financial transaction data that is stored is also validated as part of the storage process.

49. Based on the discussion above, the claim appears little more than a system that provides in a certain way, subject to certain rules, for financial transaction data to be stored or accessed using computer technology as known in the art. While much use is made of computerised devices and systems as known in the art, no technical contribution is apparent.

50. The Applicant provided arguments relevant to this consideration at paragraphs [101] to [112] of the submissions. Here the Applicant argues, at [101], that the invention is technical in nature as “...the claimed invention provides a technical solution to a technical problem. As stated in Advanced New Technologies Co., Ltd. [2021] APO 29, just ‘because a technique may be well-known does not make it any less technical’”. Further elaboration on the Applicant’s submissions regarding this consideration, and why I disagree with them, are given below.

51. The Applicant argues at [102] and [103] that:

“The claimed invention requires the use of several technical integers which as a whole, all interact in a specific manner to address several technical problems of financial transaction systems. For example, the user identifier of a user is never stored on the registry or the data store but instead, a secure identifier is encoded from a hash of a user identifier that has been converted to a standardized format. The secure identifier may be generated via a one-way hash function that converts a variable-length input into a fixed-length binary sequence, such that it may be infeasible to retrieve the user identifier from the hashed binary sequence.
We submit that the use of a one-way hash function that converts a variable length input into a fixed-length binary sequence, is a technique in the field of information technology, and is used by the claimed invention to meet minimum standards with respect to security of sensitive user information.”

Similar arguments are provided with regard to other features of the claim, for example the token, the service provider, the registry and the data store, at [104] to [108].

52. The difficulty here for the Applicant is that the mere presence or use of technical features, in the form of security features or otherwise, does not necessarily provide for patentability. As noted above, the technical features of the claim are only specified to the extent necessary to take advantage of the usual capabilities of the technical elements concerned, which is really to say they are merely present to perform a function specified in the claim. While it makes no material difference to my view regarding this consideration, I also observe that the Applicant’s arguments are somewhat predicated on features that do not necessarily exist in the claim. For example, there is nothing in the claim that positively prevents the storage of a user identifier on the registry, but even if it did, this would merely be procedural in nature, not technical. Similarly, there is nothing in the claim that requires encoding of the user identifier to proceed by way of a hash function.

53. The Applicant also made submissions about the effect of the claimed invention as a whole, at [109] to [112] of the submissions:

“For completeness, we submit that whether any of the individual features which make up the claimed invention may be known technology is not relevant to the question of whether the solution is technical.
This was made clear in Commonwealth Scientific and Industrial Research Organisation [2021] APO 43, where the Delegate stated that ‘dissecting the claims into its individual features and then assessing whether each of these features is well known in the art’ is an erroneous approach and instead, what ‘needs to be assessed is the solution provided by the claim as a whole with due regard being given to the way the individual features interact with each other in addressing the problem that is sought to be addressed.’ The ‘critical thing is how these known techniques are applied in the context’ of addressing the problem to be solved.
Whilst we have individually referred to some of the features which make up the claimed invention, it would be understood that the individual features all interact with each other to address the problems outlined in the previous section. Specifically, they enable the claimed invention to facilitate data exchange between multiple entities in a manner, which overcomes the technical limitations faced by developers of financial transaction systems, and also provides a technical solution to the bottleneck problem and matching problem.
Accordingly, we submit that the claimed invention includes features which involve techniques in the field of information technology and, in combination, are intertwined to provide a technical solution to a technical problem.” (references to footnotes omitted)

54. However, it should be apparent that I do not consider that there is any technical contribution provided as such in the claim via the various technical features, whether considered individually or in combination, for reasons as discussed above. I am unconvinced that the claimed invention in any way necessarily addresses the problems of bottlenecks or the matching problem. With regard to bottlenecks, the fact that the precise architecture, in terms of hardware and software, is entirely up to the skilled addressee on implementing the invention means that there is no reason to suppose that the claimed invention necessarily addresses or overcomes bottleneck issues in existing systems. The skilled addressee may very well implement the claimed invention in a point to point like manner (which seems likely in view of the nature of the claimed invention) that may suffer from the similar issues as existing systems. Similar can be said for the “matching problem” regarding the timely access of data due to the “pull” model of the prior art.

55. Putting this aside the discussion of the “technical” issues with existing systems comprises, in my view, a rather loose use of the term “technical” as discussed at [26] of Accenture Global Solutions Limited [2022] APO 8. The difficulties with prior systems, such as they are, appear to reside in the procedural ways or rules that specify how those systems handle the data concerned – it does not reside in any defect or problem in the technology used to implement the processes concerned per se. Hence to the extent that the claimed invention addresses any problem, it is not necessarily technical in nature, nor is any technical solution provided.

Does the invention solve a “technical” problem within the computer or outside the computer?

56. It is not apparent that the claim solves a technical problem within or without the computerised apparatus or systems concerned. Merely providing a way of storing and accessing financial transaction data, subject to certain rules, in the manner indicated using known or standard computing technology is not addressing any technical difficulty as such. Nothing within the claim appears to address or overcome any technical difficulties. Rather, the claimed invention simply addresses procedural shortcomings regarding existing systems which do not provide for convenient storage or access of financial transaction data. In summary, I do not consider that the invention solves any technical problem, either within or without the computerised apparatus of the claim.

57. I note that the Applicant addresses this consideration at paragraphs [81] to [100] of the submissions. Here the Applicant argues, at [81] and [82] that:

“As foreshadowed above, current standards for exchanging transactional information only allow aggregate-level transactional information to be accessible, and typically do not support the capability to obtain detailed transactional information. These standards also require point-to-point connections for the transmission of financial transaction data, which are subject to bottlenecks as the number of connection increases.
Whilst it may be possible to access detailed transactional information associated with users, this is typically based on a ‘pull’ model driven by explicit requests to financial institutions, which in turn, must retrieve the detailed transactional information from the service providers or via their respective financial institution.”

58. My comments regarding the difficulties with the prior systems, the nature of “technical” and the fact that the claimed invention does not necessarily address these issues, may be reiterated here. The issues concerned are simply not technical in nature as such, but relate to organisation of the process used to store and access data based on existing standards or rules.

59. The Applicant makes some reference to compliance with standards in the prior art, at [83] and [84] of the submissions:

“Furthermore, as a financial transaction system, it is important to ensure that potentially sensitive user information is protected in the event that an unauthorised party may intercept communications, or if parts of the system become compromised. These requirements are heavily regulated, and any system that handles financial transactions, must meet minimum standards such as those set by the PCI Security Standards Council. For example, systems that process card transactions (i.e. credit and debit cards) must utilise point-to-point encryption, which converts confidential payment information into indecipherable code at the point of sale to prevent hacking and fraud.
As will appreciated by a person skilled in the art, the use of point-to-point connections, and ensuring that the system meets minimum standards with respect to security of sensitive user information are technical limitations faced by developers of financial transaction systems. It would not be common sense, or feasible, for the above problems to be solved using administrative means, as this would open a whole spectrum of other issues – notwithstanding that such a system would be incompatible and prohibited from communicating with existing systems which do meet these minimum standards.” (references to footnotes removed)

60. One may first note the fact that the claimed invention, as it handles financial transaction data, would presumably be subject to the PCI Security Standards indicated. But in any case, despite the Applicant’s arguments to the contrary, what the claimed invention really does is create a type of administrative system, in the form of a set of processes and rules to be used/followed that allow for storage and access of financial data. The computerised aspects of the claim are merely utilised for their known functions or abilities to perform the claimed invention. No actual problem in the technology concerned is identified or addressed. If there is a technical advance or effect, within the invention claimed or described, that provides for overcoming the problems concerned whilst being compliant with the relevant standards then this remains elusive. At best the claimed invention provides a convenient means or location of storing and accessing financial transaction data, but this is really little more than an arrangement of logistical convenience, in the same way it is more convenient to have books for loan in a library than scattered over many different locations.

61. It was also suggested at [87] and [88] that:

“…like in Facebook, Inc. [2020] APO 19, the claimed invention accommodates the technical limitations imposed on a financial transaction system, in that it must be based on point-to-point connections while also meeting minimum standards with respect to the security of sensitive user information, and now provides the ability to obtain detailed transactional information without being subject to bottlenecks as the number of connections increases. This limitation of conventional computer systems constitutes structural and architectural bottlenecks for exchanging financial transactional data, which limits the computer system’s scalability and efficiency for accommodating a large number of participants.
Referring to the embodiment described in Figure 5A above as an example, if Bright Bookworm wanted to request detailed financial information from Real Retail, Bright Bookworm would first need to submit a request to the financial institution that issued the credit card. Bright Bookworm's request would also need to be validated by the financial institution. The financial institution may then need to initiate a point-to-point connection with the financial institution responsible for processing Real Retail's transactions, who would then need to initiate an additional point-to point connection with Real Retail to request the detailed financial transaction. Again, Bright Bookworm's request will need to be validated. Once retrieved, additional point-to-point connections may be required to provide Bright Bookworm with the detailed financial transaction. The same process may be repeated for each retailer whom Bright Bookworm has made a transaction with.” (emphasis added)

There was also some exposition at [89] to [92] regarding how the claimed invention allegedly provides for less participants to be involved in the storing and exchange of data, and thereby reducing the point-to-point connections involved.

62. However, unlike Facebook, the present invention, either as claimed or described, does not appear to address a particular architectural limitation relating to the sandboxing of applications that means native applications “…are unable to communicate with other apps and are unable to tell if other apps are downloaded” Facebook, Inc. [2020] APO 19 (“Facebook”) at [85]. That is, the Delegate in Facebook found there was a quite particular issue that was addressed with a particular solution that allowed for a material effect to be observed in the device concerned. In this regard, that is not the case here. Notwithstanding the use of “may” regarding certain steps said to occur in existing systems, at [88] of the submissions, the Applicant’s assertions that there are less participants involved in the process are not necessarily reflected in the claim, nor is there necessarily any improvement or benefit over existing systems in terms of bottlenecks or resources used. This is due to the fact that, as discussed previously, the precise implementation of the invention, in terms of hardware and/or software and the architecture of the same, is entirely up to the skilled addressee. The claimed invention provides for certain functionality in terms of the accessing and storing of data and does not specify how the hardware and/or software achieves this. There is no actual architecture providing for a material advantage.

63. It may also be reiterated here that the issues raised by the Applicant regarding prior systems fundamentally relates to the procedural way those systems are organised to handle, store and access data, and not in any technical issues regarding the systems themselves. Similarly, it has been noted previously that the claimed invention does not provide any technical benefit or advance, it merely provides a different, albeit potentially more logistically convenient, procedure for storing and accessing financial data.

64. For similar reasons, the Applicant’s arguments, at [93] to [95] of the submissions, regarding the similarity of this matter with Jagwood Pty Ltd [2020] APO 38 (“Jagwood”) do not assist the Applicant’s assertions of patentability. The same may be said regarding the alleged benefits the claimed invention provides and the problems it is said to solve, as discussed at [96] to [100] of the submissions, which largely reiterate matters already discussed. Suffice to state the issues regarding the security of data (at [97] and [98]) merely relate to a procedural way, merely using existing technology, of storing data to make it secure, rather than anything fundamentally technical per se. Similarly, the issues regarding the storing, access to, and aggregation of, financial data discussed at [100] simply relate to how existing systems share, store, exchange or allow access to data at a high level that simply relates to procedural or logistical data handling issues, rather than in any technical defect or difficulty.

Is there an improvement in the functioning of the computer, irrespective of the data being processed?

65. I cannot ascertain any improvement in the functioning of any of the computerised apparatus used within the claim, irrespective of the data being processed. As discussed above, the computerised devices present in the claim are merely used for their standard or known abilities to process, exchange and store data. Any improvement, to the extent one can be identified, appears to reside in the process used to store and access the financial transaction data.

66. In summary I consider that there is no improvement in the functioning of the computerised devices utilised in the claim.

67. The Applicant has provided arguments relevant to this consideration at [113] to [125] of the submissions. At [115] to [117] the Applicant states that:

“We submit that when properly characterised, the claimed invention results in an advance in computer technology, as it enables service providers to push detailed transaction, while accommodating technical limitations faced by developers of financial transaction systems. Put another way, the claimed invention exists as an add-on and provides existing financial transaction systems with functionality it did not previously have, without the need to incorporate a new protocol.
By way of contrast, the claimed invention enables service providers to directly share detailed transaction information with the consumer, which was not possible whilst using OFX. This is because OFX connects to the banks, who do not have detailed transaction information. Instead, banks only have aggregate-level transactional information.
As described in the specification, the claimed invention creates an open architecture for exchanging detailed transaction information, such that there is no single entity that owns the registry, and that any entity (e.g., a service provider) may transmit new detailed transactions by accessing the registry and finding a link to the data store corresponding to a specific secure identifier, without requiring pre-existing point-to-point connections.” (references to footnotes removed)

68. The difficulties I have with the Applicant’s characterisation, as technical, of the issues in existing systems and of the claimed invention, have been discussed previously and need not be repeated here. Suffice to state that, given the discussion above, the functionality referred to by the Applicant amounts to little more than a process setting out how the financial transaction data is handled and stored. No advance in the computer systems or technology (including networking) is apparent. Even assuming that previous systems did not provide detailed financial transaction data, it does not amount to an advance in computing technology to merely use standard computing technology to provide such information, directly or otherwise. As observed earlier, implementation of the invention in terms of hardware and/or software is left entirely up to the skilled addressee. This means the “open architecture” is so open as to exist at only a functional level that specifies the procedural way in which the financial transaction data is stored and accessed. It does not provide any intrinsic technical benefit or advantage. The advantage, as discussed, is at best, logistical in nature.

69. At [118] to [120] the Applicant argues that, with reference to the claimed invention:

“We submit that this functionality represents an advance in computer technology as it did not previously exist, and was not contemplated in the art.
For example, the first examination report issued on the present case cites D1 (US 2008/0052091 A1) and D2 (US 2001/0027527 A1) under the ground of inventive step. However, neither citation described enabling a service provider to push detailed transaction to a data store, that detailed transaction can be verified using metadata, or that detailed transaction is only stored after being successfully validated. Furthermore, neither citation describes protecting sensitive user information by utilising a registry, or allowing an authorised entity to lookup the data store.
Although issues raised under Novelty and Inventive Step are separate considerations to manner of manufacture, several Patent Office Decisions have referred to external documentation to formulate an overview of the state of the art at the priority date.”

Some further elaboration on this point is provided at [121] to [125] with reference to Aristocrat Technologies Australia Pty Limited [2016] APO 49 (“Aristocrat Technologies”), Apple, Inc. [2019] APO 32 (“Apple”), Gilbarco Inc [2020] APO 26 (“Gilbarco”) and Advanced New Technologies Co., Ltd. [2021] APO 29 (“ANT”).

70. While the Applicant concedes that assessment of manner of manufacture is distinct from considerations of novelty and inventive step, as best understood, the Applicant appears to be submitting that, as the claimed invention was considered novel and inventive during examination, it must be for a manner of manufacture. This, of course, is incorrect. Completely new and inventive uses of computer technology may be created that simply make use of the known capabilities of computing technology. In such cases, for the invention to be patentable, there must be something else, in terms of substance, that confers patentability besides the mere use of computing technology to provide new and inventive functionality. It would seem to me that the Applicant may have misunderstood the role of common general knowledge and the state of the art in assessing the patentability of computer implemented inventions, which is simply to assist in understanding the contribution to the art and using that to identify the substance of the invention. This is perhaps best illustrated at [85] of Rokt, in discussing RPL at [96]:

“The reference to using the computer for its ‘well-known and understood functions’ involved consideration of computers having regard to their basic and well-known functions. This did not require, and should not be taken to encourage, a review of the common general knowledge beyond the use of the common general knowledge, to the extent necessary, to construe the specification.”

71. The Applicant also made submissions, regarding whether the invention lies in the generation, presentation or arrangement of intellectual information, that I consider are relevant to this consideration. These are given at [132] and [133]:

“The claimed invention involves a service provider generating a secure identifier linked to a detailed transaction, and then pushing the detailed transaction to a data store. The identity of the service provider, and the detailed transaction itself, must be verified and validated by the registry and access controller. The system also enables a user to register a secure identifier to be linked to a URI of a data store, which is validated upon presentation of a validation token obtained from a financial institution.
We submit that based on a reasonable construction of the claims, it is clear that the claimed invention defines how information is to be handled, transmitted and stored. As there is nothing in the claim which defines how information is to be generated or arranged, we submit that the claimed invention does not lie merely the generation and arrangement of intellectual information.”

72. I can accept that the invention does not comprise the mere “generation and arrangement of intellectual information”, and that it “…defines how information is to be handled, transmitted and stored”. However, this does not assist the Applicant as merely specifying, at the level of generality of the claim, how data is handled, transmitted and stored, where each of those actions merely makes use of the known capabilities of computing technology, does not provide for patentability. It is possible that some material effect or benefit may occur from the handling, storing and transmitting of data, but as previously discussed, none is necessarily apparent. All that there is, is the possibility of more convenient data access and storage over existing arrangements.

Does the invention require merely “generic computer implementation”, as distinct from steps which are “foreign” to the normal use of computers?

73. For reasons as discussed above, it is quite clear that all the computerised features of the claimed invention are being used in a generic sense in that use is merely made of the well-known functions and abilities of the same. There is nothing in the use of any of the computerised features which is foreign to the normal use of computers.

74. The Applicant has not made any submissions directly addressing this consideration. However, while placed within a discussion on whether there is an “advance in computer technology”, I am of the view that [113] and [114] are perhaps better addressed under this consideration. These paragraphs of the submissions are reproduced below:

Recently in Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202, the Full Court determined manner of manufacture based on whether the disputed invention can ‘be broadly be described as an advance in computer technology’. However, this consideration should not be based on whether an invention may be generic, with the Full Court struggling with concepts such as ‘generic computer technology’ or ‘generic software’ as it was unclear ‘what they actually mean’.
Moreover, whether an invention results in an advance in computer technology may depend on problems, which may arise with respect to how computing technology has been implemented in different fields of technology. An invention that provides an advance in computer technology in one field of technology will not necessarily provide an advance in some other field of technology. Thus, the way in which a system functions may be patentable ‘even though a computer engineer may not consider that there has been any advance in the field of computer technology‘ - provided that the technical contribution can be viewed as residing in a different field.” (references to footnotes removed)

75. However, I consider that the arguments regarding considerations of “generic computer technology and the like” are misconceived. It is apparent that the warning from Aristocrat was with regard to the dangers that could arise in not properly defining or characterising what is meant by “generic computing technology” within the particular context under consideration. Aristocrat was not mandating the relative weight to be given to this consideration per se or suggesting that it was no longer a relevant consideration.

It is, of course, possible for an invention to comprise generic computer implementation and still be patentable. The statements in Aristocrat in that regard are unremarkable. The problem for the Applicant is that, as discussed, there is no advance in any aspect of technology, computer or otherwise that is achieved by the claimed invention.

Is the computer merely an intermediary, configured to carry out the method using program code for performing the method, but adding nothing to the substance of the idea?

For reasons as discussed above the computerised features are specified at only a generic level to merely facilitate the storage and access of financial transaction data. That is, they are merely an intermediary facilitating the storage and access of financial transaction data and add nothing of substance to the process of achieving the same.
The Applicant did not appear to make any submissions that were specifically directed to this consideration, but I would take submissions made with regard to the other factors as being generally relevant to this factor as well. To the extent this is the case, I refer to my discussion of the Applicant’s submissions elsewhere in this decision.

The Applicant’s Submissions Regarding “Practical and Useful Result”

The Applicant has provided arguments regarding there being a practical and useful result at [126] to [131] of the submissions:
“The purpose of the claimed invention is to facilitate the exchange, and collection, of detailed transactions whilst meeting minimum standards with respect to security of sensitive user information. This is achieved by providing an open architecture in which entities are verified by a registry and access controller. Detailed transactions are pushed to the data store by service providers, and are validated using transaction metadata before it is permitted to be stored in a data store.
Being an open system, any entity may transmit new detailed transactions by accessing the registry and finding a link to the data store corresponding to a specific secure identifier, without requiring pre-existing point-to-point connections.
Relying on a push system, rather than a pull system, addresses the structural and architectural bottlenecks in conventional computer systems for exchanging financial transactional data. Moreover as the user identifier is encoded into a secure identifier prior to being transmitted to the system, sensitive user information is never actually seen or stored on the registry, access controller, or data store.
As outlined in the previous section, all of these features can only be achieved using technical means involving techniques in the field of information technology. They cannot be achieved by administrative means, or by changing a business process. For example in eBay Inc. [2020] APO 49, the Delegate concluded that obtaining congestion data to determine an alternative route, was ‘a technical problem that requires a technical solution’ and was not ‘merely implementing a business process’.
Put another way, the Delegate correctly recognised that eBay's invention could not be performed by simply provisioning a business process in a computer system, but required ‘a physical and technical solution to a physical and technical problem’.
Accordingly, we submit that all of these features produce a practical and useful result that is not related to a business process or business rules.”
Putting aside questions of a “practical and useful result” for the moment, the problem for the Applicant is the invention as claimed does not necessarily provide a technical solution to any technical problem. As discussed, there are no inherent defects in the computing technology used in existing systems. The issue is simply one of how those systems allow or do not allow data to be stored and handled. The claimed invention simply creates a different, and potentially more convenient, way to store and access data than in the existing systems by using standard computer technology. The mere use or presence of technology does not necessarily provide for patentability.
In terms of there being a “practical and useful result”, I am of the view that the claimed invention can be characterised as providing, in the most general sense of the phrase, a “practical and useful result” in that it provides for what is an alternative means of storing and accessing financial transaction data, and which might comprise a more convenient arrangement of doing so as compared to existing systems. However, as discussed elsewhere in this decision, I do not consider this to lead to a technical result or improvement per se. Notably, with reference to the discussion above regarding Amsted and Grzegorz Malewicz, the fact that there is a “practical and useful result” is not necessarily sufficient to confer patentability.

82. The finding in eBay does not assist me in assessing the facts of this matter, which clearly do not relate as such to determining congestion information, processing this information and presenting a recommended route to the user to avoid congestion. Furthermore, the delegate found that eBay was patentable in providing a technical solution to a technical problem, this not being present in this case as per my discussion above.

What is the substance of the invention in claim 1 and is this patentable?

On weighing up the above considerations, which all suggest that the substance does not reside in the technical features but rather in a process or arrangement for the storage and access of financial transaction data in certain ways merely using existing computer technology, I am of the view that. the substance of the invention is as follows:
·     A process or arrangement for the storage, access and handling of financial transaction data defined by the following:
o   the use of a secure identifier that is generated from a user identifier using an encoding function
§ a first entity sends a request to store a detailed transaction corresponding to the secure identifier in a data store;
§ when trusted, a service provider can provide the request to store the detailed transaction
§ validating the detailed transaction using metadata from the first entity and storing the detailed transaction based on determining that the first entity is trusted after performing validation;
o   determining whether the first entity is trusted by applying a stored security rule corresponding to the type of secure identifier with the request to store the detailed transaction;
§ If the security rule indicates an identity check should be performed, determining whether the number of entries corresponding to the first entity in a greylist exceeds a threshold
o   receive a user request to register a URI of a data store with the secure identifier
§ validating the registration request based on presentation of a token from a financial institution;
§ storing the URI of the data store with the secure identifier;
o   receive from a second entity a request to look up a data store registered with the secure identifier;
§ retrieve the URI of the data store in response to the look up request
§ transmit the URI of the data store to the second entity, if the second entity is trusted;
§ determining whether the second entity is trusted comprises applying a second security rule corresponding to the type of secure identifier associated with the look up request.

84. While there is clearly a computerised system in the claim, it, and its constituent components, such as the plurality of transaction storage devices, access controller, registry and service provider, do not form part of the substance per se as the claim merely makes use of the known capabilities of such computerised apparatus. In addition, the transaction storage device, access controller, registry and service provider are only defined by the functionality they provide, and not in any particular arrangement or structure of the same. It is quite clear from the specification that each of these may be performed in hardware and/or software in any way known to the skilled addressee using existing technology. For example, there could be multiple access controllers and multiple registries, and each of these could be implemented using the same or different hardware and/or software.

I note the Applicant has made extensive submissions regarding the claimed invention being patentable. However, I am unable to identify a clear statement in the submissions that positively identifies what the Applicant considers the substance of the invention to be. As best understood, the submissions at [79] and [80] appear to set out what the Applicant considers to be the substance of the invention, and I, I did not take the Applicant’s views as to the substance to be materially different to mine. Suffice to state that while the substance of the invention could be implemented without existing point to point connections, this is really an expression of the fact that the claimed invention is entirely agnostic as to the nature of the connections used. Consequently, the nature of the connections used do not form, in my view, part of the substance of the invention.
The remaining question now is whether the substance falls within the bounds of patentable subject matter as established by authority. I consider that it does not. The substance clearly amounts to what I consider to be merely an arrangement of steps or processes, in effect a scheme, for storing and accessing financial transaction data. It is apparent that the Applicant disagrees with this characterisation, as apparent from the “Conclusion” at [134] to [138] of the submissions, however the nature and effect of the claimed invention is apparent from considering the relevant factors. In particular, the generality of the computerised technology used, elevate the substance to nothing more than a scheme for accessing and storing financial transaction data. No technical benefit or effect is achieved as a consequence of performing the claimed invention.

The fact that there might be a “practical and useful result” of some broadly considered kind does not change this conclusion. As noted in Amsted at [79] “The difficulty for the Applicant is that this ‘practical and useful result’ is not one that leads to patentability”.

Are Independent Claims 5, 9, 15 or 21 for a Manner of Manufacture?

Claim 5 defines “A method for data exchange between multiple entities in a computer system…” in virtually identical terms as for claim 1. Other than being couched as a method, I am unable to ascertain any material difference, in terms of substance, between claim 1 and claim 5. Consequently, claim 5 is not for manner of manufacture for similar reasons as given with regard to claim 1.
Claim 9 defines “A system, comprising: a plurality of transaction storage devices…” that provides for storge and access to financial transaction data in similar terms as for claim 1. While a computer system is not explicitly defined, the reference to such features as a URI and a data store indicate that some form of computerised system is present and used. No validation of the transaction is required, nor is there a service provider as per claim 1. The request to push the detailed transaction is done using the URI. The first determination is further based on a target of the request being a data store, rather than the number of entries in a greylist where an identity check should be performed. Similarly, the equivalent to the second determination of claim 1 is, in claim 9, further based on the target of the second request being a registry. These differences, in my view, simply amount to the particular rules used to allow storage or access to the financial data. There is no material difference between claim 1 and 9 in terms of characterisation of the substance. Consequently, claim 9 is not for manner of manufacture for similar reasons as given with regard to claim 1.
Claim 15 provides for a method that, other than being couched as a method rather than a system, is virtually identical to claim 9. Claim 21 provides for “A non-transitory computer readable medium comprising instructions…”, that, other than being a non-transitory computer readable medium instead of a system, is virtually identical to claim 9. It follows that claims 15 and 21 are not for a manner of manufacture for similar reasons as given with regard to claim 1.

Are any of the dependent claims for a Manner of Manufacture?

I have also considered each of the dependent claims. These comprise additional features that amount to adding additional steps to the scheme as defined in the independent claims, or other dependent claims, making use of standard computer technology as follows:
o   claims 2, 6, 10, 16 and 22: determining, where an identity check should be performed whether the first entity is on a whitelist;
o   claims 3, 7, 13, 19 and 24: the second security rule indicates challenge based access control should occur and generating a series of challenges in response to requests and receiving and checking a response to the challenge(s).
o   claims 4, 8, 14 and 20: challenge based access control is based on the number of requests exceeding a minimum value and not exceeding a maximum value in a predetermined time period;
o   claims 11 and 17: where an identity check should be performed, determining whether the number of entries corresponding to the entity in a greylist exceeds a threshold; and
o   claims 12, 18 and 23: retrieve the URI of the data store in response to the request to look up the data store.
I do not see anything in the additional features provided by claims 2 to 4, 6 to 8, 10 to 14, 16 to 20 and 22 to 24 that materially varies the substance, in terms of characterisation, of the independent claims. These are simply additional rules specifying how and when the financial data may be stored or accessed and do not provide for any material advantage that would confer patentability. It follows that none of the dependent claims are for a manner of manufacture.

Is there anything within the Application that provides for a Manner of Manufacture?

In addition to there being no patentable material in the claims, my perusal of the application does not reveal anything that, as a matter of substance, extends beyond the invention discussed above, either for the invention as claimed or as described. I conclude that there is nothing in the application, beyond that already considered, that could be claimed to result in a manner of manufacture.

Conclusion

None of the claims are for a manner of manufacture. In addition, I see no material in the application that could be made the subject of a claim so as to result in that claim being for a manner of manufacture. Whilst I note the Applicant’s request to address any defects I may identify via further examination, I see no point in doing so where I am of the view that there is no amendment that could be made that would overcome the findings in this decision. I therefore refuse the application.

Dr W.E. Guinea

Delegate of the Commissioner of Patents

Annex A – Claims

A computer system for data exchange between multiple entities, comprising:
a plurality of transaction storage devices, each transaction storage device of the plurality of transaction storage devices comprising a data store configured to:
receive,from a first entity, a request to push a detailed transaction corresponding to a secure identifier,
wherein the secure identifier is generated, using an encoding function, from a user identifier of a user,
wherein the detailed transaction identifies at least one selected from a group consisting of products and services received by the user from the first entity;
validate the detailed transaction using metadata from the first entity; and store the detailed transaction based on a first determination to trust the
first entity after validating the detailed transaction; an access controller configured to:
perform the first determination by applying a first security rule corresponding to a type of the secure identifier to the request to push the detailed transaction; and
determine,based on the first security rule indicating that an identity check should be performed, whether the number of entries corresponding to the first entity in a greylist exceeds a threshold; and
a registry configured to store at least the first security rule; wherein the registry is further configured to:
receive, from the user, a request to register a universal resource identifier (URI) of a first data store with the secure identifier, wherein the registration request is determined to be valid upon presentation of a validation token obtained from a financial institution;
store the URI of the first data store with the secure identifier;
receive, from a second entity, a request to lookup a data store registered with the secure identifier;
retrieve the URI of the first data store in response to the request to lookup the data store; and
transmitthe URI of the first data store to the second entity, based on a second determination to trust the second entity, wherein the second determination comprises applying a second security rule corresponding to the type of the secure identifier to the request to lookup the data store, wherein the second determination is performed by the access controller;
a service provider configured to provide the request to push the detailed transaction to the data store when the access controller trusts the service provider.
The system of claim 1, wherein the access controller is further configured to:

determine, based on the first security rule indicating that an identity check should be performed, whether the first entity is listed in a whitelist.

The system of claim 1, wherein the second security rule indicates that challenge-based access control should be performed, wherein performing the second determination further comprises:
generating a series of challenges in response to a series of requests received from the second entity;
transmitting each challenge of the series of challenges to the second entity in response to the corresponding request of the series of requests;
receiving a result from the second entity in response to the challenge; and determining whether the result is correct.
The system of claim 3, wherein performing the challenge-based access control is based on the number of requests received from the second entity exceeding a predetermined minimum value and not exceeding a predetermined maximum value within a predetermined time interval.

A method for data exchange between multiple entities in a computer system, comprising: receiving, from a first entity, a request to push a detailed transaction corresponding to
a secure identifier, wherein the secure identifier is generated, using an encoding function, from a user identifier of a user,
wherein the detailed transaction identifies at least one selected from a group consisting of products and services received by the user from the first entity;
validate the detailed transaction using metadata from the first entity;
storingthe detailed transaction based on a first determination to trust the first entity after validating the detailed transaction, wherein the first determination comprises applying a first security rule corresponding to a type of the secure identifier to the request to push the detailed transaction;
determining, based on the first security rule indicating that an identity check should be performed, whether the number of entries corresponding to the first entity in a greylist exceeds a threshold;
receiving a request to register a universal resource identifier (URI) to a first data store with the secure identifier, wherein the registration request is determined to be valid upon presentation of a validation token obtained from a financial institution;
storing the URI of the first data store with the secure identifier;
receiving, from a second entity, a request to lookup a data store registered with the secure identifier;
retrieving the URI of the first data store in response to the request to lookup the data store; and
transmitting the URI of the first data store to the second entity, based on a second determination to trust the second entity, wherein the second determination comprises applying a second security rule corresponding to the type of the secure identifier to the request to lookup the data store;
a service provider configured to provide the request to push the detailed transaction to the data store when the access controller trusts the service provider.
The method of claim 5, wherein the first determination further comprises:
determining, based on the first security rule indicating that an identity check should be performed, whether the first entity is listed in a whitelist.
The method of claim 5, wherein the second security rule indicates that challenge-based access control should be performed, wherein the second determination further comprises:
generatinga series of challenges in response to a series of requests received from the second entity;
transmitting each challenge of the series of challenges to the second entity in response to the corresponding request of the series of requests;
receiving a result from the second entity in response to the challenge; and determining whether the result is correct.
The method of claim 7, wherein performing the challenge-based access control is based on the number of requests received from the second entity exceeding a predetermined minimum value and not exceeding a predetermined maximum value within a predetermined time interval.

9.A system, comprising: a plurality of transaction storage devices, each transaction storage device of the plurality of transaction storage devices comprising a data store configured to: receive, from an entity, a first request to push, using a universal resource identifier (URI) of the data store registered with a secure identifier, a detailed transaction corresponding to the secure identifier, wherein the secure identifier is generated, using an encoding function, from a user identifier of a user, and wherein the detailed transaction identifies at least one selected from a group consisting of products and services received by the user from the entity; and store the detailed transaction based on a first determination to trust the entity; and an access controller configured to: perform the first determination using a first access control procedure specified by a first security rule corresponding to a type of the secure identifier and a first target of the first request being a data store of one of the plurality of transaction storage devices; and perform a second determination to trust the entity using a second access control procedure specified by a second security rule corresponding to the type of the secure identifier and a second target of a second request being a registry, wherein the registry is configured to: store at least the first security rule; receive, from the entity, the second request to lookup the URI of the data store registered with the secure identifier; and transmit, to the entity and based on the second determination, the URI of the data store registered with the secure identifier, wherein the entity generates the first request to push the detailed transaction corresponding to the secure identifier in response to receiving, from the registry and in response to the second request, the URI of the data store registered with the secure identifier; wherein the registry is further configured to: receive, from the user, a request to register the URI of the data store with the secure identifier; and store the URI of the data store with the secure identifier, and the registration request is determined to be valid upon presentation of a validation token obtained from a financial institution.

The system of claim 9, wherein the access controller is further configured to: determine, based on the first security rule indicating that an identity check should be performed, whether the entity is listed in a whitelist.
The system of claim 9, wherein the access controller is further configured to: determine, based on the first security rule indicating that an identity check should be performed, whether the number of entries corresponding to the entity in a greylist exceeds a threshold.

The system of claim 9, wherein the registry is further configured to: retrieve the URI of the data store in response to the second request to lookup the data store.

The system of claim 12, wherein the second security rule indicates that challenge-based access control should be performed, wherein performing the second determination further comprises: generating a series of challenges in response to a series of requests received from the entity; transmitting each challenge of the series of challenges to the entity in response to the corresponding request of the series of requests; receiving a result from the entity in response to the challenge; and determining whether the result is correct.
The system of claim 13, wherein performing the challenge-based access control is based on the number of requests received from the entity exceeding a predetermined minimum value and not exceeding a predetermined maximum value within a predetermined time interval.

A method, comprising: receiving, from an entity, a first request to push, using a universal resource identifier (URI) of a data store registered with a secure identifier, a detailed transaction corresponding to the secure identifier, wherein the secure identifier is generated, using an encoding function, from a user identifier of a user, and wherein the detailed transaction identifies at least one selected from a group consisting of products and services received by the user from the entity; storing the detailed transaction based on a first determination to trust the entity, wherein the first determination comprises applying a first security rule corresponding to a type of the secure identifier to the request to push the detailed transaction; performing the first determination using a first access control procedure specified by a first security rule corresponding to a type of the secure identifier and a first target of the first request being a data store of one of the plurality of transaction storage devices; performing a second determination to trust the entity using a second access control procedure specified by a second security rule corresponding to the type of the secure identifier and a second target of a second request being a registry; storing, by the registry, at least the first security rule; receiving, from the entity and by the registry, the second request to lookup the URI of the data store registered with the secure identifier; and transmitting, to the entity, by the registry, and based on the second determination, the URI of the data store registered with the secure identifier, wherein the entity generates the first request to push the detailed transaction corresponding to the secure identifier in response to receiving, from the registry and in response to the second request, the URI of the data store registered with the secure identifier, the method further comprising: receiving a request to register the URI to the data store with the secure identifier; and storing the URI of the data store with the secure identifier, wherein the registration request is determined to be valid upon presentation of a validation token obtained from a financial institution.
The method of claim 15, wherein the first determination further comprises: determining, based on the first security rule indicating that an identity check should be performed, whether the entity is listed in a whitelist.
The method of claim 15, wherein the first determination further comprises: determining, based on the first security rule indicating that an identity check should be performed, whether the number of entries corresponding to the entity in a greylist exceeds a threshold.
The method of claim 15, further comprising: retrieving the URI of the data store in response to the second request to lookup the data store.

The method of claim 18, wherein the second security rule indicates that challenge-based access control should be performed, wherein the second determination further comprises: generating a series of challenges in response to a series of requests received from the entity; transmitting each challenge of the series of challenges to the entity in response to the corresponding request of the series of requests; receiving a result from the entity in response to the challenge; and determining whether the result is correct.

The method of claim 19, wherein performing the challenge-based access control is based on the number of requests received from the entity exceeding a predetermined minimum value and not exceeding a predetermined maximum value within a predetermined time interval.

A non-transitory computer readable medium comprising instructions that, when executed by a computer processor, perform: receiving, from an entity, a first request to push, using a universal resource identifier (URI) of a data store registered with a secure identifier, a detailed transaction corresponding to the secure identifier, wherein the secure identifier is generated, using an encoding function, from a user identifier of a user, and wherein the detailed transaction identifies at least one selected from a group consisting of products and services received by the user from the entity; storing the detailed transaction based on a first determination to trust the entity, wherein the first determination comprises applying a first security rule corresponding to a type of the secure identifier to the request to push the detailed transaction; performing the first determination using a first access control procedure specified by a first security rule corresponding to a type of the secure identifier and a first target of the first request being a data store of one of the plurality of transaction storage devices; performing a second determination to trust the entity using a second access control procedure specified by a second security rule corresponding to the type of the secure identifier and a second target of a second request being a registry; storing, by the registry, at least the first security rule; receiving, from the entity and by the registry, the second request to lookup the URI of the data store registered with the secure identifier; and transmitting, to the entity, by the registry, and based on the second determination, the URI of the data store registered with the secure identifier, wherein the entity generates the first request to push the detailed transaction corresponding to the secure identifier in response to receiving, from the registry and in response to the second request, the URI of the data store registered with the secure identifier, wherein the instructions further perform: receiving a request to register a universal resource identifier (URI) to a data store with the secure identifier; and storing the URI of the data store with the secure identifier, and the registration request is determined to be valid upon presentation of a validation token obtained from a financial institution.

The non-transitory computer readable medium of claim 21, wherein the instructions further perform: determining, based on the first security rule indicating that an identity check should be performed, whether the entity is listed in a whitelist.

The non-transitory computer readable medium of claim 21, wherein the instructions further perform: retrieving the URI of the data store in response to the second request to lookup the data store.

The non-transitory computer readable medium of claim 23, wherein the second security rule indicates that challenge-based access control should be performed, and wherein the second determination further comprises: generating a series of challenges in response to a series of requests received from the entity; transmitting each challenge of the series of challenges to the entity in response to the corresponding request of the series of requests; receiving a result from the entity in response to the challenge; and determining whether the result is correct.