Accenture Global Solutions Limited
[2022] APO 23
•29 March 2022
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Accenture Global Solutions Limited [2022] APO 23
Patent Application: 2018250365
Title:HARDWARE BLOCKCHAIN CORRECTIVE CONSENSUS OPERATING PROCEDURE ENFORCEMENT
Patent Applicant: Accenture Global Solutions Limited
Delegate:Tim Gillett
Decision Date: 29 March 2022
Hearing Date: Written submissions filed on 8 January 2021 and 28 January 2022
Catchwords: PATENTS – section 45 – examiner’s objection - manner of manufacture – blockchain – managing insurance on blockchain – alleged invention not a manner of manufacture – contractual terms – efficient conduct of business – no patentable subject matter in application – application refused
Representation: Patent attorney for the Applicant: Murray Trento & Associates Pty Ltd
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2018250365
Title:HARDWARE BLOCKCHAIN CORRECTIVE CONSENSUS OPERATING PROCEDURE ENFORCEMENT
Patent Applicant: Accenture Global Solutions Limited
Date of Decision: 29 March 2022
DECISION
The claims of the application, as proposed to be amended are not for a manner of manufacture. I do not see any subject matter in the specification which could be used to overcome this issue and as such I refuse the application.
REASONS FOR DECISION
Background
Patent application 2018250365 (“the application”) was filed on 16 October 2018 as a divisional application of 2017204199. The Applicant is Accenture Global Solutions Limited, hereinafter the “Applicant”. Seven examination reports have been issued across the two applications, with each report asserting that all claims are directed to a scheme and are therefore not patentable; the only outstanding matter at present.
A hearing was requested on 13 November 2020 with submissions that the claims are not directed to a scheme. The hearing was by way of written submissions filed on 8 January 2021. I note that the Applicant has provided several written submissions during the course of examination, and these have also been considered in writing this decision.
On 3 December 2021 the Applicant was invited to provide further submissions in light Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 (“Aristocrat ‘21”) which was issued on 19 November 2021. The Applicant provided further submissions on 28 January 2022 which were considered in writing this decision.
The examination of the present application is governed by the Patents Act 1990 (“the Act”) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 (“the Raising the Bar Act”) as the application was filed after 15 April 2013. Thus, the standard of proof that applies in the present case is the balance of probabilities (subsection 49(1)). I must accept the application if satisfied on the balance of probabilities that the application complies with the Act. If I am not so satisfied, then I can refuse the application.
During examination, amendments to the application were proposed on 21 March 2019 and 8 April 2020. No objection has been taken to those amendments under s102 to date. It follows that the examiner considered the amendments to be allowable. I see no outstanding issue in relation to those amendments and so from hereon in, all references will be to the specification as proposed to be amended on 8 April 2020.
Background to blockchain
The application is directed to blockchain technology. It is necessary to understand this technology to properly analyse the specification. Since the specification only provides a brief explanation of blockchain technology I consider it useful at this point to provide some additional background before continuing to the specification.
As was discussed in Advanced New Technologies Co., Ltd. [2021] APO 29 (“ANT”), the article “Consensus - Immutable agreement for the Internet of value” by Sigrid Seibold and George Samman and published by KPMG on the internet in September 2016 provides what I consider to be an excellent overview of the state of the art in relation to blockchain before the priority date of the present application.
The following is a snippet from the “The basics behind blockchain” section of the KPMG document:
Blockchains are a specific type of a distributed ledger and a way of ordering and verifying transactions into blocks with various protections against tampering and revision. A network of computers maintains and validates a record of consensus of those transactions via a cryptographic audit trail. A distributed ledger means that no single centralized authority, like a clearinghouse, verifies and executes transactions. Instead, participants have computers that serve as “nodes” within the network.
Some or all of these nodes verify and, if appropriate, execute proposed transactions according to an agreed-upon algorithm called the consensus mechanism. The transactions are then encrypted and stored in linked blocks on the nodes, creating an audit trail. There’s no need for a middleman between the parties in a transaction. There’s also no need for trust from one peer to the next, since the technology, running on the participants’ nodes, provides all the confidence needed. If a blockchain is well implemented, the resulting advantages include speed, privacy, reliability, and much lower costs.
At the heart of a blockchain is consensus among the participants (refer to steps three and four in Figure 1.) Consensus is key, because without a central authority, the participants have to agree on the rules and how to apply them; using these rules, they have to agree to accept and record a proposed transaction.
Consensus
How consensus mechanisms work
Basic parameters that define a consensus mechanism:- Decentralized governance: A single central authority cannot provide transaction finality.
- Quorum structure: Nodes exchange messages in predefined ways, which may include stages or tiers
- Authentication: This process provides means to verify the participants’ identities
- Integrity: It enforces the validation of the transaction integrity (e.g., mathematically through cryptography).
- Nonrepudiation: This provides means to verify that the supposed sender really sent the message.
- Privacy: It helps ensure that only the intended recipient can read the message.
- Fault Tolerance: The network operates efficiently and quickly, even if some nodes or servers fail or are slow.
- Performance: It considers throughput, liveness, scalability, and latency.
Within these parameters, there are significant differences between one consensus mechanism and another. We’ll look at some of these differences when we describe specific mechanisms below. A number of the parameters above are implemented through four main techniques within cryptography that use mathematical formulas to try to ensure security and privacy. These techniques include private keys, hashing functions and hierarchical deterministic keys.
Overview of consensus mechanisms and distributed ledger technologies
Figure 2, provides a visual summary of the key distributed ledger technologies we are seeing in the market right now.
Specification
The specification is directed toward managing an accumulated value with blockchain technology. The invention could be applied to a range of fields, but the primary example provided is an insurance provider tracking claim value. Other applicable fields include a telecommunications provider tracking usage as discussed in paragraph [0080] which reads as follows:
The usage scenarios in the health claims context were described above with regard to the accelerated record entry hardware system 100. However, the accelerated record entry hardware system 100 may be used to track other accumulated values. For example, the accelerated record entry hardware system 100 may be used in maintaining a record of network usage for telecommunication service provision. For example, user equipment may post usage to a blockchain. The blockchain may be used by the provider to track usage. The blockchain may be used to ensure that the user equipment does not alter the usage record if compromised. Additionally or alternatively, the blockchain may be applied in multiple telecommunication provider contexts. For example, multiple providers may wish to coordinate complementary services, such as regional wireless coverage, television and cellular service, or other combinations of service. The blockchain of the accelerated record entry hardware system 100 may be used as a multiple-provider record for tracking usage of the difference services. The consensus operating procedure may be used to ensure the multiple providers adhere to agreed-upon tracking standards. The accelerated record entry hardware system 100 may be used in virtually any context where multiple parties agree to a consensus operating procedure for additions to a blockchain.
10. The specification provides a general definition of an accumulated value in paragraph [0020] as follows:
…For example, accumulated values may include values that are tracked by the system over time and tally the value of one or more related operations or transactions.
11. I have understood that being a tally, each accumulated value can be dependent on one or more previous values. As a result of this dependency, changes to a value can necessitate recalculation of later values which depend upon it.
12. The problem being addressed is introduced in paragraph [0019] which begins:
When multiple nodes coordinate to place entries in a record, the parties represented by the multiple nodes may be dependent on other nodes following the consensus operating procedure or terms when creating entries in the record. For example, a consensus operating procedure may include a procedure enforced through a blockchain consensus mechanism. Situations in which a node posts an entry to the record without first following the consensus operating procedure may necessitate corrections that ripple through multiple ledger entries and consume hardware processing resources.
13. Despite the assertion that corrections can “ripple through multiple ledger entries” there is no explanation of how or why that happens. I have assumed that the accumulated value, being a tally creates this issue via the dependency. That is, correction of one entry can necessitate further corrections to other dependent entries.
14. The specification then addresses a few scenarios which may give rise to transactions that are in some way erroneous:
a. An invalid block is submitted (paragraph [0023]).
b. A valid corrective block is submitted and invalidates another block (paragraph [0033]).
c. A valid block is submitted out of sequence and invalidates another block (paragraph [0048]).
15. Paragraph [0022] suggests scenario a) can be handled by marking compliance against the record for future reference:
When a node follows the consensus operating procedure during posting of an entry, e.g., by complying with the terms of the smart contract, the system may provide a validity indicator for the entry created…
16. Paragraph [0023] suggests scenario a) can be handled by ignoring the request:
…If the system added the block without properly following the defined consensus procedure, the block may be ignored…
17. Scenario a) can be handled in these ways because the block is plainly invalid without any need for complex analysis. As will be noted later, the claims are not directed to scenario a).
18. Scenarios b) and c) create unpredictable non-compliance. That is, a compliant block was entered and only later became non-compliant after submission of one or more other blocks. This seems to be the problem that the specification is directed to handling – unpredictable non-compliance.
19. The specification describes a solution to unpredictable non-compliance whereby the consensus operating procedures are applied to create a corrective block. That block is then added to the blockchain and the system flags other potentially affected blocks. These steps are reflected in fig.2. Note that steps 201-218 seem to reflect including a transaction in the blockchain in the first instance, whereas steps 220-230 are directed toward processing the correction.
20. Paragraph [0039] discusses the type of corrections which may be made. I note that the claimed invention is limited to situations in which at least the transaction date is corrected:
…a correction may arise from a change to the underlying record entry information 114 (e.g., a change to identification information, amounts, dates, or other record entry information), a change to the applicable consensus operating procedure that results in a change to the record entry (e.g., an error may be discovered in the procedure, an accum value threshold may be adjusted, the incorrect consensus operating procedure may have been previously applied, or other correction), or both…
21. Tables 3, 4, and 5 exemplify pseudocode for various consensus operating procedures. Each one is used to calculate an accumulated value for a particular transaction type. Table 4 shows three scenarios for an In-Network Individual Out-of-Pocket (IIOOP) health insurance claim dependent on whether the balance fully covers the transaction amount, partially covers the transaction amount, or the balance is already exhausted. In each case the consensus operating procedures dictate how to calculate the remaining Balance and Out of Pocket Limit. I have repeated table 4 below.
22. Paragraph [0044] discusses flagging blocks for review when they have potentially been affected by a correction. These flags may be written in various places including in the corrective block or in metadata for the affected block:
When blocks may be affected by a correction (e.g., the corresponding record entries are: associated with accumulated values within an affected range, associated with dates within an affected range, or both), the consensus logic 170 may mark affected blocks or data within blocks for review (230). For example, the consensus logic 170 mark blocks by adding a review indicator referencing an affected block to the corrective block. Additionally or alternatively, consensus logic 170 may add the review indicator to metadata for affected block, which may be stored outside of the blockchain 199.
23. Paragraph [0079] discusses handling of flagged blocks as follows:
In the various usage scenarios, the BMC [blockchain management circuitry] may mark claims for review by adding flag bits with the claim ID to the blockchain. The flag bits may cause the node circuitry to generate prompts to initiate manual review of the affected claims. Additionally or alternatively, the BMC may initiate corrective action. For example, the BMC may send a message that causes the node circuitry to issue refunds or send additional invoicing.
24. There is no further description of what the manual review or corrective action entails.
Consensus operating procedures
25. The consensus operating procedures that have been described appear to be different to a typical consensus mechanism (which the person skilled in the art would have been familiar with). It does not fit the definition in the KPMG document either which reads as follows in Appendix 1: Key terminology:
Consensus mechanism
A method to authenticate and validate a set of values or a transaction without the need to trust or rely on a centralized authority; can be constructed on and off a blockchain; a variety of approaches exist
26. The consensus operating procedures that have been described do not define “A method to authenticate and validate a set of values or a transaction without the need to trust or rely on a centralized authority…” [emphasis added]. They instead provide rules which could be used to validate transactions only; to confirm that a correct calculation has been made. As a result, the present invention requires a centralised authority to authenticate transactions. In this case that appears to be the BMC.
27. Given the disparity between the technical meaning of a consensus mechanism and the consensus operating procedures that are described, plainly an alternate meaning was intended. The specification refers to the consensus operating procedures as terms, or smart contract terms, a definition which matches what is shown in Table 4. See for example from paragraphs [0019], [0022], and [0032]:
When multiple nodes coordinate to place entries in a record, the parties represented by the multiple nodes may be dependent on other nodes following the consensus operating procedure or terms when creating entries in the record…
When a node follows the consensus operating procedure during posting of an entry, e.g., by complying with the terms of the smart contract…
…The consensus operating procedure may be codified in consensus operation procedure definitions 172 (e.g., smart contract terms)…
28. The person skilled in the art would interpret the phrase “consensus operating procedure” as contractual terms. Specifically, rules to calculate the result of a transaction.
Overview of the invention as described
29. As discussed above, the specification describes a system which handles unpredictable non-compliance with a set of rules. After receiving a correction to a previous entry, the system selects the appropriate rules, applies them to the correction, and generates a corrective block which is added to the blockchain. Other potentially affected blocks are marked for review with those blocks being addressed by manual review or additional invoicing and refunds.
30. I will note briefly that the invention does not seem to propose a solution to “corrections that ripple through multiple ledger entries”. It is reasonably likely that the manual review step would put a stop to any such ripple and thus solve the problem. Referring to paragraph 16 of this decision, it is also reasonably likely that rejecting invalid blocks would stop the ripple before it even starts. As will be clear momentarily, neither of those are part of the claimed invention though.
Claims
31. The specification includes 20 claims with independent claims 1, 8, and 12 being directed to a “Computer-implemented method”, “A device”, and “A system” respectively. I will repeat and discuss claim 1 below. Because of their similarly my discussion is equally applicable to claims 1, 8, and 12.
1.A computer-implemented method including:
in a record entry hardware system:
receiving, at a blockchain application programming interface (API) executing on blockchain management circuitry (BMC), a message from node circuitry in communication with client circuitry;
determining, at the BMC, a correction for a previous record entry stored within a single blockchain, the previous record entry associated with the client circuitry, the correction including changing an original transaction date for the previous record entry to a corrected transaction date;
at consensus logic within the BMC and in communication with the blockchain API:
accessing, in memory within the BMC, an identifier of a consensus operating procedure, and
selecting the consensus operating procedure responsive to the single blockchain,
the consensus operating procedure detailing a rule for an application to block content prior to appending blocks to the single blockchain;
obtaining a previous accumulated value stored within a selected block of the single blockchain and generated without the correction;
applying the consensus operating procedure to generate a corrected accumulated value from the previous accumulated value;
where the applying includes performing a processor-level operation using the correction and the previous record entry as inputs; andgenerating a corrective indicator including:
a reference to the previous accumulated value and the selected block; and
the corrected accumulated value;
generating a hash value using content of a previous block in the single blockchain;
after complying with the consensus operating procedure, generating a corrective block for the single blockchain,
the generating the corrective block responsive to the corrective indicator and the hash value generated using the content of the previous block;
designating a period of review between the original transaction date and the corrected transaction date; and
marking, for review, a specific existing block storing a specific record entry with an affected transaction date during the period of review by adding a review indicator for the specific existing block to metadata for the blockchain.
32. Whilst not explicitly stated, the claim is laid out in chronological order with earlier steps being precedent to later steps. Initially a message is received at the BMC from a node. That message is non-descript. However, plainly it contains enough information for the BMC to then determine the need for “changing an original transaction date for the previous record entry to a corrected transaction date”. Of note, the correction must at least change a transaction date. Other fields may also be changed such as those noted in paragraph [0039]:
…For example, a correction may arise from a change to the underlying record entry information 114 (e.g., a change to identification information, amounts, dates, or other record entry information), a change to the applicable consensus operating procedure that results in a change to the record entry…
33. The claim then specifies that a consensus operating procedure is selected and accessed from the memory of the BMC. That consensus operating procedure is then applied to generate a corrected value with a previous accumulated value being part of the calculation. There is little specificity as to which entity performs each of these actions, although it is likely that they are performed by the BMC. The claim is not limited as such though.
34. The claim follows with a corrective block being generated including a hash of the previous block. Presumably that is as is typical for all blockchains; i.e. the block contains a hash of the immediately preceding block.
35. Finally, a period of review is designated between the original and corrected transaction dates. At least one block with a record in that period is marked for review. The claim is not limited in relation to the review.
The examiner’s objection
36. Three adverse reports have been issued in the examination of this application. Each report included an objection to manner of manufacture, the only outstanding matter at present. The latest form of that objection is item number 3 from examination report number 3.
37. As best understood the examiner considers that the substance of the invention is an administrative scheme of determining the need to correct a record followed by a series of steps to affect the correction. The examiner asserts that this problem exists when a node in a blockchain record system fails to follow protocol and thus is an administrative issue of following instructions rather than a technical issue. The examiner also asserted that other technical issues such as reduced processing load are derived from that administrative scheme and thus do not provide a patentable contribution.
38. In short, the examiner appears to consider that the substance of the invention lies in an administrative scheme which forces nodes to follow protocol.
The Applicant’s submissions
39. The Applicant has emphasised various portions of claim 1 as follows. As best understood, these have been emphasised because they are said to be technical in nature and to represent steps taken within the computer in a technical capacity:
oSelecting the appropriate consensus operating procedure.
oApplying that consensus operating procedure to produce a corrected accumulated value.
oGenerating a corrective block for the blockchain.
oAdding a review indicator into metadata for the blockchain to identify potentially effected blocks.
40. Whilst the Applicant has identified the above portions of the claim, they have also asserted that the claim should not be dissected but rather considered as a whole. In support Aristocrat Technologies Australia Pty Limited v Commissioner of Patents [2020] FCA 778 (“Aristocrat ‘20”) and Jagwood Pty Ltd [2020] APO 38 (“Jagwood”) are referenced.
41. The Applicant asserts that the problem being addressed is characterised by paragraph [0019] of the specification. Paragraph [0019] addresses how nodes are dependent on other nodes following the consensus mechanism and goes on to describe how non-compliance by a node leads to corrections which ripple through the blockchain and create additional hardware processing.
42. In short, the Applicant appears to consider that the invention gives rise to a reduced processing load which is required to operate the system. The Applicant has submitted that this is a technical solution to a technical problem and is thus patentable.
43. The above summary reflects submissions the Applicant made initially in preparation for this matter to be heard. As noted earlier, further submissions were provided on 28 January 2022 following an invitation to do so.
44. In these further submissions the Applicant submitted that “generic computer implementation” is not a relevant factor in determining patentability and referenced Aristocrat ’21 and CCOM Pty Ltd v Jiejing [1994] 51 FCR 260 (“CCOM”) in support. I have focussed on whether there is an improvement in computer technology as suggested in paragraph [38] of Aristocrat ’21 and accorded little weight to whether the computer itself is generic or not.
45. The Applicant has reiterated earlier submissions to emphasise that there is an improvement in computer technology. Further submissions have been made in relation to CCOM in support of this position. Those submissions have been fully considered in making my decision.
46. Finally, the Applicant has discussed other office decisions such as eBay Inc. [2020] APO 49 (“eBay”) and ANT. Those decisions were made on their facts with regard for the law regarding manner of manufacture as articulated in court decisions referenced below, as will the present decision.
Manner of manufacture: Legal principles
47. Section 18(1)(a) of the Patents Act 1990 states:
(1) Subject to subsection (2), an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim:
(a)is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies;
48. An early decision in relation to business methods is Cooper’s Application for a Patent [1901] 19 RPC 53 (“Cooper”) where the following was stated at [54]. This text has been relied upon frequently and seems to be well established law:
You cannot have a Patent for a mere scheme or plan – a plan for becoming rich; a plan for the better government of a State; a plan for the efficient conduct of business
49. The broad principles to consider manner of manufacture have been set out in National Research Development Corporation v Commissioner of Patents [1959] HCA 67 (“NRDC”). At [269]:
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?"
50. Further guidance was provided in D'Arcy v Myriad Genetics Inc [2015] HCA 35 (“Myriad”) to look for the substance of the invention. This is reflected in [87] & [88] by the majority and repeated by the minority at [144] quite succinctly:
Whatever words have been used, the matter must be looked at as one of substance and effect must be given to the true nature of the claim.
51. Aristocrat Technologies Australia Pty Limited [2016] APO 49 (“Aristocrat ‘16”) summarised considerations appearing in Grant v Commissioner of Patents [2006] FCAFC 120 (“Grant”), Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150 (“Research Affiliates”), and Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (“RPL”) at [35] as follows:
othere must be more than an abstract idea, mere scheme or mere intellectual information;
ois the contribution of the claimed invention technical in nature;
odoes the invention solve a technical problem within the computer or outside the computer;
odoes the invention result in improvement in the functioning of the computer, irrespective of the data being processed;
odoes the application of the method produce a practical and useful result;
ocan it be broadly described as an improvement in computer technology;
odoes the method merely require generic computer implementation;
ois the computer merely an intermediary or tool for performing the method while adding nothing of substance to the idea;
ois there ingenuity in the way in which the computer is utilised;
odoes the invention involve steps that are foreign to the normal use of computers; and
odoes the invention lie in the generation, presentation or arrangement of intellectual information.
52. These seem to represent a well-tested approach to assess patentability for computer implemented inventions. I note that later decisions including Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161 (“Encompass”), Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 (“Aristocrat ‘21”), and Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223 (“Repipe”) have not diverted from this approach in any meaningful way.
Considerations
53. The examiner’s assessment is that the invention comprises a series of steps which relevant parties should follow to create an efficient transaction. They have observed that the invention is about whether nodes follow protocol or not, and thus is a matter of administration only. I am not satisfied with this explanation. As noted earlier, the specification discusses direct non-compliance in paragraph [0022]. That is a trivial problem and not the subject of the claimed invention. The invention is directed toward unpredictable non-compliance.
54. The Applicant has asserted that the invention is about using hardware resources efficiently. The Applicant has noted that the method steps are undertaken in a computer, presumably suggesting that they are not simply about following rules but are instead technical steps. I am not satisfied with this explanation either for a few reasons:
- I am hesitant to accept that there is an efficiency gain at all. However, assuming that there is one, the efficiency gain seems to stem from either declining invalid requests or manual intervention. These are simply non-technical administrative choices where any technical effect is incidental to the administrative choice per se.
- Assuming the efficiency gain is real that does not preclude the invention itself being administrative in substance. Good administration is often directed at saving time using arrangement or organisation that is non-technical.
55. At a high level I consider that the invention is akin to record keeping. When the node submits a correction, flow on effects of that correction are marked for review. Subsequent issues are then handled via manual intervention, invoicing, and refunds.
Does the invention solve a technical problem within the computer?
56. The claimed invention is directed toward handling unpredictable non-compliance arising from correcting a transaction date. Whilst the correction itself will be compliant (it would be ignored if not), as noted earlier, a compliant correction can invalidate other dependent entries which were previously compliant. This issue is not unique to the blockchain implementation which has been claimed though. It exists because of the calculation type rather than the technology on which the calculation is made.
57. For example, while the specification describes the problem in terms of blocks, the issue really exists in terms of records. That is, the transaction date of any record being moved when other records are dependent on it. These issues persist irrespective of how those records are stored or what type of information they include provided there is a dependency.
58. The claimed invention clearly involves computer technology. Beyond just the preamble which reads “A computer-implemented method”, plainly blockchain cannot reasonably be implemented outside a computer.
59. From the above I conclude that the claimed invention is limited to computer implemented methods. However, whilst not claimed, the method at a general level is equally applicable to all methods of calculating an accumulated value (computerised or not). This suggests that the substance of the invention is a computer implemented method of administration. I would otherwise have expected the computer be more clearly defined and key to the operation and benefits of the invention.
60. While I am satisfied that the invention solves a problem, I am not satisfied that it is a technical problem within the computer. Rather, it solves an administrative problem which exists independently of the computer.
Does the application of the method produce a practical and useful result?
61. The Applicant has asserted that the claimed invention results in fewer hardware resources being used. As stated earlier, I find this result to be questionable. However, assuming it is true, then when implemented in a blockchain as claimed, improved efficiency is clearly a useful and practical result in that computing resources are saved. I note that useful and practical in this sense does not necessarily imply that the improved efficiency arises from or provides a technical effect.
62. My hesitancy in relation to the stated benefits could lead to questions about utility and whether the invention achieves the promised benefit or not. I will not make any decision about that because the ground of utility has not been raised during examination, so the Applicant has not had an opportunity to make submissions about utility. While I could invite submissions doing so would unnecessarily complicate the present matter.
Can the invention be broadly described as an improvement in computer technology?
63. The claimed invention is limited to correcting an accumulated value in a blockchain implementation. Blockchain per se could be considered an improvement in computer technology; it uses computer technology in a unique way to create an arrangement of information whereby authenticity, validity, and other aspects of a transaction can be verified without a central authority.
64. Whilst the present invention is limited to blockchain implementation, the improvement is not in the blockchain itself. It is instead in the way that a correction is implemented to minimise the number of calculations made. In this way I consider that the improvement is in limiting when the computer is used rather than how it is used. For example, the invention proposes manual intervention as a solution to corrections which ‘ripple’ through multiple ledger entries.
65. The Applicant has compared the present invention to CCOM to support a finding that there is an improvement in computer technology. I don’t find this to be persuasive because in CCOM there is an improvement in the data structure that facilitates the easier or improved finding of items in a computer implemented searching device using a keyboard; ordering characters by their constituent strokes rather than the number of strokes. As noted above, the present invention improves when the computer is used rather than how it is used or the blockchain. As such the facts of these two cases differ substantially.
66. I do not consider that the present invention could be described as an improvement in computer technology, but rather, an improvement in administering the calculation of accumulated values.
Is the computer merely an intermediary or tool for performing the method while adding nothing of substance to the idea?
67. As noted earlier the claimed invention is clearly computer implemented. However, neither the problem nor the solution is intrinsically tied to the computer beyond the fact that a computer is required to implement a blockchain. I consider that the computer is an intermediary and adds nothing of substance to the invention.
Does the invention lie in the generation, presentation or arrangement of intellectual information?
68. There is no suggestion that the present invention generates information that is different to that of the prior art. As such, the invention cannot reasonably be the information per se. As such the invention is not merely presentation of information.
Summary
69. As noted in paragraph 55 the invention is a system of maintaining accurate records after correcting an earlier record.
70. In deciding whether the invention is for a manner of manufacture, after considering all factors, my conclusion that this invention does not solve a technical problem within the computer is a strong factor. Despite the fact the claimed invention is limited to a computer environment, in substance, the invention remains administrative. I consider that this aligns with other factors which support the notion that the computerised blockchain environment is the platform within which the substance of invention is implemented.
71. Turning to the useful and practical result, I consider this to be a weak factor. As noted in Cooper, “You cannot have a Patent for… a plan for the efficient conduct of business”. I consider that the potential efficiency gains here are a result of improved administration only rather than a technical improvement. That is, there is a useful result which has practical utility, but it arises from a non-technical mechanism. Accordingly, I accord this factor low weight.
72. I have noted that the invention is not directed to merely presentation of information.
73. In summary, after weighing up all factors, the substance of the invention is not technical in nature. It does not solve a problem with the computer, provide an improvement in computer technology, and does not result in a technical arrangement of information that is any different to blockchains of the prior art. Whilst the blockchain implementation claimed is intrinsically computerised, the administrative review of records is not. There is potentially a useful and practical result in that it represents good administration. However, set against the factors that weight against a finding of patentability that is not enough.
Conclusion
74. For the above reasons I find that claims 1-20 are not for a manner of manufacture.
75. Further, there does not appear to be any subject matter in the specification which could be introduced to overcome this issue. As such, I see no reason to remit the application for further examination and I therefore refuse the application.
Tim Gillett
Delegate of the Commissioner of Patents
0
2
0