Prosecution Insights
Last updated: October 25, 2026
Application No. 18/809,169

Integrity and Privacy-Preserving Federated Learning in a Smart Factory Using Smart Contracts and Merkle Tree-Based Key Management

Non-Final OA §101§102
Filed
Aug 19, 2024
Priority
Aug 17, 2023 — provisional 63/520,155
Examiner
CAREY, FORREST L
Art Unit
2491
Tech Center
2400 — Computer Networks
Assignee
University of South Florida
OA Round
1 (Non-Final)
57%
Grant Probability
Moderate
1-2
OA Rounds
1y 5m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 57% of resolved cases
57%
Career Allowance Rate
154 granted / 272 resolved
-1.4% vs TC avg
Strong +55% interview lift
Without
With
+55.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 8m
Avg Prosecution
13 currently pending
Career history
304
Total Applications
across all art units

Statute-Specific Performance

§101
9.7%
-30.3% vs TC avg
§103
59.5%
+19.5% vs TC avg
§102
15.1%
-24.9% vs TC avg
§112
12.3%
-27.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 272 resolved cases

Office Action

§101 §102
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 . Status of Claims Claims 1-20 are pending; of which claims 2, 4-6 are withdrawn from consideration. Election/Restrictions Applicant's election with traverse of Group II, Claims 1, 3, 7-20 in the reply filed on 7/7/2026 is acknowledged. Applicant makes no apparent arguments regarding grounds for traversal; therefore, the election is being treated as without traverse. The requirement is still deemed proper and is therefore made FINAL. Information Disclosure Statement The information disclosure statement (IDS) submitted on 12/22/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Allowable Subject Matter Claim 3 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, in addition to correcting any outstanding 35 USC 101 or 112 issues. The following is a statement of reasons for the indication of allowable subject matter: None of the prior art of record, individually or in combination, teaches each and every limitation of claim 3, especially the limitations of “transmit[ting], via the blockchain module, as new block of a blockchain, the encrypted message and the complete key hash, wherein the blockchain is distributed to the plurality of robots or associated edge nodes; and transmit[ting] (i) the Merkle tree, (ii) a partial key hash of the plurality of partial key hashes, and (iii) a partial key of the plurality of partial keys to each respective node of the plurality of robots or associated edge nodes, wherein each respective node of the plurality of robots or associated edge nodes is configured to (i) receive the transmitted partial key hash as a first local partial key hash and received the partial key, (ii) transmit the first local partial key hash and received partial key to a paired node among the plurality of robots or associated edge nodes, (ii) receive, at least, a second local partial key hash corresponding to the paired node from the paired node and a corresponding partial key of the second local partial key hash, (iii) construct a local complete key hash from the first local partial key hash and, at least, the second local partial key hash, (iv) validate the new block in the blockchain via a smart contract operation of the blockchain if the constructed key hash matches the complete key hash in the new block, and (v) decrypt the control or communication data from the encrypted message using a key generated from (i) the Merkle tree, (ii) the received partial key of the first local partial key hash and, at least, (iii) the received partial key of the second local partial key hash. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1, 3, 7-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) “executing control software for a… autonomous multi-robot system… comprising: a blockchain module comprising smart contracts” (executing a software module - well-understood, routine, conventional computer activity) and “a Merkle tree-based key management module… wherein the key management ensures information exchange in the system is encrypted…” (mental process – evaluation and judgement). This judicial exception is not integrated into a practical application because claims 1, 19, and 20 fail to recite any further language that integrates the above steps into a process that applies, relies on, or uses the abstract idea in a manner that imposes a meaningful limit on the abstract idea. There are no additional limitations that reflect an improvement to the functioning of a computer, or an improvement to another technology or technical field. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because claims 1, 19, and 20 recite generic computer components (e.g., processor, memory, software) performing well-understood, routine, and conventional functions, such as executing software. While the executed software “ensures information exchange”, this amounts to no more that execution of the abstract idea on a computer. The dependent claims fail to recite any further limitations that would either integrate the above identified abstract idea into a practical application or recite anything which would constitute significantly more than the abstract idea itself. Therefore, these claims are also rejected for the same reasons as claims 1, 19, and 20, above. 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. Claim(s) 1, 19-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Paffrath (PGPUB 2025/0076834). Regarding Claim 1: Paffrath teaches a non-transitory computer readable medium having instructions stored thereon, wherein execution of the instructions by a processor of an equipment of a decentralized ([0015] in association with embodiments of the invention, a “module” can be understood to mean for example a processor and/or a storage unit for storing program instructions; by way of example, the processor is specifically designed to execute the program instructions in such a way that the processor executes functions, for implementing or realizing the method according to embodiments of the invention or a step of the method according to embodiments of the invention), autonomous multi-robot system comprising a plurality of robots and edge nodes causes the processor to ([0056] device is for example a manufacturing device and/or an electromechanical device and/or an electronic device and/or a device of an automation network (e.g. for industrial technological installations, manufacturing installations, energy or resource distribution installations)): execute control software for a decentralized ([0036] embodiments of the invention, a “network application” can be understood to mean for example a decentralized distributed database, a distributed database system, a distributed database, a peer-to-peer application, a distributed memory management system, a blockchain, a distributed ledger), autonomous multi-robot system for on-demand production ([0056] device is for example a manufacturing device and/or an electromechanical device and/or an electronic device and/or a device of an automation network (e.g. for industrial technological installations, manufacturing installations, energy or resource distribution installations); [0221] ecosystem of devices which interact with one another autonomously by means of a blockchain or network application; in particular, security-protected data processing of sensor data or measurement data for an object is realized by means of embodiments of the invention with a distributed infrastructure (e.g. the network application); fields of application here are supply chain scenarios or industrial control applications of blockchains; [0188] by means of the control functions, it is possible to control parts of a technical installation (e.g. a manufacturing installation) for the object O; this can be the control of a conveyor belt, for example, in order that the object O (e.g. a melting furnace) is supplied with material for melting or the object O (e.g. a manufacturing robot) is supplied with the next part to be manufactured), the system having adaptive and resilience productivity and resource efficiency ([0056] device is for example a manufacturing device and/or an electromechanical device and/or an electronic device and/or a device of an automation network (e.g. for industrial technological installations, manufacturing installations, energy or resource distribution installations)), each system comprising: a blockchain module comprising smart contracts as a unified automation framework ([0189] corresponding control functions can be realized for example as a smart contract of the network application); and a Merkle tree-based key management module for privacy preservation ([0020] a “checksum”, for example a data block checksum, a data checksum, a node checksum, a transaction checksum, a linking checksum or the like, can be understood to mean for example a cryptographic checksum or cryptographic hash or hash value that is formed or calculated in particular by means of a cryptographic hash function by way of a data set and/or data and/or one or more of the transactions and/or a partial area of a data block (e.g. the block header of a block of a blockchain or data block header of a data block of the distributed database system (or of the network application) or only a portion of the transactions of a data block); a checksum can be in particular (a) checksum(s) or hash value(s) of a hash tree (e.g. Merkle tree, Patricia tree); furthermore, it can also be understood to mean in particular a digital signature or a cryptographic message authentication code; [0095]-[0102] the network application or the distributed database system is for example a blockchain, where the device is embodied for example as a node or an oracle of the distributed database system or of the network application, the cryptographic checksum is for example a digital signature; the device comprises a calculation module (120), for example, wherein the calculation module (120) is designed for example for calculating an object-specific characteristic on the basis of the individual features, the characteristic is calculated for example taking account of predefined tolerance values of the individual features, for example the characteristic and/or the individual features are/is compared with the corresponding reference value, for example in the case of a sufficiently accurate match between the reference value and the characteristic and/or the individual features, the first cryptographic key is released by the cryptography module), wherein the key management ensures information exchange in the system is encrypted prior to data exchange and decryption requiring the joint effort of recipients ([0060] the data of the executability confirmation transaction may also have been exchanged between the transmitter and the receiver before the executability confirmation transaction is stored e.g. in the distributed database system; the executability confirmation transaction can for example also be cryptographically protected (e.g. it can be encrypted or be protected by a transaction checksum); [0201] data structure and the cryptographic checksum are stored in a data set, for example, wherein the data set is stored for example as a transaction in the distributed database system or the network application; for this purpose, the transaction can comprise an additional checksum (e.g. a transaction checksum), which was generated e.g. by means of a cryptographic key (e.g. a private cryptographic key) that is assigned to an entity or is used by the latter). Regarding Claim 19: Paffrath teaches a system comprising: a processor ([0015] in association with embodiments of the invention, a “module” can be understood to mean for example a processor and/or a storage unit for storing program instructions; by way of example, the processor is specifically designed to execute the program instructions in such a way that the processor executes functions, for implementing or realizing the method according to embodiments of the invention or a step of the method according to embodiments of the invention); and a memory having instructions stored thereon, wherein execution of the instructions causes the processor to ([0015] as above): execute control software for a decentralized ([0036] embodiments of the invention, a “network application” can be understood to mean for example a decentralized distributed database, a distributed database system, a distributed database, a peer-to-peer application, a distributed memory management system, a blockchain, a distributed ledger), autonomous multi-robot system for on-demand production ([0056] device is for example a manufacturing device and/or an electromechanical device and/or an electronic device and/or a device of an automation network (e.g. for industrial technological installations, manufacturing installations, energy or resource distribution installations); [0221] ecosystem of devices which interact with one another autonomously by means of a blockchain or network application; in particular, security-protected data processing of sensor data or measurement data for an object is realized by means of embodiments of the invention with a distributed infrastructure (e.g. the network application); fields of application here are supply chain scenarios or industrial control applications of blockchains; [0188] by means of the control functions, it is possible to control parts of a technical installation (e.g. a manufacturing installation) for the object O; this can be the control of a conveyor belt, for example, in order that the object O (e.g. a melting furnace) is supplied with material for melting or the object O (e.g. a manufacturing robot) is supplied with the next part to be manufactured), the system having adaptive and resilience productivity and resource efficiency ([0056] device is for example a manufacturing device and/or an electromechanical device and/or an electronic device and/or a device of an automation network (e.g. for industrial technological installations, manufacturing installations, energy or resource distribution installations)), each system comprising: a blockchain module comprising smart contracts as a unified automation framework ([0189] corresponding control functions can be realized for example as a smart contract of the network application); and a Merkle tree-based key management module for privacy preservation ([0020] a “checksum”, for example a data block checksum, a data checksum, a node checksum, a transaction checksum, a linking checksum or the like, can be understood to mean for example a cryptographic checksum or cryptographic hash or hash value that is formed or calculated in particular by means of a cryptographic hash function by way of a data set and/or data and/or one or more of the transactions and/or a partial area of a data block (e.g. the block header of a block of a blockchain or data block header of a data block of the distributed database system (or of the network application) or only a portion of the transactions of a data block); a checksum can be in particular (a) checksum(s) or hash value(s) of a hash tree (e.g. Merkle tree, Patricia tree); furthermore, it can also be understood to mean in particular a digital signature or a cryptographic message authentication code; [0095]-[0102] the network application or the distributed database system is for example a blockchain, where the device is embodied for example as a node or an oracle of the distributed database system or of the network application, the cryptographic checksum is for example a digital signature; the device comprises a calculation module (120), for example, wherein the calculation module (120) is designed for example for calculating an object-specific characteristic on the basis of the individual features, the characteristic is calculated for example taking account of predefined tolerance values of the individual features, for example the characteristic and/or the individual features are/is compared with the corresponding reference value, for example in the case of a sufficiently accurate match between the reference value and the characteristic and/or the individual features, the first cryptographic key is released by the cryptography module), wherein the key management ensures information exchange in the system is encrypted prior to data exchange and decryption requiring the joint effort of recipients ([0060] the data of the executability confirmation transaction may also have been exchanged between the transmitter and the receiver before the executability confirmation transaction is stored e.g. in the distributed database system; the executability confirmation transaction can for example also be cryptographically protected (e.g. it can be encrypted or be protected by a transaction checksum); [0201] data structure and the cryptographic checksum are stored in a data set, for example, wherein the data set is stored for example as a transaction in the distributed database system or the network application; for this purpose, the transaction can comprise an additional checksum (e.g. a transaction checksum), which was generated e.g. by means of a cryptographic key (e.g. a private cryptographic key) that is assigned to an entity or is used by the latter). Regarding Claim 20: Paffrath teaches a method comprising: executing control software for a decentralized ([0036] embodiments of the invention, a “network application” can be understood to mean for example a decentralized distributed database, a distributed database system, a distributed database, a peer-to-peer application, a distributed memory management system, a blockchain, a distributed ledger), autonomous multi-robot system for on-demand production ([0056] device is for example a manufacturing device and/or an electromechanical device and/or an electronic device and/or a device of an automation network (e.g. for industrial technological installations, manufacturing installations, energy or resource distribution installations); [0221] ecosystem of devices which interact with one another autonomously by means of a blockchain or network application; in particular, security-protected data processing of sensor data or measurement data for an object is realized by means of embodiments of the invention with a distributed infrastructure (e.g. the network application); fields of application here are supply chain scenarios or industrial control applications of blockchains; [0188] by means of the control functions, it is possible to control parts of a technical installation (e.g. a manufacturing installation) for the object O; this can be the control of a conveyor belt, for example, in order that the object O (e.g. a melting furnace) is supplied with material for melting or the object O (e.g. a manufacturing robot) is supplied with the next part to be manufactured), the system having adaptive and resilience productivity and resource efficiency ([0056] device is for example a manufacturing device and/or an electromechanical device and/or an electronic device and/or a device of an automation network (e.g. for industrial technological installations, manufacturing installations, energy or resource distribution installations)), each system comprising: a blockchain module comprising smart contracts as a unified automation framework ([0189] corresponding control functions can be realized for example as a smart contract of the network application); and a Merkle tree-based key management module for privacy preservation ([0020] a “checksum”, for example a data block checksum, a data checksum, a node checksum, a transaction checksum, a linking checksum or the like, can be understood to mean for example a cryptographic checksum or cryptographic hash or hash value that is formed or calculated in particular by means of a cryptographic hash function by way of a data set and/or data and/or one or more of the transactions and/or a partial area of a data block (e.g. the block header of a block of a blockchain or data block header of a data block of the distributed database system (or of the network application) or only a portion of the transactions of a data block); a checksum can be in particular (a) checksum(s) or hash value(s) of a hash tree (e.g. Merkle tree, Patricia tree); furthermore, it can also be understood to mean in particular a digital signature or a cryptographic message authentication code; [0095]-[0102] the network application or the distributed database system is for example a blockchain, where the device is embodied for example as a node or an oracle of the distributed database system or of the network application, the cryptographic checksum is for example a digital signature; the device comprises a calculation module (120), for example, wherein the calculation module (120) is designed for example for calculating an object-specific characteristic on the basis of the individual features, the characteristic is calculated for example taking account of predefined tolerance values of the individual features, for example the characteristic and/or the individual features are/is compared with the corresponding reference value, for example in the case of a sufficiently accurate match between the reference value and the characteristic and/or the individual features, the first cryptographic key is released by the cryptography module), wherein the key management ensures information exchange in the system is encrypted prior to data exchange and decryption requiring the joint effort of recipients ([0060] the data of the executability confirmation transaction may also have been exchanged between the transmitter and the receiver before the executability confirmation transaction is stored e.g. in the distributed database system; the executability confirmation transaction can for example also be cryptographically protected (e.g. it can be encrypted or be protected by a transaction checksum); [0201] data structure and the cryptographic checksum are stored in a data set, for example, wherein the data set is stored for example as a transaction in the distributed database system or the network application; for this purpose, the transaction can comprise an additional checksum (e.g. a transaction checksum), which was generated e.g. by means of a cryptographic key (e.g. a private cryptographic key) that is assigned to an entity or is used by the latter). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Xu et al (PGPUB 2020/0358600) recites methods providing access control and data privacy/security with decentralized ledger technology. Key information can be stored in the system in a decentralized manner with partial key fragments encrypted and split among system nodes ([abstract]). Carman et al (PGPUB 2002/0199102) recites a system for establishing a cryptographic key between energy-limited nodes ([abstract]). Establishing the cryptographic key at the first node involves creating a hash of the first node's partial key value and the second node's partial key value ([0022]). Bonisch et al (PGPUB 2025/0131825) recites a decentralized control system for the intra-fleet and/or inter-fleet, at least partially self-organized, control of a network formed at least by vehicles comprises a decentralized consensus module, which is designed for transmitting mobility orders, in particular network-external or network-internal transport orders or service provision orders, and/or mobility offers, in particular transport offers or service provision offers, of vehicles of the network, in each case in the form of smart contracts within a distributed ledger technology (DLT) ([abstract]). Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM 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, William Korzuch can be reached at (571) 272-7589. 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. /FORREST L CAREY/Examiner, Art Unit 2491 /WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
Read full office action

Prosecution Timeline

Aug 19, 2024
Application Filed
Sep 30, 2026
Non-Final Rejection mailed — §101, §102 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12762254
DETECTION OF OVER-PRIVILEGED ACCESS PERMISSIONS
5y 4m to grant Granted Oct 13, 2026
Patent 12711250
INFORMATION PROCESSING SYSTEM, INFORMATION PROCESSING APPARATUS, METHOD OF CONTROLLING THE SAME, AND STORAGE MEDIUM
3y 7m to grant Granted Aug 18, 2026
Patent 12696083
Securing Media Stream Communications
4y 5m to grant Granted Jul 28, 2026
Patent 12683928
Hybrid web application firewall
4y 1m to grant Granted Jul 14, 2026
Patent 12647791
METHOD AND DEVICE FOR AUTHENTICATING A PRIMARY STATION
3y 4m to grant Granted Jun 02, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
57%
Grant Probability
99%
With Interview (+55.3%)
3y 8m (~1y 5m remaining)
Median Time to Grant
Low
PTA Risk
Based on 272 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month