Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
This office action is in response to the amended listing of claims filed on November 4, 2025. Claims 1-6, 8-14, 16-17, 19-21, and 28-29 are currently pending of which claims 1, 28, and 29 are currently amended.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 5-6, 8-10, 13-14, 16-17, 19-21 and 28-29 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Falco et al (US PGPub No: 2020/0014531), hereafter referred to as Falco.
With regard to claims 1 and 28-29, Falco teaches a computer-implemented method of processing a blockchain transaction, wherein the method is performed by a receiving party and comprises: obtaining one or more probabilistic filters, wherein each probabilistic filter encodes one of i) one or more sets of whitelisted data items, or ii) one or more sets of blacklisted data items (Falco teaches a NeuroNode/lightweight software operating within each device node; see paragraph 120 and Figure 3B, Falco. The NeuroNode receives updates of whitelisted and blacklisted addresses from the NeuroCloud along with security updates in form of control information in blockchain transactions; see paragraphs 122, 138-140, and 166, Falco. The NeuroCloud (whose whitelist/blacklist filter information is within the control information) can run Naïve Bayes; see paragraph 138, Falco. The device node stores at least one command file with at least some of the control information that includes whitelisted and blacklisted IP addresses; see paragraph 51, Falco);
obtaining the blockchain transaction, wherein the obtained blockchain transaction is associated with a candidate data item corresponding to i) one of the one or more sets of whitelisted data items, or ii) one of the one or more sets of blacklisted data items (Falco explains how the control information is within the blockchain transaction; see paragraphs 139 and 144, Falco. The blockchain transactions and control information with security updates are relayed to the NeuroNodes; see paragraph 140, Falco. The control information with security updates contains whitelisted and blacklisted addresses; see paragraphs 122 and 138, Falco);
and determining whether to process the obtained blockchain transaction based on whether the candidate data item is present in at least one of the one or more probabilistic filters (Again, the blockchain transaction has control information with security updates; see paragraph 140, Falco. The control information with security updates contains whitelist and blacklist IP addresses; see paragraphs 122 and 138, Falco. Blacklisted IP addresses are not permitted to be accepted while whitelisted IP addresses are permitted to be accepted; see paragraph 166, Falco. Upon execution, the device controls the communication interface to accept the communication (candidate data) from whitelisted IP addresses and not accept the communications (candidate data) from blacklisted IP addresses; see paragraph 50, Falco).
With regards to claim 2, Falco teaches the method wherein one of the one or more sets of whitelisted data items comprises a set of whitelisted blockchain addresses, wherein one of the one or more sets of blacklisted data items comprises a set of blacklisted blockchain addresses, and wherein the candidate data item is a candidate blockchain address (The blockchain transaction has control information with security updates; see paragraph 140, Falco. The control information with security updates contains whitelist and blacklist IP addresses; see paragraphs 122 and 138, Falco. Blacklisted IP addresses are not permitted to be accepted while whitelisted IP addresses are permitted to be accepted; see paragraph 166, Falco. Upon execution, the device controls the communication interface to accept the communication (candidate data) from whitelisted IP addresses and not accept the communications (candidate data) from blacklisted IP addresses; see paragraph 50, Falco).
With regards to claim 5, Falco teaches the method wherein determining whether to process the obtained blockchain transaction comprises determining whether to accept the obtained blockchain transaction for publishing in a block of the blockchain (Upon execution, the device controls the communication interface to accept the communication (candidate data) from whitelisted IP addresses and not accept the communications (candidate data) from blacklisted IP addresses; see paragraph 50, Falco).
With regards to claim 6, Falco teaches the method wherein: i) at least one probabilistic filter encodes the set of whitelisted blockchain addresses, and wherein the method comprises accepting the obtained blockchain transaction on condition that the candidate blockchain address is present in the at least one probabilistic filter; or ii) at least one probabilistic filter encodes ii) the set of blacklisted blockchain addresses, and wherein the method comprises accepting the obtained blockchain transaction on condition that the candidate blockchain address is not present in the at least one probabilistic filter (The blockchain transaction has control information with security updates; see paragraph 140, Falco. The control information with security updates contains whitelist and blacklist IP addresses; see paragraphs 122 and 138, Falco. Blacklisted IP addresses are not permitted to be accepted while whitelisted IP addresses are permitted to be accepted; see paragraph 166, Falco. Upon execution, the device controls the communication interface to accept the communication (candidate data) from whitelisted IP addresses and not accept the communications (candidate data) from blacklisted IP addresses; see paragraph 50, Falco).
With regards to claim 8, Falco teaches the method wherein obtaining the blockchain transaction comprises obtaining a block comprising the blockchain transaction, and wherein determining whether to process the obtained blockchain transaction comprises determining whether to validate the block comprising the obtained blockchain transaction (Falco teaches a blockchain with blockchain transactions and validating new blocks on blockchains; see paragraph 83, Falco).
With regards to claim 9, Falco teaches the method wherein: i) at least one probabilistic filter encodes the set of whitelisted blockchain addresses, and wherein the method comprises validating the obtained block on condition that the candidate blockchain address is present in the at least one probabilistic filter; or ii) at least one probabilistic filter encodes ii) the set of blacklisted blockchain addresses, and wherein the method comprises validating the obtained block on condition that the candidate blockchain address is not present in the at least one probabilistic filter (Falco teaches a blockchain with blockchain transactions and validating new blocks on blockchains; see paragraph 83, Falco. A new block is added (i.e. blockchain is updated) when the blockchain transaction is whitelisted; see paragraphs 50 and 140, Falco).
With regards to claim 10, Falco teaches the method wherein one of the one or more sets of whitelisted data items comprises a set of whitelisted unspent transaction outputs, and wherein the one or more sets of blacklisted data items comprises a set of blacklisted unspent transaction outputs, and wherein the candidate data item is a candidate unspent transaction output referenced by the obtained blockchain transaction (Falco supports determining the balances (unspent) for the transactions to extract the whitelisted and blacklisted IP addresses; see paragraph 152, Falco).
With regards to claim 13, Falco teaches the method wherein the one or more sets of whitelisted data items comprises a set of whitelisted blockchain transaction identifiers, and wherein the one or more sets of blacklisted data items comprises a set of blacklisted blockchain transaction identifiers, and wherein the candidate data item is a candidate transaction identifier of the obtained blockchain transaction (Falco teaches blacklisted and whitelisted IP addresses (identifiers); see paragraph 122, Falco. The communications received and assessed are IP addresses (candidate identifiers)).
With regards to claim 14, Falco teaches the method wherein determining whether to process the obtained blockchain transaction comprises determining whether to transmit the obtained blockchain transaction to a third party, and wherein: i) a first at least one probabilistic filter encodes the set of whitelisted blockchain transaction identifiers, and wherein the method comprises transmitting the obtained blockchain transaction to the third party on condition that the candidate blockchain transaction identifier is present in the at least one probabilistic filter: or ii) a second at least one probabilistic filter encodes the set of blacklisted blockchain transaction identifiers, and wherein the method comprises transmitting the obtained blockchain transaction to the third party on condition that the candidate blockchain transaction identifier is not present in the at least one probabilistic filter (Falco teaches the NeuroNode analyzing communication between a first device node and one/more other device nodes; see paragraph 123, Falco. The NeuroNode receives updates of whitelisted and blacklisted addresses from the NeuroCloud along with security updates in form of control information in blockchain transactions; see paragraphs 122, 138-140, and 166, Falco. The device node stores at least one command file with at least some of the control information that includes whitelisted and blacklisted IP addresses; see paragraph 51, Falco)
With regards to claim 16, Falco teaches the method wherein the one or more sets of whitelisted data items comprises a set of whitelisted transaction content, and wherein the one or more sets of blacklisted data items comprises a set of blacklisted transaction content, and wherein the candidate data item is a candidate transaction content item of the obtained blockchain transaction (Falco teaches logging IP addresses for analysis and supports identifying blacklisted and whitelisted IP addresses; see paragraphs 122-123 and 152, Falco).
With regards to claim 17, Falco teaches the method wherein determining whether to process the obtained blockchain transaction comprises determining whether to transmit the obtained blockchain transaction to a third party, and wherein: i) a first at least one probabilistic filter encodes the set of whitelisted blockchain transaction content, and wherein the method comprises transmitting the obtained blockchain transaction to the third party on condition that the candidate blockchain transaction content item is present in the at least one probabilistic filter: or ii) a second at least one probabilistic filter encodes the set of blacklisted blockchain transaction content, and wherein the method comprises transmitting the obtained blockchain transaction to the third party on condition that the candidate blockchain transaction content item is not present in the at least one probabilistic filter (Falco teaches the NeuroNode analyzing communication between a first device node and one/more other device nodes; see paragraph 123, Falco. The blockchain transaction has control information with security updates; see paragraph 140, Falco. The control information with security updates contains whitelist and blacklist IP addresses; see paragraphs 122 and 138, Falco. Blacklisted IP addresses are not permitted to be accepted while whitelisted IP addresses are permitted to be accepted; see paragraph 166, Falco. Upon execution, the device controls the communication interface to accept the communication (candidate data) from whitelisted IP addresses and not accept the communications (candidate data) from blacklisted IP addresses; see paragraph 50, Falco. Hence whitelisted IP addresses can be communicated with, such as communication between one or more other device nodes; see paragraph 123, Falco).
With regards to claim 19, Falco teaches the method wherein determining whether to process the obtained blockchain transaction comprises determining whether to accept the obtained blockchain transaction for publishing in a block of the blockchain (Falco supports use of a consensus algorithm to determine the truth for blockchains for updating; see paragraphs 134 and 138, Falco).
With regards to claim 20, Falco teaches the method wherein: i) at least one probabilistic filter encodes the set of whitelisted blockchain transaction content, and wherein the method comprises accepting the obtained blockchain transaction on condition that the candidate blockchain transaction content item is present in the at least one probabilistic filter; or ii) at least one probabilistic filter encodes the set of blacklisted blockchain transaction content, and wherein the method comprises accepting the obtained blockchain transaction to a third party on condition that the candidate blockchain transaction content item is not present in the at least one probabilistic filter (Falco teaches the NeuroNode analyzing communication between a first device node and one/more other device nodes; see paragraph 123, Falco. The blockchain transaction has control information with security updates; see paragraph 140, Falco. The control information with security updates contains whitelist and blacklist IP addresses; see paragraphs 122 and 138, Falco. Blacklisted IP addresses are not permitted to be accepted while whitelisted IP addresses are permitted to be accepted; see paragraph 166, Falco. Upon execution, the device controls the communication interface to accept the communication (candidate data) from whitelisted IP addresses and not accept the communications (candidate data) from blacklisted IP addresses; see paragraph 50, Falco).
With regards to claim 21, Falco teaches the method wherein the set of whitelisted transaction content item comprises a set of whitelisted tokens, and wherein the set of blacklisted transaction content item comprises a set of blacklisted tokens, and wherein the candidate data item is a candidate token (Applicant’s specifications define token as an asset. Falco supports analyzing IP addresses, whitelisted IP addresses and blacklisted IP addresses to be used alongside wallets; see paragraph 152, Falco. The wallet can be for bitcoins; see paragraphs 35-36, Falco).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3-4 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Falco et al (US PGPub No: 2020/0014531) in view of Smith et al (US PGPub No: 2019/0349190), hereafter referred to as Falco and Smith, respectively.
With regards to claim 3, Falco teaches through Smith, the method wherein determining whether to process the obtained blockchain transaction comprises determining whether to sign the obtained blockchain transaction with a digital signature associated with the receiving party
Falco teaches a blockchain with blockchain transactions and validating new blocks on blockchains; see paragraph 83, Falco. However, Falco does not explicitly cite signing the blockchain transaction. In the same field of endeavor, Smith also teaches a blockchain; see abstract and paragraph 83, Smith. In particular, Smith teaches how blockchain transactions can be signed by each device, helping to record/track boot integrity amongst devices; see paragraph 150, Smith. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Smith with those of Falco, to provide trust and improve data integrity; see paragraph 62, Smith.
With regards to claim 4, Falco teaches through Smith, the method wherein: i) at least one probabilistic filter encodes the set of whitelisted blockchain addresses, and wherein the method comprises signing the obtained blockchain transaction on condition that the candidate blockchain address is present in the at least one probabilistic filter; or ii) at least one the probabilistic filter encodes the set of blacklisted blockchain addresses, and wherein the method comprises signing the obtained blockchain transaction on condition that the candidate blockchain address is not present in the at least one probabilistic filter
Falco teaches the blockchain transaction having control information with security updates; see paragraph 140, Falco. The control information with security updates contains whitelist and blacklist IP addresses; see paragraphs 122 and 138, Falco. Blacklisted IP addresses are not permitted to be accepted while whitelisted IP addresses are permitted to be accepted; see paragraph 166, Falco. Upon execution, the device controls the communication interface to accept the communication (candidate data) from whitelisted IP addresses and not accept the communications (candidate data) from blacklisted IP addresses; see paragraph 50, Falco.
However, Falco does not explicitly cite signing the blockchain transaction. In the same field of endeavor, Smith also teaches a blockchain; see abstract and paragraph 83, Smith. In particular, Smith teaches how blockchain transactions can be signed by each device, helping to record/track boot integrity amongst devices; see paragraph 150, Smith. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Smith with those of Falco, to provide trust and improve data integrity; see paragraph 62, Smith.
With regards to claim 11, Falco teaches through Smith, the method wherein determining whether to process the obtained blockchain transaction comprises determining whether to sign the transaction or accept the referenced blockchain transaction for publishing in a block of the blockchain
Falco teaches a blockchain with blockchain transactions and validating new blocks on blockchains; see paragraph 83, Falco. However, Falco does not explicitly cite signing the blockchain transaction. In the same field of endeavor, Smith also teaches a blockchain; see abstract and paragraph 83, Smith. In particular, Smith teaches how blockchain transactions can be signed by each device, helping to record/track boot integrity amongst devices; see paragraph 150, Smith. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Smith with those of Falco, to provide trust and improve data integrity; see paragraph 62, Smith.
With regards to claim 12, Falco teaches through Smith, the method wherein: i) a first at least one probabilistic filter encodes the set of whitelisted unspent transaction outputs, and wherein the method comprises signing or accepting the obtained blockchain transaction on condition that the candidate unspent blockchain transaction is present in the at least one probabilistic filter; or ii) a second at least one probabilistic filter encodes the set of blacklisted unspent transaction outputs, and wherein the method comprises signing or accepting the obtained blockchain transaction on condition that the candidate blockchain unspent transaction output is not present in the at least one probabilistic filter
Falco teaches a blockchain with blockchain transactions and validating new blocks on blockchains; see paragraph 83, Falco. Falco also supports determining the balances (unspent) for the transactions to extract the whitelisted and blacklisted IP addresses; see paragraph 152, Falco. In addition, Falco teaches a blockchain with blockchain transactions and validating new blocks on blockchains; see paragraph 83, Falco. A new block is added (i.e. blockchain is updated) when the blockchain transaction is whitelisted; see paragraphs 50 and 140, Falco. However, Falco does not explicitly cite signing the blockchain transaction. In the same field of endeavor, Smith also teaches a blockchain; see abstract and paragraph 83, Smith. In particular, Smith teaches how blockchain transactions can be signed by each device, helping to record/track boot integrity amongst devices; see paragraph 150, Smith. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Smith with those of Falco, to provide trust and improve data integrity; see paragraph 62, Smith.
Response to Arguments
Applicant's arguments filed November 4, 2025 have been fully considered but they are not persuasive. The following are the examiner’s response to the applicant’s arguments.
The applicant’s first and principal argument concerns the claimed “probabilistic filter”. Applicant contends that Falco fails to teach a probabilistic filter and thereby also does not teach the probabilistic filter encoding sets of whitelisted/blacklisted data items. The examiner respectfully disagrees.
Falco teaches a NeuroNode/lightweight software operating within each device node; see paragraph 120 and Figure 3B, Falco. The NeuroNode receives updates (gets encoded) of whitelisted and blacklisted addresses from the NeuroCloud along with security updates in form of control information in blockchain transactions; see paragraphs 122, 138-140, and 166, Falco. The NeuroCloud (whose whitelist/blacklist filter information is within the control information) can run Naïve Bayes (see paragraph 138, Falco) which is a probabilistic filter; see Wikipedia (https://en.wikipedia.org/wiki/Naive_Bayes_classifier). So, the whitelisted/blacklisted data is received from the NeuroCloud which uses the probabilistic filter, Naïve Bayes. Control information contains this probabilistic filter information.
So there is clearly support for the use of probabilistic filters, in the form of Naïve Bayes, which is used in the NeuroCloud, which has the whitelisted/blacklisted content.
And second, the NeuroNode receives updates (gets encoded) with whitelisted and blacklisted addresses in the form of control information from the NeuroCloud (which has the Naïve Bayes probabilistic filter). As such, applicant’s arguments pertaining to probabilistic filters and encoding are not deemed persuasive.
Applicant next argues that Falco fails to teach “determining whether to process the obtained blockchain transaction based on whether the candidate data item is present in at least one of the one or more probabilistic filters”, since Falco does not allegedly teach a probabilistic filter encoding sets of whitelisted/blacklisted data items. Again, the examiner respectfully disagrees.
As explained above, the NeuroNode receives updates (gets encoded) with whitelisted and blacklisted addresses in the form of control information from the NeuroCloud (which has the Naïve Bayes probabilistic filter). As such, applicant’s arguments pertaining to probabilistic filters and encoding are not deemed persuasive. Falco further teaches blacklisted IP addresses not being permitted to be accepted while whitelisted IP addresses are permitted to be accepted; see paragraph 166, Falco. Upon execution, the device controls the communication interface to accept the communication (candidate data) from whitelisted IP addresses and not accept the communications (candidate data) from blacklisted IP addresses; see paragraph 50, Falco. So, it is clear that determinations are made based on blacklists/whitelists, the blacklists/whitelists being attained from the NeuroCloud with the Naïve Bayes (probabilistic filter). As such, this argument is also not deemed persuasive.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AZIZUL Q CHOUDHURY whose telephone number is (571)272-3909. The examiner can normally be reached M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, EMMANUEL MOISE can be reached at (571) 272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AZIZUL CHOUDHURY/Primary Examiner, Art Unit 2455