DETAILED ACTION
Claims 1-20 are pending. This is in response to the application filed on June 30, 2023.
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 .
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4, 6-9, 11-13 and 15-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pub 20200372154 (hereinafter Bacher)
Regarding claim 1, Bacher discloses an apparatus for a node of a blockchain network, the apparatus comprising interface circuitry, machine-readable instructions and processor circuitry to execute the machine-readable instructions to:
compare a traffic pattern of requests associated with one or more smart contracts hosted by the node of the blockchain network with a reference traffic pattern (Fig. 8 and par. [0005], [0032], [0163]-[0193] discloses a system comprising of a peer-to-peer network of security nodes, having pre-trained detection models and rules, to monitor blockchains and connected devices for security vulnerabilities including DDos attack, where the pre-trained detection models and rules including cybersecurity artifacts such as security vulnerabilities in smart contracts and digital assets, malware in smart contracts, digital assets, end user, computers, good/malicious smart contract patterns, good/malicious network attack traffic patterns, etc.);
determine an estimated denial of service of at least one of the one or more smart contracts based on the comparison between the traffic pattern and the reference traffic pattern (Fig. 8 - steps 850-870 discloses using the pre-trained detection models and rules to detect against good/malicious network attack traffic patterns. NOT eth at par. [0179]-[0192] discloses using risk score as the basis to determine for malicious behavior);
determine one or more potential mitigations for the estimated denial of service; and apply at least one of the one or more potential mitigations (par. [0194] discloses choices of mitigations).
Regarding claim 2, Bacher discloses wherein the processor circuitry is to execute the machine-readable instructions to determine the one or more potential mitigations based on a collection of mitigations collectively maintained by the nodes of the blockchain network (Security nodes are on the blockchain network).
Regarding claim 4, Bacher discloses wherein the reference traffic pattern is a reference traffic pattern that is determined locally at the node (par. [0183]-[0184] discloses the security nodes having the self-learning to generate the pre-trained detection models and rules).
Regarding claim 6, Bacher discloses wherein the reference traffic pattern is a reference traffic pattern that is collectively maintained by the nodes of the blockchain network (see claim 4 reasoning).
Regarding claim 7, Bacher discloses wherein the comparison between the traffic pattern and the reference traffic pattern is performed using a traffic pattern evaluation mechanism (par. [0115] [0120] discloses the pre-trained detection models using machine learning algorithms to train data for detection).
Regarding claim 8, Bacher discloses wherein the traffic pattern evaluation mechanism is collectively maintained by the nodes of the blockchain network (as presented in claim 4 rejection, the security nodes have the self-learning to generate the pre-trained detection models and rules as well as self-improving over time without requiring user input (par. [0143]).
Regarding claim 9, Bacher discloses wherein the processor circuitry is to execute the machine-readable instructions to adjust the traffic pattern evaluation mechanism over time based on a plurality comparisons between the traffic pattern and the reference traffic pattern at a plurality of points of time (see claims 4 and 8 rejections. Also see par. [0086]: “The SN full node 102 sends frequent updates, e.g., hourly, daily, etc., on all incoming network traffic for further training…”).
Regarding claims 11-12, Bacher discloses wherein a selection of the one or more potential mitigations is performed using a mitigation selection mechanism, wherein the mitigation selection mechanism is collectively maintained by the nodes of the blockchain network (par. [0194] discloses a listing of mitigation choices for malicious and good behaviors. Par. [0112]).
Regarding claim 13, Bacher discloses wherein the processor circuitry is to execute the machine-readable instructions to determine an efficacy of the at least one applied mitigation, and to adjust the mitigation selection mechanism over time based on the determined efficacy (par. [0112] and [0194] discloses the master security node issues a reward granted to at least one or more security nodes for performing a cybersecurity defense for the monitored connected devices correctly with no false security vulnerability report. Par. [0084], [0090]-[0092] discloses The security node called full node also provides a latest version of self-learned cybersecurity knowledge base to the security node called light nodes whom receive the reward. This suggests a security node providing the correct detection and mitigation will get a reward along with the latest cybersecurity knowledge which will improve the detection and protection of blockchain nodes over time).
Regarding claim 15, Bacher discloses wherein at least one of a collective maintenance of a collection of mitigations, a collective maintenance of a traffic pattern evaluation mechanism and a collective maintenance of a mitigation selection mechanism is based on a reputation-based mechanism that is based on a reputation of the nodes of the blockchain network (par. [0106] discloses a risk score assigned to a SN light node to designate the node is trustworthy or not).
Regarding claim 16, Bacher discloses wherein the processor circuitry is to execute the machine-readable instructions to determine an efficacy of the at least one applied mitigation, and to provide information on the efficacy of the at least one potential mitigation to at least one other node of the blockchain network (see claim 13 rejection for the SN full node providing a latest version of self-learned cybersecurity knowledge base to the SN light nodes whom receive the reward after the SN light nodes are assessed to protect correction detection and mitigation).
Regarding claim 17, Bacher discloses wherein the processor circuitry is to execute the machine-readable instructions to identify a potential vulnerability associated with the estimated denial of service, and to provide information on the potential vulnerability to at least one other node of the blockchain network (see claim 16 rejection for same reasoning).
Regarding claim 18, Bacher discloses wherein the processor circuitry is to execute the machine-readable instructions to provide information on the estimated denial of service to at least one other node of the blockchain network (see claim 16 rejection for same reasoning).
Claims 19-20 are rejected in view of claim 1 rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Bacher in view of NPL 2020 - detecting DDoS attacks in smart contract-based Blockchain-IoT Systems (hereinafter Kumar)
Regarding claim 3, Bacher does not expressly disclose wherein the traffic pattern relates to at least one of incoming requests and outgoing requests. Kumar discloses detecting DDos attack based on illegitimate requests (Section 2.8). Therefore, it would have been obvious before the effective filing date of the claim invention to modify Bacher with Kumar to further teach the aforementioned feature. One would have done so as an obvious variation of detecting malicious traffic pattern to arrive at the claimed feature with reasonable expectation of success.
Regarding claim 5, the combination of Bacher and Kumar teaches wherein the processor circuitry is to execute the machine-readable instructions to monitor requests associated with the one or more smart contracts, and to determine the reference traffic pattern based on the monitored requests (Bacher detects malicious traffic pattern and Kumar teaches detecting illegitimate requests).
Claims 10 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Bacher in view of NPL 2022 - Intrusion Detection System for IoMT through Blockchain-based Federated Learning (hereinafter Bessem)
Regarding claim 10, Bacher discloses using various machine learning to pre-train detection models but not using the federated learning. Bessem discloses using the federated learning architect for intrusion detection in blockchain including detecting denial of service (2nd page). Therefore, it would have been obvious before the effective filing date of the claim invention to modify Bacher with Bessem to further teach wherein the processor circuitry is to execute the machine-readable instructions to adjust the traffic pattern evaluation mechanism by training a machine-learning model used by the traffic pattern evaluation mechanism, and to propagate the training of the machine-learning model to one or more further nodes of the blockchain network using federated learning. One would have done so as an obvious variation of detecting using various machine learning algorithm to arrive at the claimed feature with reasonable expectation of success.
Regarding claim 14, the combination of Bacher and Bessem discloses wherein the processor circuitry is to execute the machine-readable instructions to adjust the mitigation selection mechanism by training a machine-learning model used by the mitigation selection mechanism, and to propagate the training of the machine-learning model to one or more further nodes of the blockchain network using federated learning (see claim 13 rejection for the self-learned knowledge passed to other node that received the reward. And Bessem using federated learning which can be substitute to Bacher’s other machine learning algorithm).
Inquiry communication
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRI M TRAN whose telephone number is (571)270-1994. The examiner can normally be reached Mon-Fri: 9am-5pm.
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, Jeffrey Nickerson can be reached at (469)295-9235. 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.
/TRI M TRAN/Primary Examiner, Art Unit 2432
Prosecution Insights