Advanced New Technologies Co., Ltd.
[2021] APO 29
•21 July 2021
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Advanced New Technologies Co., Ltd. [2021] APO 29
Patent Application: 2018243625
Title:Method and apparatus for processing transaction requests
Patent Applicant: Advanced New Technologies Co., Ltd.
Delegate:Ranganath Subbarayan
Decision Date: 21 July 2021
Hearing Date: Written submissions filed on 22 January 2021
Catchwords: PATENTS – section 45 – examiner’s objections – blockchain technology – whether invention is a manner of manufacture – whether the specification provides a full disclosure – is it a business scheme? – does it address a technical problem? – is the solution technical in nature? – does it require only generic computer implementation? – is there a practical and useful result? – on balance invention is a manner of manufacture – provides full disclosure – doubts about inventiveness – application referred back to examination
Representation: Patent attorney for the Applicant: Cotters Patent & Trade Mark Attorneys
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2018243625
Title:Method and apparatus for processing transaction requests
Patent Applicant: Advanced New Technologies Co., Ltd.
Date of Decision: 21 July 2021
DECISION
The claims of the present application, as proposed to be amended, are for a manner of manufacture and the specification provides a clear enough and complete enough disclosure. Neither of these two examiner objections can be sustained.
However, as I have serious concerns about the inventiveness of the claimed invention, I will refer the application back to examination in order to reassess the inventiveness of the claimed invention and, if warranted, issue another adverse report. If not, it may proceed to acceptance.
Pursuant to sub-regulation 13.4(3), the final date to gain acceptance is set at six (6) months from the date of this decision.
REASONS FOR DECISION
BACKGROUND
Patent application 2018243625 in the name of Advanced New Technologies Co., Ltd. (the Applicant) was filed on 21 March 2018 as a PCT application (PCT/US2018/023517) and claims an earlier priority date of 28 March 2017. The Applicant requested examination of the application on 11 September 2019.
A first examination report issued on 23 January 2020 finding that all the claims were not for a manner of manufacture and also lacked an inventive step.
The Applicant responded on 27 May 2020 with proposed amendments to the description and claims and submissions as to why the amended claims were for a manner of manufacture and were inventive.
A second examination report issued on 25 June 2020 maintaining that all the claims were still not for a manner of manufacture and also lacked an inventive step.
The Applicant responded on 27 October 2020 with submissions in rebuttal arguing that the amended claims were for a manner of manufacture and were also inventive.
A third examination report issued on 5 November 2020 again maintaining that all the claims were still not for a manner of manufacture but withdrawing the lack of inventive step objection.
The Applicant responded on 8 December 2020 with proposed amendments to the description and claims and submissions as to why the amended claims were for a manner of manufacture.
A fourth examination report issued on 7 January 2021 that maintained that all the claims were still not for a manner of manufacture and introduced a new objection that the complete specification did not provide a clear enough and complete enough disclosure of the claimed invention as required by subsection 40(2)(a).
The Applicant responded on 22 January 2021 requesting to be heard in relation to the outstanding objections along with submissions as to why these outstanding objections should be withdrawn.
The Commissioner wrote to the Applicant on 9 February 2021 advising them that the hearing would be done through written submissions and giving them one month to file their submissions.
On 12 March 2021, the Applicant advised that they did not wish to file any additional written submissions.
This decision is therefore based on the submissions made by the Applicant in response to the four examination reports.
APPLICABLE LAW
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”). Amendments to sections 7, 40 and 49 of the Act apply to the present case as a consequence of Schedule 1, items 55(1)(d) and 55(4)(a), and Schedule 6, item 133(7)(d) of the Raising the Bar Act. 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.
Section 18 of the Patents Act 1990 relevantly provides that:
(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; and …Section 40 of the Patents Act 1990 relevantly provides that:
(2) A complete specification must:
(a) disclose the invention in a manner which is clear enough and complete enough for the invention to be performed by a person skilled in the relevant art; and ………
(3) The claim or claims must be clear and succinct and supported by matter disclosed in the specification.
THE INVENTION
The present invention relates to blockchain networks and more specifically to methods and systems for processing transaction requests in a blockchain network.
The specification provides a very brief explanation of a blockchain network.
“The blockchain network, also known as the distributed ledger network, is characterized by decentralization, openness, and transparency. A blockchain network comprises blockchain nodes each capable of initiating a transaction request and participating in consensus verification on a transaction request. All blockchain nodes are synchronized with the blockchain”.[1]
[1] Specification at [3]
A brief explanation of how a typical transaction request is processed is then given.
“An existing method to process a transaction request is as follows: with respect to a transaction, a blockchain node that participates in this transaction broadcasts a transaction request for this transaction to all consensus nodes (blockchain nodes in charge of consensus verification) in the blockchain network, the transaction request comprising transaction data of this transaction. The transaction data is saved into the blockchain after the transaction data passes consensus verification by all the consensus nodes”.[2]
[2] Specification at [4]
The specification notes that with such a process there are privacy security issues.
“However, since all the consensus nodes can synchronize with the blockchain to obtain transaction data of each transaction stored on the blockchain, it easily leads to leakage of the privacy of some blockchain nodes participating in transactions and that is comprised in the transaction data. Moreover, even if the transaction data stored on a blockchain are encrypted, there is still a risk that the encrypted transaction data can be decrypted”.[3]
[3] Specification at [5]
The present invention is therefore stated to be directed to solving this problem.
“Therefore, there is a need to solve the technical problem of how to design a method for verifying a transaction request, such that there is no risk for privacy breach of a blockchain node participating in the transaction”.[4]
[4] Specification at [6]
The specification then describes different ways of processing a transaction request which it says will overcome the possibility of a privacy breach. A broad summary of the invention is given as follows.
“According to one aspect, a method for processing a transaction request implementable by a first transaction node may comprise: acquiring transaction data of a target transaction, wherein the first transaction node participates in the target transaction; determining, according to the transaction data, a transaction abstract after a plurality of transaction nodes each sign a data abstract of the transaction data, wherein the transaction nodes comprise at least the first transaction node and one or more second transaction nodes; generating a transaction request that comprises the transaction abstract; and broadcasting the transaction request to one or more consensus nodes, causing the consensus nodes to each save the transaction abstract in the transaction request into a blockchain after the transaction abstract passes consensus verification, the consensus nodes being blockchain nodes, wherein the transaction nodes and the consensus nodes are blockchain nodes of a blockchain network. The one or more transaction nodes may or may not comprise the first transaction node. The consensus nodes and the one or more transaction nodes may or may not overlap”.[5]
[5] Specification at [8]
The method of the present invention is implemented by a plurality of nodes that are coupled to each other in a blockchain network. A node may be a computing device such as a computer or a server. A transaction node is one that participates in a target transaction and a consensus node is one that participates in consensus validation.
The invention defined in the proposed amended claims is schematically shown in figures 3A-3C which show a block chain network with 10 nodes numbered 1-10, with the hatched nodes representing transaction nodes some or all of which can also be consensus nodes and the non-hatched nodes representing exclusive consensus nodes. These figures are reproduced below.
The method of the claimed invention involves the following steps:
Step 101: Acquiring transaction data of a target transaction.
This step of the method is performed by a first node amongst the group of transaction nodes that participates in a target transaction. According to the specification a target transaction may be any one of a variety of transactions that a blockchain may be involved with. Transaction data of the target transaction may comprise any data associated with the target transaction such as the subject matter of the transaction, an account address or ID of a subject that participates in the target transaction and may also include privacy information of blockchain nodes that participate in the target transaction.
Step 102: Determining a transaction abstract according to the transaction data.
In this step, the first transaction node generates a data abstract of the transaction data wherein the generated data abstract is characterised in that the plaintext transaction data cannot be obtained reversely through the data abstract. The specification notes that one method of generating a data abstract is through the use of a one-way hash function, which I note is a technique well-known in the art.
The first transaction node then communicates the data abstract to all of the transaction nodes that participate in the target transaction and requests a digitally signed copy of the data abstract from the other transaction nodes. The obtaining of the multiple digital signatures may be done in a number of ways such as broadcasting multiple digital signatures or ordered multiple digital signatures.
If all the other transaction nodes sign the data abstract, the transaction has been authenticated or approved by all of them and then based on the signed copies of the data abstracts, the first node generates a transaction abstract. If one or more transaction nodes do not sign the data abstract, the transaction abstract will not be generated.
In one of the embodiments, the transaction data is also sent to the transaction nodes along with the data abstract, so that they can verify the authenticity of the transaction before they sign the data abstract, but the transaction data will be stored by the transaction nodes only in a private database outside of the blockchain.
Step 103: Generating a transaction request that comprises the transaction abstract.
In this step of the claimed embodiment the first node generates a transaction request comprising the transaction abstract but not the transaction data.
Step 104: Broadcasting the transaction request to one or more consensus nodes.
In this step the first transaction node, then broadcasts the transaction request to a plurality of
consensus nodes of the blockchain network for their verification. If the transaction request passes the consensus verification, the transaction abstract is saved in the consensus nodes.
The specification notes that “For a target transaction, as long as a blockchain stores a transaction abstract determined according to the transaction data of the target transaction, it can show that the target transaction is authentic, and there is no need for all the consensus nodes to perform consensus verification on the transaction data of the target transaction”.[6]
[6] Specification at [56]
The method of claim 1 is stated to overcome the privacy breach issues of the prior art because the transaction data will not be broadcast to the consensus nodes and nor will it be stored in the blockchain.
“By the method for processing a transaction request shown in Fig. 1, a transaction request broadcast by a transaction node to all consensus nodes comprises a transaction abstract, but the transaction request does not comprise transaction data. As a result, when the transaction request passes consensus verification, the consensus nodes will not save transaction data into a blockchain, and there will be no risk for the privacy of the transaction nodes to be leaked. At the same time, the transaction abstract is obtained after all transaction nodes sign the data abstract of the transaction data. As a result, even when there is no transaction data stored in
the blockchain, the authenticity of the transaction request can still be proved through the data abstract recognized by all transaction nodes, such that none of the transaction nodes can deny the target transaction corresponding to the transaction request”.[7][7] Specification at [67]
The specification notes that the present invention may be implemented by apparatus comprising a processor and a memory, with the memory storing instructions that can be executed by the processor to perform the claimed method. A typical implementation device is a computer, such as a personal computer, a smart phone, a personal digital assistant or a wearable device.
The proposed amended claims as filed by the Applicant on 8 December 2020 are as follows:
1. A method for processing a transaction request, implementable by a first transaction node, the method comprising:
initiating, by the first transaction node, a target transaction that a plurality of transaction
nodes participate in, wherein the plurality of transaction nodes comprise the first transaction node, and wherein the plurality of transaction nodes are blockchain nodes of a blockchain network;acquiring, by the first transaction node, transaction data of the target transaction;
generating, by the first transaction node, a data abstract according to the transaction data,
wherein the transaction data cannot be obtained reversely through the data abstract;determining, at the first transaction node, a transaction abstract according to the data
abstract after the data abstract is digitally signed by all of the plurality of transaction nodes that participate in the target transaction, the transaction abstract recognizing the authenticity of the target transaction by all of the plurality of transaction nodes, wherein determining the transaction abstract comprises:digitally signing, at the first transaction node, the data abstract to obtain a first signed
data abstract; obtaining one or more second signed data abstracts signed respectively by the other transaction nodes; and combining at least the first signed data abstract and the one or more second signed data abstracts to obtain the transaction abstract; orobtaining the transaction abstract from a single signed data abstract signed in a
predetermined order by the first transaction node and the one or more second transaction
nodes;generating, by the first transaction node, a transaction request that comprises the
transaction abstract and does not comprise the transaction data, the transaction abstract
enabling consensus verification without the transaction data; andbroadcasting, via the blockchain network, the transaction request to a plurality of
consensus nodes of the blockchain network, causing the consensus nodes to each save the
transaction abstract in the transaction request into a blockchain after the transaction abstract passes the consensus verification.2. The method according to claim 1, further comprising:
saving the transaction data into a private database corresponding to the first transaction node.3. The method according to claim 2, further comprising:
sending the transaction data from the first transaction node to the other transaction nodes,
causing each of the other transaction nodes to save the transaction data into a private database corresponding to the other transaction node.4. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor of a first transaction node, cause the processor to perform the method of any one of claims 1 to 3.
5. An apparatus, implementable as a first transaction node, comprising a processor and a
non-transitory computer readable storage medium storing instructions that, when executed by the processor, cause the apparatus to perform a method for processing a transaction request, the method comprising:initiating, by the first transaction node, a target transaction that a plurality of transaction nodes participate in, wherein the plurality of transaction nodes comprise the first transaction node, and wherein the plurality of transaction nodes are blockchain nodes of a blockchain network;
acquiring transaction data of the target transaction;
generating a data abstract according to the transaction data, wherein the transaction data cannot be obtained reversely through the data abstract;
determining a transaction abstract according to the data abstract after the data abstract is digitally signed by all of the plurality of transaction nodes that participate in the target transaction, the transaction abstract recognizing the authenticity of the target transaction and the data abstract by all of the plurality of transaction nodes, wherein determining the transaction abstract comprises:
digitally signing, at the first transaction node, the data abstract to obtain a first signed data abstract; obtaining one or more second signed data abstracts signed respectively by the other transaction nodes; and combining at least the first signed data abstract and the one or more second signed data abstracts to obtain the transaction abstract; or
obtaining the transaction abstract from a single signed data abstract signed in a predetermined order by the first transaction node and the one or more second transaction nodes;
generating a transaction request that comprises the transaction abstract and does not comprise the transaction data, the transaction abstract enabling consensus verification without the transaction data; and
broadcasting, via the blockchain network, the transaction request to a plurality of consensus nodes of the blockchain network, causing the consensus nodes to each save the transaction abstract in the transaction request into a blockchain after the transaction abstract passes the consensus verification.
6. The apparatus according to claim 5, wherein the method further comprises:
saving the transaction data into a private database corresponding to the first transaction node.7. The apparatus according to claim 6, wherein the method further comprises:
sending the transaction data to the other transaction nodes, causing each of the other transaction nodes to save the transaction data into a private database corresponding to the other transaction node.8. The method of claim 1, further comprising: causing the consensus nodes to each verify the transaction abstract in the transaction request.
9. The method of claim 8, wherein:
the transaction data is not transmitted to the consensus nodes and not saved into the blockchain.10. The method of claim 8, wherein:
the transaction data of the target transaction comprises at least one of a subject matter of a transaction associated with the target transaction, detailed information of the subject matter, an account address of a subject that participates in the target transaction, or ID information of the subject that participates in the target transaction.11. The method of claim 8, further comprising:
causing the consensus nodes to each save the transaction abstract into the blockchain in response to all of the consensus nodes having verified the transaction abstract.MANNER OF MANUFACTURE
The Examiner’s Objection
The Examiner’s objection in the fourth examination report reads as follows:
“Objection 3 of the previous report is maintained the invention defined in claims 1-11 is not directed to a manner of manufacture within the meaning of s18(1) of the Patents Act. The Applicant in their most recent response has sought to amend the claims to highlight that the substance of the invention is technical in character. More specially the Applicant has sought to include additional features relating to the signing of data abstracts and the generation of the transaction abstract into the independent claims. The Applicant also has provided a number of submissions as to technical nature of the invention namely the claimed invention is implemented via the use of blockchain and thus must logically be technical in nature.
As noted in the previous report it is not disputed that the implementation of a blockchain network requires the use of various technical elements. The fact that the invention involves the use of one or more technical elements or is implemented within a technical environment does not of itself mean that the invention is directed to suitable subject matter for Letters Patent. As was highlighted in Research Affiliates LLC v Commissioner of Patents (“Affiliates”), [2014] FCAFC at [103]:
“… there is a distinction, between mere implementation of an abstract idea in a computer and implementation of an abstract idea in a computer that creates an improvement in the computer”.
This was also highlighted in the decisions in Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161 (“Encompass”) and Commissioner of Patents v Rokt Pty Ltd [2020] FCAFC 86 (“Rokt”), in each of these cases the inventions were implemented in a computing environment but were ultimately held not to directed to patentable subject matter.
As the relevant legal authorities have made clear the assessment of manner of manufacture predicated on an assessment of the substance of the invention. The substance should be assessed based on the claims as properly construed within the context of the specification as a whole in order to arrive at a proper characterisation of the invention.
In their submission of 8 December 2020 the Applicant asserts that the invention does not merely utilise the well known and well understood function of the blockchain network, but rather results in a technical improvement in the operation of the blockchain. More specially the Applicant asserts that the use (sic) signing the data abstract and the generation of the transaction data abstract is foreign to the operation of a blockchain architecture and consequently the use of such features provides for necessary technical character required by the relevant authorities to fall within the bounds of patentable subject matter.
With respect to the signing of data abstract, the Applicant asserts that this is not a typical process employed in the environment of blockchain. As has been noted in previous reports this process equates to nothing more than use of the multi-signature consensus verification which is a fundamental approach utilised in blockchain to ensure validity of the transaction. Under such an approach each transaction is required to be signed by a number of participating parties (i.e. nodes) to establish the validity of the transaction. There is nothing in the specification to suggest that the signing employed in the instant invention involves anything more than the implementation of such a standard process. This view is further reenforced on a plain reading of the specification which does not provide any detail regarding the signing process, rather the specification merely states that each node signs the data abstract. Moreover, it is stated at [66] of the specification that type of multi-signature solution utilised is not limited in any way.
Given the specification leaves the technical implementation of the signing of the abstract to the discretion of the skilled addressee it cannot be said that the contribution and thus the substance of the invention lies in the implementation of this aspect of the claimed invention.
In view of the above it would appear that the ingenuity of the inventors in this instance lies in the generation and utilisation of the transaction abstract. This also being the point advanced by the Applicant i.e. the use of such a transaction abstract is of technical significance and is one which provides the necessary technical character to the alleged invention to qualify it as patentable subject matter. However on a review of the specification little detail is given as to the technical implementation regarding the production of the transaction abstract, other than it is produced by some unspecified algorithm or algorithms which combine the signed data abstracts in some way to produce the desired transaction abstract per paras [45] and [66] of the instant application. As such there does not appear to be any technical intervention or ingenuity in the production of such a data abstract on the part of the inventors.
It is noted that the Applicant in their submissions states that blockchain networks typically send plaintext information relating to the transaction, this is in contrast to the instant invention which utilises the transaction abstract. However, on a plain reading of the specification no information is given as to the data etc contained in transaction abstract, thus it is not apparent on the face of the specification as to whether the format of transaction abstract is plaintext or not. All that can be gleaned from the specification is that the transaction abstract is apparently devoid of any personal information.
Given that the specification as a whole is largely agonistic (sic) regarding the technical implementation of the alleged invention within a blockchain environment, there is no suggestion in the specification or the claims that any part of the substance of the invention lies in the computer implementation. Rather it becomes apparent that the substance of the invention lies in the abstract idea of not sending particular information as part of the transaction processing. Moreover, it is evident from the specification that the substance of the invention lies solely in the content of the data rather than any technical intervention on the part of the inventors.
In view of the above discussion it is clear that the specification merely points to the idea of using a transaction abstract which is devoid of personal information to facilitate the transaction. Here, as was the case in Ecompass (sic), the manner or mode in which the idea is to be carried out in the blockchain environment has not properly characterised it being left to the user to devise an appropriate technical implementation. Consequently the substance of the alleged invention is considered to be directed to an abstract idea of performing a transaction on a blockchain network without the need to transmit personal information.
The Applicant in their submission has made reference to the decision in eBay Inc. [2020] APO 49 ("eBay") with a particular focus on the comments of the delegate regarding the consideration of the combination of features giving rise to a practical and useful result. While it is appreciated that the alleged invention may well have practical utility, the determination of manner of manufacture however is not based solely on a consideration of the practical utility, but rather requires an assessment of the substance based on a consideration of the specification as a whole. Moreover, the delegate in eBay found that the (sic) there was a technical contribution that arose from the particular combination or arrangement of features at issue in eBay, this being in line with the decision in Affiliates and other relevant authorities including Encompass. The facts in consideration in eBay are not considered to be wholly analogous to the present situation, rather as noted above the facts in this case are considered to be more aligned with the considerations set out in Full court decision in Encompass.
It is maintained that the invention so far as claimed is not directed to patentable subject matter within the meaning of s18(1). The substance of the alleged invention concerns the mere implementation of an abstract idea in an unspecified manner within a particular computer/computing environment.
Case Law
The principles of law in respect to manner of manufacture, arising from the High Court decisions in National Research Development Corporation v Commissioner of Patents (“NRDC”), [1959] HCA 67, (1959) 102 CLR 252, and D’Arcy v Myriad Genetics Inc (“Myriad”), [2015] HCA 35, are well-documented in previous office decisions. The authorisation of a case-by-case methodology would also be apparent from the High Court decisions.
That case-by-case approach must have regard to the substance of the claimed invention, not simply the form of the claim. The point was made succinctly in the Myriad case by Gageler and Nettle JJ. At [144]:
“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”.
In Commissioner of Patents v RPL Central Pty Ltd (“RPL”), [2015] FCAFC 177, the Full Court of the Federal Court stated the same thing in the context of an invention that was in substance a scheme. At [96]:
“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”.
Moreover at [98]:
“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”.
In Research Affiliates LLC v Commissioner of Patents (“Research Affiliates”), [2014] FCAFC 150, the Full Court of the Federal Court noted a distinction between mere implementation of an abstract idea in a computer and implementation of the idea in a computer that created an improvement in the computer. At [103]:
“… there is a distinction, between mere implementation of an abstract idea in a computer and implementation of an abstract idea in a computer that creates an improvement in the computer”.
Moreover, at [114] of Research Affiliates:
“The invention set out in the specification is directed to the index itself. The method of the invention is not one that has any artificial or patentable effect other than the implementation of a scheme, which happens to use a computer to effect that implementation. There is no technical contribution to the invention or artificial effect of the invention by reason of the intervention of the inventors”.
In also discussing the requirement for the contribution to be technical, the Full Court in RPL stated as follows, amongst other things, at [99]:
·“It is necessary to ascertain whether the contribution to the claimed invention is technical in nature …
·One consideration is whether the invention solves a ‘technical’ problem within the computer or outside the computer, or whether it results in an improvement in the functioning of the computer, irrespective of the data being processed.
·Does the claimed method merely require generic computer implementation?
·Is the computer merely the intermediary, configured to carry out the method using a computer readable medium containing program code for performing the method, but adding nothing to the substance of the idea? …”.
In Aristocrat Technologies Australia Pty Ltd [2016] APO 49 at [35], a delegate of the Commissioner set out the following non-exhaustive summary of the issues to be considered when applying these principles.
·there must be more than an abstract idea, mere scheme or mere intellectual information;
·is the contribution of the claimed invention technical in nature;
·does the invention solve a technical problem within the computer or outside the computer;
·does the invention result in improvement in the functioning of the computer, irrespective of the data being processed;
·does the application of the method produce a practical and useful result;
·can it be broadly described as an improvement in computer technology;
·does the method merely require generic computer implementation;
·is the computer merely an intermediary or tool for performing the method while adding nothing of substance to the idea;
·is there ingenuity in the way in which the computer is utilised;
·does the invention involve steps that are foreign to the normal use of computers; and
·does the invention lie in the generation, presentation or arrangement of intellectual information.
Background to Blockchains
As the specification only provides a very brief explanation of blockchain technology, it would be useful for the purposes of this decision to provide a bit more background about this technology as it existed at the priority date of the present application. While there are numerous articles on blockchain technology on the internet, the article “Consensus - Immutable agreement for the Internet of value”[8] by Sigrid Seibold and George Samman and published by KPMG on the internet in September 2016 particularly stands out as it provides what I consider an excellent overview of the state of the art in relation to blockchain technology before the priority date of the claimed invention, including various approaches to consensus mechanisms and security/privacy issues within blockchains.
[8] © 2016 KPMG LLPFollowing are some extracts from this article that I found are particularly useful in the context of the claimed invention.
“The basics behind blockchain
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.
As highlighted in Figure 1, the transaction, once created and posted to the network, is signed with the signature of the transaction’s initiator, which indicates the authorization to spend the money, create the contract, or pass on the data parameters associated with the transactions. If the transaction is signed, it is valid and contains all the information needed to be executed.
The transaction is sent to a node connected to the blockchain network, which knows how to validate the transaction based on predefined criteria. Invalid transactions are discarded, while valid transactions are propagated to another three or four other connected nodes, which will further validate the transactions and send them to their peers until a transaction reaches every node in the network. This flooding approach guarantees a valid transaction will reach the whole network within a few seconds. The senders do not need to trust the nodes they use to broadcast the transactions, as long as they use more than one to ensure that the transaction propagates. The recipients do not need to trust the senders either, because the transactions are signed or contain no confidential information or credentials, such as private keys.
Once a transaction is validated and included in a block, it is then propagated to the network. Once the whole network reaches a consensus and the other nodes of the network accept the new block, it is chained into the blockchain. Once recorded on the blockchain and confirmed by sufficient subsequent blocks, the transaction becomes a permanent part of the public ledger and is accepted as valid in principle by all nodes within the blockchain network. There are many different mechanisms that can build this consensus, and programmers and companies are constantly working on new ones. Which consensus mechanism a blockchain uses is at the core of what most defines it”.
“Privacy
– DLTs are taking various measures to ensure privacy. These include:
- Not including customer data on the distributed ledger
- Pseudonymous addresses
- Encryption and permissioning models
- Zero knowledge proofs
- Ring signatures.– Almost all distributed ledger technologies require the use of verifiable authenticity through digital signatures, etc.
– Nodes generally have a certain degree of transparency of all other transactions, except in the case of N2N DLTs”.It is clear from this article, that blockchains are not limited to one type of consensus mechanism and that various alternatives to the traditional consensus mechanisms used in blockchains like Bitcoin are being explored.
It is also clear that the other standard features of typical blockchains include use of digital signatures to recognise authenticity in blockchain transactions as well as the use of encryption and hash functions to store information in each block and to link each block to the preceding block.
The Substance of the Invention
The Applicant has submitted that the substance of the invention is not an abstract scheme that is merely implemented in a computer as alleged by the examiner but is rather a technological innovation that solves a technical problem in blockchain technology.
“Contrary to such an illogical characterisation of the claimed invention, the Applicant submits that the problem addressed by the claimed invention is a technical problem of blockchain technology, and blockchain technology is not just an essential feature of the claimed invention by virtue of clever claim drafting, but rather, integral to the working of the invention because, without the blockchain technology, the claimed invention simply would not work, or provide any effect.
In light of the above discussion, the substance of the claimed invention must logically involve blockchain technology, characterising the substance of the invention as technical in nature. Further, having blockchain technology as an integral feature of the claimed invention, the claimed invention is a technological innovation, not an abstract scheme that is merely implemented in a computer as alleged”.[9]
[9] Applicant’s submissions of 27 October 2020
While I accept that blockchain is integral to the working of the claimed invention and that blockchain is inherently a computer implemented technology, that does not necessarily lead to the conclusion that the claimed invention is a technological innovation. As noted by the authorities, it is important to look at the claimed invention as a matter of substance and not of form.
The specification notes that in a typical blockchain transaction request, the transaction request that is sent to all of the consensus nodes for consensus validation includes the transaction data and that this transaction data is stored by the consensus nodes in the blockchain, thereby potentially exposing the private and confidential information in the transaction data to breaches, even if this information is encrypted. This is the problem that the present invention seeks to address.
The solution proposed by the present invention is to convert the transaction data of the transaction request to a data abstract from which the transaction data cannot be reversely obtained and send this data abstract with or without the original transaction data initially only to the other nodes participating in the subject transaction to get their digital signature as approval for the transaction and then subsequently creating a transaction abstract based on the signed data abstract and sending this transaction abstract alone to all of the consensus nodes including those that do not participate in the subject transaction and getting the required consensus verification based only on this transaction abstract and also for finally storing the transaction abstract in the blockchain.
By sending only the transaction abstract rather than the full transaction data to all of the consensus nodes and because of the fact that the transaction data cannot be reversely obtained from the transaction abstract, the risk of security/privacy breach of the transaction data which would otherwise be stored in the blockchain by the consensus nodes can be reduced or avoided.
The substance of the invention therefore lies in a method of processing a transaction request within a blockchain wherein the transaction data is irreversibly converted into a non-recognisable form (data abstract) and using this data abstract to first get approval for the transaction only from transaction nodes and then use this approved data abstract to then get consensus validation from all of the consensus nodes. By processing the transaction request in this manner, only the data abstract finally gets to be stored in the blockchain and not the transaction data. It is clear from the specification that the basic computer infrastructure that underpins the claimed invention is very much the standard blockchain infrastructure comprising a network of computers that are programmed to communicate and transact with each other.
When the invention is characterised this way, it would appear that this new method of processing a transaction request within what is otherwise a standard blockchain infrastructure includes elements that may be considered technical such as the conversion of the data using cryptographic techniques and elements that may be considered as an abstract scheme such as the modified procedural rules for obtaining consensus validation. It is therefore appropriate to consider some of the other considerations that I have identified earlier.
Does the invention solve a technical problem?
The Applicant has submitted that the claimed invention solves a technical problem within a blockchain.
“The claimed invention addresses a problem of preserving the privacy of blockchain nodes participating in transactions that arises when transaction data is broadcast to consensus nodes of a blockchain network for consensus verification, and the consensus nodes save the transaction data in a blockchain. As noted by the present application,
“[S]ince all the consensus nodes can synchronize with the blockchain to obtain transaction data of each transaction stored on the blockchain, it easily leads to leakage of the privacy of some blockchain nodes participating in transactions and that is comprised in the transaction data. Moreover, even if the transaction data stored on a blockchain are encrypted, there is still a risk that the encrypted transaction data can be decrypted.
Therefore, there is a need to solve the technical problem of how to design a method for verifying a transaction request, such that there is no risk for privacy breach of a blockchain node participating in the transaction.” (See Specification paragraphs 5-6 (emphasis added); see also Specification paragraph 27.)
This problem is caused by a technical configuration of a conventional blockchain system, which is possible only by computer implementation as discussed above, in particular due to the verification/consensus procedure that is central to blockchain technology. Accordingly, the problem is very clearly technical in nature.
The technological solution recited in the claims includes: i) the generation of a data abstract according to the transaction data, where the transaction data cannot be obtained reversely through the data abstract; ii) the determination of a transaction abstract after the data abstract is digitally signed by all of the plurality of transaction nodes that participate in the target transaction, where, the transaction abstract recognizes the authenticity of the target transaction by all of the plurality of transaction nodes; and iii) broadcasting, via the blockchain network, a transaction request that comprises the transaction abstract but not the transaction data. By virtue of having all participating transaction nodes digitally sign the data abstract, the authenticity of the transaction may be proved through the data abstract recognized by the digital signature of all transaction nodes. At the same time, because the transaction data is not included in the transaction request sent to the consensus nodes on the blockchain network, and transaction data cannot be obtained reversely through the data abstract, the consensus nodes will not save the transaction data into a blockchain, and the risk for the privacy of the transaction nodes to be leaked from the blockchain may be eliminated. (See specification paragraphs 35, 39-40, 42-43, 54, and 56.)
The claims thus define a set of concrete, technical features, rather than a mere abstract idea, thus providing a technological solution to the above-discussed technical problem. The claimed invention also provides a practical and useful result, as per as per Grant v Commissioner of Patents [2006] FCAFC 120, paragraph 29, in the form of increased security against privacy breach without compromising the efficacy of the consensus procedure”.
While I accept the Applicant’s submission that the claimed invention is directed to solving the problem of how to design a method for verifying a transaction request, such that there is no risk for privacy breach of a blockchain node participating in the transaction, I am not convinced that this problem is purely a technical one. It is clear from a fair reading of the specification that any breach of privacy data occurs not because of any technological deficiencies in the IT infrastructure of the blockchain but rather because of the form of the data information within the transaction request and the way it is shared amongst the nodes for consensus validation and then storage within the blockchain. It is more to do with the administrative rules employed within a typical blockchain for sharing transaction data for the purposes of obtaining approval for a transaction and then consensus validation before the transaction can be added to the blockchain. In my view, this appears to be more of a business problem relating to the content of the transaction data and the administrative rules for consensus validation within a blockchain rather than a technical problem relating to the blockchain itself. It is no different to information on a piece of paper being insecure by nature of its readily readable and understandable form.
Does the invention provide a technical solution to the problem?
The Applicant has submitted that the claimed invention provides a technical solution to a technical problem.
“The technological solution recited in the claims includes: i) the generation of a data abstract according to the transaction data, where the transaction data cannot be obtained reversely through the data abstract; ii) the determination of a transaction abstract after the data abstract is digitally signed by all of the plurality of transaction nodes that participate in the target transaction, where, the transaction abstract recognizes the authenticity of the target transaction by all of the plurality of transaction nodes; and iii) broadcasting, via the blockchain network, a transaction request that comprises the transaction abstract but not the transaction data. By virtue of having all participating transaction nodes digitally sign the data abstract, the authenticity of the transaction may be proved through the data abstract recognized by the digital signature of all transaction nodes. At the same time, because the transaction data is not included in the transaction request sent to the consensus nodes on the blockchain network, and transaction data cannot be obtained reversely through the data abstract, the consensus nodes will not save the transaction data into a blockchain, and the risk for the privacy of the transaction nodes to be leaked from the blockchain may be eliminated. (See specification paragraphs 35, 39-40, 42-43, 54, and 56.)
The claims thus define a set of concrete, technical features, rather than a mere abstract idea, thus providing a technological solution to the above-discussed technical problem. The claimed invention also provides a practical and useful result, as per as per Grant v Commissioner of Patents [2006] FCAFC 120, paragraph 29, in the form of increased security against privacy breach without compromising the efficacy of the consensus procedure”.[10]
“In any case, it is submitted that signing of information within a blockchain architecture, and in particular in a manner defined in the claims, is a technical feature, and thus constitutes a technical characteristic of the substance of the claimed invention. It is further submitted that this is not a standard operation of a blockchain system, and therefore constitutes a part of the technical solution for addressing the technical problem of privacy protection of a transacting node”.[11]
[10] Applicant’s submissions of 27 May 2020
[11] Applicant’s submissions of 27 October 2020
The examiner is of the view that claimed solution lies in the application of particular data administration rules rather than any invention or ingenuity in any program or any improvement in the involved computing technology. however, I beg to differ.
Each of the steps of the claimed invention either relate to the conversion of transaction data into indecipherable form (data abstract), or how this converted information is then sent to certain nodes (transaction nodes) for digitally approving the transaction and then to certain nodes (consensus nodes) for gaining consensus validation.
For example, the first step of the method involves generating a data abstract of the transaction data so that transaction data cannot be reversely obtained from the data abstract. While not claimed, the specification notes that this can be done using a one-way hash function. This function is a well-known cryptographic technique that is widely used in password management and even in blockchains themselves for storing information in the form of merkle trees within a block and for proof of work consensus. Clearly the use of encryption or cryptography technology to convert the transaction data is a technical step. That fact that this technique may be well-known does not make it any less technical.
The next step is the obtaining of the digital signatures of all of the transaction nodes as approval of the transaction and then generating a transaction abstract. While the specification is silent on what techniques are used to obtain the digital signatures, the Applicant has acknowledged that the “Methods for combining digital signatures or sequential signing of data are known/used in areas of computer technology requiring means for data authenticity”[12]. I agree. While obtaining digital signatures from participating nodes is commonplace in blockchains, it clearly involves the application of information technology encryption techniques such as Public Key Infrastructure (PKI). I am satisfied that there is a technical element to this step.
[12] Applicant’s submissions of 22 January 2021
The remaining steps such as broadcasting the transaction request to all of the consensus nodes for getting their consensus verification and storing the transaction abstract in the blockchain are all standard steps in getting consensus verification in a blockchain. These involve sending the transaction abstract to all of the nodes to get their consensus approval and if consensus based on the agreed consensus protocol is reached, then store the transaction abstract in the blockchain. These steps appear to relate to standard procedural rules for gaining consensus validation in a blockchain. Other than the fact that it is done by computers, there does not seem to be anything technical in these steps.
It is therefore clear that while not all of the steps of the claimed method can be considered to be technical steps, the critical steps of converting the transaction data into an indecipherable data abstract and then generating a transaction abstract based on digitally signed approvals from the transaction nodes involves the application of information technology techniques. On balance, when the claim is considered as a whole, I am satisfied that the claimed invention provides a technical solution to the problem of breach of privacy information.
Does the claimed method require only generic computer implementation?
While the invention as claimed refers to blockchain and nodes, it does not define any other specifics of the computer infrastructure that is used in the claimed blockchain. The Federal Court has in a recent decision, distinguished inventions characterised as apparatus of a specific character and general-purpose computing devices.
“… the invention may be characterised as a machine of a particular construction which implements a gaming function. It yields a practical and useful result. Simply put, the machine that is the subject of the claims is built to allow people to play games on it. That is its only purpose. In this regard, the physical and virtual features of the display, reels, credit input mechanism, gameplay mechanism and game controller combine to produce the invention. It is a device of a specific character.”[13]
[13] Aristocrat Technologies Australia Pty Limited v Commissioner of Patents [2020] FCA 778 at [98]
In the present case, the blockchain of the claimed invention cannot be considered to be such a device. As noted earlier, the specification states that the claimed method may be implemented by standard blockchain apparatus comprising a processor and a memory with the memory storing instructions that can be executed by the processor and that a typical implementation device is a computer, such as a personal computer, a smart phone, a personal digital assistant or a wearable device. All that is required is a suitable software program that when executed by a processor can carry out the steps of the claimed invention. This is also reflected in claim 4 which defines “A non-transitory computer-readable storage medium storing instructions that, when executed by a processor of a first transaction node, cause the processor to perform the method of any one of claims 1 to 3”.
Clearly the invention requires only generic computer implementation.
Is there a practical and useful result?
The next question is whether there is a practical and useful result. The purpose of the claimed method is to prevent breach of privacy data from the transaction data which gets to be stored in the blockchain after consensus validation. This is achieved by converting the transaction into a transaction abstract from which the transaction data or the privacy information therein may not be seen or obtained and storing this in the blockchain. The transaction data never gets to be stored in the blockchain and hence privacy information within the transaction data cannot be obtained from the nodes. In my view, this is a practical and useful result.
Does the invention lie in the generation, presentation or arrangement of intellectual information?
The invention involves the generation and presentation of information by converting transaction data into a transaction abstract and communicating this to all of the consensus nodes for consensus validation. However, the steps are not simply generating and presenting intellectual information. Based on the information, each of the nodes is then required to validate the transaction by doing consensus verification and then storing the transaction abstract in the blockchain. It is not fair to say that the invention lies merely in the generation and arrangement of intellectual information.
Balance of considerations
The present invention relates to blockchains, a computer implemented technology that, in my view, is not inherently unpatentable.
While the potential for breach of sensitive privacy data appears to be more due to administrative rules rather than a technical deficiency in the blockchain IT infrastructure, the solution provided involves application of cryptographic techniques that I consider are technical in nature. Moreover, the invention yields a practical and useful result in providing greater security for information stored in the blockchain. It is also not merely for the generation and/or presentation of intellectual information.
While the claimed invention only requires generic computer implementation, the focus of the invention is not the computer program to carry out the method. Hence the weight that I give to this consideration is quite minimal.
I can see no reason why technical improvements to fundamental mechanisms related to consensus within a blockchain should not be patentable, even though these improvements might not necessarily be addressing technical problems. In my view, the balance of considerations weigh in favour of finding that the claimed invention is a manner of manufacture.
Conclusion in relation to Manner of Manufacture
The invention of claim 1 is for a manner of manufacture.
Although claim 4 relates to a non-transitory computer-readable storage medium, the instructions stored therein when executed perform the method of claim 1. I am therefore satisfied that the same finding in relation to claim 1 can be applied to this claim.
Claim 5 relates to an apparatus comprising a processor and a non-transitory computer readable storage medium storing instructions that, when executed by the processor, cause the apparatus to perform a method for processing a transaction request that comprises all of the features of claim 1. Again, I have no reason to depart from my finding in relation to claim 1.
DISCLOSURE
The Examiner’s Objection
As noted earlier, in the fourth examination report, the examiner has introduced the objection that the specification does not provide a full disclosure as per the requirements of subsection 40(2)(a). The objection reads as follows:
The complete specification does not provide a clear enough and complete enough disclosure of the invention defined in claims 1-11, as required by subsection 40(2)(a).
In their submission of 8 December 2020, the Applicant points out that the generation of the transaction abstract is critical to enable the invention to be put into practice. Moreover, it is in this feature that ingenuity of the invention lies. However, on a review of the specification little detail is provided as to how the transaction abstract is generated or determined in accordance with the instant invention. The specification broadly states that the transaction abstract is obtained after the transaction nodes sign a data abstract see for example paras [34]-[39], [45]- [49]. Moreover at para [45] of the specification states that data abstracts that are collected, are combined according to a specific algorithm, however the specification provides no indication as to what this algorithm is or how such an algorithm produces the transaction abstract. It is also noted that at para [66] of the specification it is stated there is no limitation as to what algorithm is used to combine the data abstract(s) obtained after all transaction nodes sign the data abstract into a transaction abstract. Aside from the references to the use of an algorithm per paras [45] and [66] little guidance is given regarding the generation of the transaction abstract. Rather it would appear on a plain reading of the specification as a whole that the manner in which transaction abstract is derived is entirely left to the discretion of the skilled addressee. Accordingly, the complete specification does not provide sufficient information to enable the skilled person to perform the invention over the whole width of the claims, without undue burden or the need for further invention.
In addition to the above it also follows that claims 1-11 lack proper support under subsection 40(3). As noted above the body of the specification provides insufficient directions as to how to put the claimed invention into practice across the full width of the claims. Moreover given that the manner in which the transaction abstract is to be determined is left entirely to the discretion of the skilled addressee the claims as currently presented encompass possibilities which cannot be readily predetermined or assessed on the basis of what is disclosed.
I apologise for any inconvenience caused by raising new grounds of objection at this late juncture of prosecution. However, on consideration of the Applicant’s response concerning the nature of the inventive concept and on a detailed review of the specification it was considered that the raising of a such a significant ground of objection was appropriate.
Applicant’s Submissions
The Applicant has, in response to the fourth report, submitted as follows:
“The addressee of the present application would be a person skilled in the art in the field of blockchain technology, who is equipped with knowledge of standard techniques used in building and implementation of, at least conventional forms of,
blockchain systems.The Examiner alleges that little detail is provided in the specification as to how the transaction abstract is generated or determined in accordance with the instant invention. However, as discussed above in relation to the patentable subject matter objection, techniques used for generation and determination of the transaction abstract of the claimed invention, including generation of a data abstract, digital signing and combining, are not limited to, nor do they need to be limited to, techniques that are unique to the claimed invention.
Paragraphs 38 and 39 describe generation of a data abstract based on transaction data, stating: ‘The data abstract of the transaction data may be generated according to a one-way hash function, or may be generated according to other functions, as long as such the transaction data cannot be obtained reversely through the data abstract’. It is submitted that this description is sufficient for enabling a person skilled in the art of blockchain technology to understand the attribute of a function required for generation of the data abstract for the claimed invention.
Digital signatures of data (regardless of whether that data is the data abstract of the claimed invention or other types of data) are common not only in blockchain technology but widely in other areas of computer technology requiring means for data authenticity. Methods for combining digital signatures or sequential signing of data are known/used in areas of computer technology requiring means for data authenticity. A skilled person with knowledge of standard techniques in the blockchain technology would therefore be able to understand, upon reading the present specification in the context of the blockchain technology, that such standard techniques can be applied to the processing of the transaction data, data abstract and transaction abstract of the claimed invention.
Accordingly, it is submitted that the present specification does provide sufficient information to enable a skilled person to perform the invention over the whole width of the claims without undue burden or the need for further invention, and objections under s40(2)(a) and s40(3) should be withdrawn”.[14]
[14] Applicant’s submissions of 22 January 2021
Consideration
I am inclined to agree with the Applicant. In relation to the generation of the data abstract, the specification clearly states that this can be done through the use of the one-way hash function. I agree with the Applicant that one-way hash functions as a means of disguising information is common general knowledge in the art and the person skilled in the art would be able to apply this technique to obtain the data abstract without any difficulty or exercise of invention.
Similarly, the obtaining of digital signatures is very much part of the common general knowledge in the art and while the claimed invention defines alternate procedural rules for obtaining digital signatures from each of the transaction nodes, the basic computer techniques for obtaining digital signatures within blockchains still remains the same. I am satisfied that the person skilled in the art would be able to perform these steps of the invention without difficulty or exercise of invention.
The remaining steps of the claimed method relate to the procedural rules for obtaining initial approval for the transaction from only the transaction nodes and then obtaining consensus validation from all of the consensus nodes. I can see no deficiency in the disclosure of the specification which would not allow the person skilled in the art from performing these procedural steps.
I am satisfied that the specification provides a clear enough and complete enough disclosure to perform the invention across its full scope.
I am also satisfied that for similar reasons the claims are also supported by the body of the specification.
This objection of the examiner cannot be maintained.
INVENTIVE STEP
As noted earlier, the examiner raised an inventive objection in the first and second examination reports, but this objection was dropped in the third report based on the submissions from the applicant. However, while reading background material on blockchains in order to better inform myself of the state of the art in relation to this technology at the priority date of the claimed invention, I have come across relevant prior art information that, in my view, casts serious doubts about the inventiveness of the claimed invention. The claimed invention would appear to be no more than a combination of known concepts in blockchains.
For example, the concept of hashing the transaction data and sharing only this hashed data rather than the transaction data with all of the consensus nodes for consensus validation and storing, is disclosed in the following prior art information.
·Four genuine blockchain use cases - Posted May 10, 2016 by Gideon Greenspan – see page 5.
Decentralized Computation Platform with Guaranteed Privacy by Guy Zyskind, Oz Nathan, Alex Pentland, published 10 Jun 2015 – see sections 2-4.
the blockchain – published by Norton Rose Fulbright in August 2016 – see chapter 1, page 23.
>
In relation to the concept of restricting the transaction request approval to a subset of the nodes (transaction nodes) and then sending the approved transaction to all of the consensus nodes for consensus validation, there is again prior art information that strongly suggests that this is well-known in permissioned blockchains. For example, see the following:
·Blockchain: Opportunities for Health Care by RJ Krawiec, Dan Housman, Mark White, Mariya Filipova, Florian Quarre, Dan Barr, Allen Nesbitt, Kate Fedosova, Jason Killmeyer, Adam Israel, Lindsay Tsai – published by Deloitte in 2016 – see page 6
Permissioned Blockchains by Marko Vukolic – published April 2017
>
In the circumstances, it is appropriate that the application be referred back to the examination section for the examiner to review the prior art, perform additional searching if required, and reassess the ground of inventive step.
CONCLUSION
I have found that the claims of the present application, as proposed to be amended, are for a manner of manufacture and that the specification provides a clear enough and complete enough disclosure. Neither of these two examiner objections can be sustained.
However, I have serious concerns about the inventiveness of the claimed invention. I therefore refer the application back to examination in order to reassess the inventiveness of the claimed invention and, if warranted, issue another adverse examination report. If not, it may proceed to acceptance.
In the circumstances, pursuant to sub-regulation 13.4(3), the final date to gain acceptance is set at six (6) months from the date of this decision.
Ranganath Subbarayan
Delegate of the Commissioner of Patents
12
8
0