DETAILED ACTION
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 .
1.This is a Final Office Action in response to applicant’s amendment filed September 11, 2025. At this time, claims 1, 3, 5-7, 9, 11 and 13-15 have been amended. No claim has been added or cancelled. Therefore, claims 1-16 are pending and addressed below.
Response to Amendments
As to Claims 1-16, Applicants’ amendment of independent Claims 1 and 9 with newly added features [Claims 1-16] has necessitated a new ground(s) of rejection in this Office action. Therefore, Applicants’ arguments filed on 09/11/2025 have been fully considered but are moot in view of the new ground(s) of rejection because the arguments do not apply to any of the updated reference(s) being used in the current rejection.
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 1, 3-4, 6-16 are rejected under 35 U.S.C 103 as being unpatentable over Sethia, US pat. No US 20240386106 A1 in view of Yadav-Ranjan, US pat. No 20240039938.
1. Sethia discloses a computer-implemented method for automatically preventing harm caused from malware, (See Sethia, abstract; Aspects of this disclosure relate to systems and methods to determine whether an application is misconfigured or malicious using smart contracts stored on a distributed ledger and a transferred deep learning system.) the computer-implemented method comprising: providing, by at least one computing device configured by executing instructions, a blockchain framework for blockchain nodes to interface over a cybersecurity platform; (See Sethia [0051-0052] Each of full node computing devices 210A-210F may operate in concert to create and maintain decentralized P2P network 270 of decentralized P2P computer system 200. In creating decentralized P2P network 270 of decentralized P2P computer system 200, processors, ASIC devices, and/or graphics processing units (e.g., GPUs) of each full node computing device 210A-210F may execute network protocols which may cause each full node computing device 210A-210F to form a communicative arrangement with the other full node computing devices 210A-210F in decentralized P2P computer system 200 and thereby create decentralized P2P network 270. [0108] Every time the application 535 initiates or launches an application session on the user computing device 510, a smart contract is generated, assigned rules, and bound with the configuration data 538 to monitor or authenticate the application session to prevent any misconfigured data or potentially malicious code in the configuration data from executing. The smart contract protects against malicious attacks at the application level that may cause personal user data and/or an enterprise organization's enterprise data 580 from being compromised. )
configuring, by the at least one computing device using the blockchain framework, a first blockchain node with malware detection; (See Sethia, [0105] and fig 5; The user computing device 510 may comprise a user memory 520 and one or more user processor(s) 545. The user memory 520 may store a monitoring module 525, a deep learning module 530, an application 535, configuration data 538, user data 540, a distributed ledger 542, and/or computer readable instructions, that when executed by the user processor(s) 545, perform one or more functions and/or operations described herein. The application 535 may comprise configuration data 538 associated with the application. In some embodiments, the configuration data 538 associated with the application 535 comprises one or more data associated with the application's settings, such as the version of the application, the security protocol (HTTPS or the like) used by the application, the operating system required to use the application, and/or dates of updates to the version of the application. In some embodiments, the configuration data comprises one or more data of hash keys obtained from hashing executable files of the application 535, encryption keys obtained from encrypting files and data associated with the application 535, and/or an application session identification data (ID) generated for each application session. The user computing device may comprise a smart phone, tablet, smart watch, and/or a laptop and the like. See also [0108-0109]; The smart contract protects against malicious attacks at the application level that may cause personal user data and/or an enterprise organization's enterprise data 580 from being compromised.)
configuring, by the at least one computing device using the blockchain framework, each of a plurality of other blockchain nodes with at least one smart contract, (See Sethia, [0109] and fig 5; [0110] In some embodiments, after the smart contract is generated and assigned the first, second and third rules, the monitoring module 525 may extract the configuration data 538 and bind the configuration data 538 with the smart contract. Then, the smart contract is added to the distributed ledger 542 for monitoring the application session. The smart contract denies or grants the application session permission to access user data 540 based on the rules assigned to the smart contract. The smart contract protects against malicious attacks or requests by the malicious device 560 attempting to tamper with misconfigurations in the configuration data 538 associated with the application 535. )
wherein the first blockchain node and the each of the plurality of other blockchain nodes are configured, as a function of the blockchain framework, (See Sethia, [0053]; [0053] Lightweight node computing devices 250A and 250B may request execution of network functions related to decentralized P2P network 270. In order to request execution of network functions, such as balance sheet transaction and/or smart contract operations, processors of lightweight node computing devices 250A and 250B may execute network commands to broadcast the network functions to decentralized P2P network 270 comprising full node computing devices 210A-210F. [0109] In some embodiments, the monitoring module 525 generates a smart contract for monitoring an application session based on dynamic rules or logic that may be determined from a rules engine and/or the deep learning module 530. Each time an application session associated with the application 535 is initiated, the monitoring module 525 generates a smart contract, assigns rules to the smart contract, and binds the configuration data 538 with the smart contract. The rules may include a first rule for the smart contract related to denying permission to the application session when the application session attempts to execute by bypassing the smart contract, a second rule for the smart contract related to denying permission to the application session when unknown data not associated with the application 535 is detected in the configuration data 538 associated with the application 535, and a third rule for the smart contract related to shutting down the application session when a malicious indication is detected in the configuration data 538. ) to perform the following steps:
automatically transmit, by each of the plurality of other blockchain nodes running at least one smart contract, a request to each of the other of the plurality of other blockchain nodes
for data associated with a new file or an update to an existing file;(See Sethia, [0047] Each of the user computing devices 120 may be configured to interact with server infrastructure 110 through network 130. In some instances, one or more of the user computing devices 120 may be configured to receive and transmit information corresponding to system requests through particular channels and/or representations of webpages and/or applications associated with server infrastructure 110. The system requests provided by user computing devices 120 may initiate the performance of particular computational functions such as data and/or file transfers at server infrastructure 110. In such instances, the one or more of the user computing devices may be internal computing devices associated with the particular entity corresponding to server infrastructure 110 and/or may be external computing devices which are not associated with the particular entity. [0065])
automatically receive, by each of the plurality of other blockchain nodes running at least one smart
contract, the requested data; (See Sethia, [0047] Each of the user computing devices 120 may be configured to interact with server infrastructure 110 through network 130. In some instances, one or more of the user computing devices 120 may be configured to receive and transmit information corresponding to system requests through particular channels and/or representations of webpages and/or applications associated with server infrastructure 110. The system requests provided by user computing devices 120 may initiate the performance of particular computational functions such as data and/or file transfers at server infrastructure 110. In such instances, the one or more of the user computing devices may be internal computing devices associated with the particular entity corresponding to server infrastructure 110 and/or may be external computing devices which are not associated with the particular entity. [0065] )
automatically transmit, by each of the plurality of other blockchain nodes
running at least one smart contract, the requested data; (See Sethia, [0047] Each of the user computing devices 120 may be configured to interact with server infrastructure 110 through network 130. In some instances, one or more of the user computing devices 120 may be configured to receive and transmit information corresponding to system requests through particular channels and/or representations of webpages and/or applications associated with server infrastructure 110. The system requests provided by user computing devices 120 may initiate the performance of particular computational functions such as data and/or file transfers at server infrastructure 110. In such instances, the one or more of the user computing devices may be internal computing devices associated with the particular entity corresponding to server infrastructure 110 and/or may be external computing devices which are not associated with the particular entity. [0065] )
receive, by the first blockchain node, from the plurality of other blockchain nodes, the requested data; (See Sethia, [0047] Each of the user computing devices 120 may be configured to interact with server infrastructure 110 through network 130. In some instances, one or more of the user computing devices 120 may be configured to receive and transmit information corresponding to system requests through particular channels and/or representations of webpages and/or applications associated with server infrastructure 110. The system requests provided by user computing devices 120 may initiate the performance of particular computational functions such as data and/or file transfers at server infrastructure 110. In such instances, the one or more of the user computing devices may be internal computing devices associated with the particular entity corresponding to server infrastructure 110 and/or may be external computing devices which are not associated with the particular entity.)
and mitigate, by at least one of the plurality of other blockchain nodes running at least
one smart contract, the threat caused by the malware. (See Sethia, [0109] In some embodiments, the monitoring module 525 generates a smart contract for monitoring an application session based on dynamic rules or logic that may be determined from a rules engine and/or the deep learning module 530. Each time an application session associated with the application 535 is initiated, the monitoring module 525 generates a smart contract, assigns rules to the smart contract, and binds the configuration data 538 with the smart contract. The rules may include a first rule for the smart contract related to denying permission to the application session when the application session attempts to execute by bypassing the smart contract, a second rule for the smart contract related to denying permission to the application session when unknown data not associated with the application 535 is detected in the configuration data 538 associated with the application 535, and a third rule for the smart contract related to shutting down the application session when a malicious indication is detected in the configuration data 538. In some examples, the malicious indication is determined by processing the configuration data 538 by the deep learning module 530, which outputs the malicious indication.) Sethia does not appear to explicitly disclose process, by the first blockchain node using the malware detection, the requested data to automatically determine, at least some of the requested data represents the new file or the update to the existing file is malware or infected with malware; automatically transmit, by the first blockchain node in response to detecting the malware or infection with malware, an instruction for the plurality of other blockchain nodes to mitigate any threat caused by the malware; However, Yadav-Ranjan discloses process, by the first blockchain node using the malware detection, the requested data to automatically determine, at least some of the requested data represents the new file or the update to the existing file is malware or infected with malware; (See Yadav-Ranjan, [0083] Applied to control plane nodes, blockchain smart contracts can observe and alert anomalous UE detach, reconnect, paging, location update, and re-establish behaviors that indicate control plane DDoS attacks. Applied to user-plane nodes, blockchain smart contracts can observe and alert anomalous packet flow volume and activity patterns that indicate user plane IoT DDOS attacks. When combined from multiple nodes serving the same devices, blockchain smart contract reports can be observed for temporal and spatial patterns that can point to the presence, origin, and destination of DDoS attacks. Application of blockchain records and smart contract-induced updates to IoT DDoS use cases provides an effective distributed data source for DDoS anomaly detection, countermeasure, and mitigation functions. Blockchain-based solutions are better suited to IoT networks than classical probing, packet inspection, and data caching techniques because the raw data and rule computations are handled at the distributed nodes. [0047]; When applied to the IoT DDoS use case, blockchain records and smart-contract-initiated updates can be used to track device behavior and network impacts, and therefore provide an efficient data source for DDoS anomaly detection, countermeasure and mitigation functions. Compared to traditional probing, packet inspection, and data caching techniques, this blockchain approach is better suited for the privacy, scale, and speed of IoT networks. If a particular IoT device is identified as a source of a DDoS attack, then that device name, location or other identifier can be stored on the blockchain, creating a permanent (or nearly permanent, depending on the blockchain technology used) record. All devices on the blockchain may then know which device(s) can be the target of countermeasures.)
automatically transmit, by the first blockchain node in response to detecting the malware or infection with malware, an instruction for the plurality of other blockchain nodes to mitigate any threat caused by the malware; (See Yadav-Ranjan, [0046]; Additional remedial actions, including automated over-the-air software updates, may be used to further identify, repair, impair or completely disable DDoS devices. Finally, proactive actions must be taken to prevent DDoS UE from impacting additional networks after detection. These countermeasures and remedial actions may be designed to mimic normal or DDoS-impaired conditions that are difficult for IoT devices to detect or counter. [0064]; mitigation and remediation procedures may be targeted at specific locations and cell sites. This type of targeted strategy may be supported by location fingerprinting of DDoS UE, and the possibility of “swarms” of DDoS UE. An example of this type of localization is to use timing advance (TA) information for DDoS location fingerprinting, as illustrated in FIG. 5. While active, all cellular UEs adjust their uplink transmit burst timing to align with the frame structure of the serving cell site receiver. As each UE moves further away, uplink transmit bursts take longer to reach the cell site. When the reception is delayed beyond a threshold, the cell site commands the UE to increase the timing advance value, thus sending uplink bursts sooner to overcome the additional delay)
Sethia and Yadav-Ranjan are analogous art because they are from the same field of endeavor which is blockchain node intrusion detection. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sethia with the teaching of Yadav-Ranjan to include the newly created file because it would have allowed systems for identifying and responding to DDoS attacks in a communication system, such as an IoT network. (See Yadav-Ranjan, [0004] )
2. The combination of Sethia and Yadav-Ranjan does not appear to explicitly disclose the computer-implemented method of claim 1, wherein the step of determining the data represents the new file or the update to the existing file is malware or infected with malware includes heuristics, machine learning, and artificial intelligence. (See Yadav-Ranjan, [0006]; machine learning, reinforcement learning, actor critic learning, supervised learning, unsupervised learning.) Sethia and Yadav-Ranjan are analogous art because they are from the same field of endeavor which is blockchain node intrusion detection. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sethia with the teaching of Yadav-Ranjan to include the newly created file because it would have allowed systems for identifying and responding to DDoS attacks in a communication system, such as an IoT network. (See Yadav-Ranjan, [0004] )
3. The combination of Sethia and Yadav-Ranjan discloses the computer-implemented method of claim 1, further comprising: providing, on at least the first blockchain node, a graphical user interface. (See Sethia, fig 2 and [0129]; GUI)
4, The combination of Sethia and Yadav-Ranjan discloses the computer-implemented method of claim 1, wherein the malware includes at least one of ransomware, spyware, a trojan, a worm, and virus. (See Sethia, [0109] The unknown data may be malware data or virus data that execute malicious)
6. The combination of Sethia and Yadav-Ranjan discloses the computer-implemented method of claim 1, wherein the data associated with a new file or an update to an existing file includes a file hash. (See Sethia, [0123])
7. The combination of Sethia and Yadav-Ranjan discloses the computer-implemented method of claim 1, further comprising: configuring, by the at least one computing device, the first blockchain node
to notify each of the plurality of other blockchain nodes that the new file or the update to the existing file is malware or infected with malware. (See Yadav-Ranjan, [0051] and [0083]) Sethia and Yadav-Ranjan are analogous art because they are from the same field of endeavor which is blockchain node intrusion detection. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sethia with the teaching of Yadav-Ranjan to include the newly created file because it would have allowed systems for identifying and responding to DDoS attacks in a communication system, such as an IoT network. (See Yadav-Ranjan, [0004] )
8. The combination of Sethia and Yadav-Ranjan discloses the computer-implemented method of claim 1, wherein the threat is mitigated by quarantining the new file or the existing file. (See Yadav-Ranjan, [0066]) Sethia and Yadav-Ranjan are analogous art because they are from the same field of endeavor which is blockchain node intrusion detection. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sethia with the teaching of Yadav-Ranjan to include the newly created file because it would have allowed systems for identifying and responding to DDoS attacks in a communication system, such as an IoT network. (See Yadav-Ranjan, [0004] )
9. As to claim 9, the claim is rejected under the same rationale as claim 1. See the rejection of claim 1 above.
10. As to claim 10, the claim is rejected under the same rationale as claim 2. See the rejection of claim 2 above.
11. As to claim 11, the claim is rejected under the same rationale as claim 3. See the rejection of claim 3 above.
12. As to claim 12, the claim is rejected under the same rationale as claim 4. See the rejection of claim 4 above.
14. As to claim 14, the claim is rejected under the same rationale as claim 6. See the rejection of claim 6 above.
15. As to claim 15, the claim is rejected under the same rationale as claim 7. See the rejection of claim 7 above.
16. As to claim 16, the claim is rejected under the same rationale as claim 8. See the rejection of claim 8 above.
Claims 5, 13 are rejected under 35 U.S.C 103 as being unpatentable over Sethia, US pat. No US 20240386106 A1 in view of Yadav-Ranjan, US pat. No 20240039938 in further view of O’Grady, US 20210304191 A1.
5. The combination of Sethia and Yadav-Ranjan does not appear to explicitly disclose the computer-implemented method of claim 1, further comprising: configuring, by the at least one computing device using the blockchain framework, thefirst blockchain node as an application programming interface (“API”) server; and configuring, by the at
least one computing device using the blockchain framework, each of the other of the plurality of other
blockchain nodes as an API client, wherein the requested data associated with a new file or an update to an existing file is provided via an API call. However, O’Grady discloses configuring, by the at least one computing device using the blockchain framework, thefirst blockchain node as an application programming interface (“API”) server; (See O’Grady, [0023-0027]; the standard API format can enable information to be written to multiple blockchains using a standard request format. The subject technology can connect multiple third parties to the multiple blockchains via a single API server, multiple API server instances (e.g., one per blockchain, one per blockchain node), different API server, and/or any suitable number of API servers.) and configuring, by the at
least one computing device using the blockchain framework, each of the other of the plurality of other
blockchain nodes as an API client, wherein the requested data associated with a new file or an update to an existing file is provided via an API call. (See O’Grady, [0024]-0027], [0029] In an example, the subject system can include one or more API servers (e.g., node API server 111) that function to communicate with one or more API clients (e.g., node API client 140). API clients can be included in a blockchain protocol (e.g., in blockchain node 121), provided as a stand-alone module (e.g., node API client 140), integrated within the blockchain application module (e.g., used by the blockchain application module 160), and/or otherwise integrated with each supported blockchain.)
Sethia, Yadav-Ranjan and O'Grady are analogous art because they are from the same field of endeavor which is blockchain node. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Sethia and Yadav-Ranjan with the teaching of O’Grady to include the newly created file because it would have allowed blockchain network to communicate through API.
13. As to claim 13, the claim is rejected under the same rationale as claim 5. See the rejection of claim 5 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Katragadda, US pat. No 20190379699, title “ SYSTEMS AND METHODS FOR BLOCKCHAIN SECURITY DATA INTELLIGENCE “.
Alsharif, US pat. No 20210211451, title “METHOD AND SYSTEM FOR BLOCKCHAIN ACCREDITATION MECHANISM BASED ON CYBERSECURITY RISK”.
Stott; Christopher J, pat. No 20210256113, title “Blockchain Validation Of Software
Patent Number “.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 JOSNEL JEUDY whose telephone number is (571)270-7476. The examiner can normally be reached M-F 10:00-8:00.
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, Arani T Taghi can be reached at (571)272-3787. 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.
Date: 11/10/2025
/JOSNEL JEUDY/ Primary Examiner, Art Unit 2438