Office Action Predictor
Last updated: April 16, 2026
Application No. 18/720,039

A METHOD FOR MONITORING OR VALIDATING COMPLIANCE OF A DEVICE ON A NETWORK

Non-Final OA §103§112
Filed
Jun 14, 2024
Examiner
BROWN, ANTHONY D
Art Unit
2408
Tech Center
2400 — Computer Networks
Assignee
British Telecommunications Public Limited Company
OA Round
1 (Non-Final)
85%
Grant Probability
Favorable
1-2
OA Rounds
2y 8m
To Grant
98%
With Interview

Examiner Intelligence

Grants 85% — above average
85%
Career Allow Rate
728 granted / 854 resolved
+27.2% vs TC avg
Moderate +12% lift
Without
With
+12.4%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
15 currently pending
Career history
869
Total Applications
across all art units

Statute-Specific Performance

§101
14.4%
-25.6% vs TC avg
§103
48.2%
+8.2% vs TC avg
§102
18.5%
-21.5% vs TC avg
§112
7.0%
-33.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 854 resolved cases

Office Action

§103 §112
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 . Information Disclosure Statement The information disclosure statement (IDS) submitted on 6/14/2024 was filed after the mailing date of the application on 6/14/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(d): (d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph: Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. Claims 13-14 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements. 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. Claim(s) 1-5 and 7-15 are rejected under 35 U.S.C. 103 as being unpatentable over Fortney (US Patent 10,726,000) in view of Natarajan (US Patent 11,334,439). As per claims 1 and 13-15: (Currently Amended) Fortney discloses a method for monitoring or validating compliance of attributes of a device on a network, the method comprising (see abstract): providing a first tree data structure comprising compliance data associated with a network (claim 6; a first Merkle tree may be generated for authenticated software and/or data); performing a comparison of the first tree data structure with a second tree data structure comprising attribute data associated with an electronic device to compare the compliance data with the attribute data (claim 6; a second Merkle tree may be generated for the software and/or data the integrity of which is to be determined. The root hash values of the two Merkle trees may be compared, and if they are the same, the integrity of the software and/or data corresponding to the second Merkle tree may be verified. If the root hash values are different, it may be determined that the software and/or data corresponding to the second Merkle tree have been compromised); and However, Fortney does not specifically disclose determining, based on the comparison, whether the electronic device is compliant with the network (See Natarajan; Col 16, lines 2-9; the receiving node can verify the proof by rebuilding the merkle root hash using the leaves of the received merkle tree and then checking whether the constructed root hash matches with the root hash in the consensus. If there is a match, then the state is not tampered with. If there is a mismatch the hashes in the level nodes can be checked to identity which bucket or leaf node is tampered with). Therefore, it 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, having the teachings of Fortney and Natarajan in it’s entirety, to modify the technique of Fortney for blockchain based Integrity Checks using merkle tree structures by adopting Natarajan's teaching for verify the proof by rebuilding the merkle root hash using the leaves of the received merkle tree and then checking whether the constructed root hash matches with the root hash. The motivation would have been to improve monitoring or validating compliance of attributes of a device on a network. As per claim 2: (Currently Amended) The method according to claim 1, wherein the first tree data structure is a first Merkle tree and the second tree data structure is a second Merkle tree, each of the first Merkle tree and the second Merkle tree comprising a plurality of nodes, each node of the plurality of nodes having an associated hash generated based on the nodes beneath that respective node (claim 6; a first Merkle tree may be generated for authenticated software and/or data. A second Merkle tree may be generated for the software and/or data the integrity of which is to be determined. The root hash values of the two Merkle trees may be compared, and if they are the same, the integrity of the software and/or data corresponding to the second Merkle tree may be verified. If the root hash values are different, it may be determined that the software and/or data corresponding to the second Merkle tree have been compromised). As per claim 3: (Currently Amended) The method according to claim 2, wherein performing the comparison comprises comparing the hashes in the second Merkle tree with the hashes in the first Merkle tree to determine if the hashes in the second Merkle tree are present in the first Merkle tree (See Natarajan; Col 16, lines 2-9; the receiving node can verify the proof by rebuilding the merkle root hash using the leaves of the received Merkle tree and then checking whether the constructed root hash matches with the root hash in the consensus. If there is a match, then the state is not tampered with. If there is a mismatch the hashes in the level nodes can be checked to identity which bucket or leaf node is tampered with). As per claim 4: (Currently Amended) The method according to claim 3, further comprising: if it is determined that a hash is present in the second Merkle tree that is not present in the first Merkle tree, determining the electronic device as being non-compliant with the network (See Natarajan; Col 16, lines 2-9; the receiving node can verify the proof by rebuilding the merkle root hash using the leaves of the received merkle tree and then checking whether the constructed root hash matches with the root hash in the consensus. If there is a match, then the state is not tampered with. If there is a mismatch the hashes in the level nodes can be checked to identity which bucket or leaf node is tampered with). As per claim 5: (Currently Amended) The method according to claim 2, wherein the first tree data structure and the second tree data structure each comprise a probabilistic data structure for evaluating a presence or an absence of one or more hashes associated with the plurality of nodes, the method further comprising using the probabilistic data structures to evaluate the presence or the absence of the one or more hashes (claim 6; a first Merkle tree may be generated for authenticated software and/or data. A second Merkle tree may be generated for the software and/or data the integrity of which is to be determined. The root hash values of the two Merkle trees may be compared, and if they are the same, the integrity of the software and/or data corresponding to the second Merkle tree may be verified. If the root hash values are different, it may be determined that the software and/or data corresponding to the second Merkle tree have been compromised). As per claim 7: (Currently Amended) The method according to claim 2, wherein the attribute data associated with the electronic device comprises one or more hardware attributes or attributes, each node of the second tree data structure representing an attribute of the electronic device (claim 6; a first Merkle tree may be generated for authenticated software and/or data. A second Merkle tree may be generated for the software and/or data the integrity of which is to be determined. The root hash values of the two Merkle trees may be compared, and if they are the same, the integrity of the software and/or data corresponding to the second Merkle tree may be verified. If the root hash values are different, it may be determined that the software and/or data corresponding to the second Merkle tree have been compromised). As per claim 8: (Currently Amended) The method according to claim 2, wherein the compliance data associated with the network comprises one or more hardware attributes or software attributes, each node of the first tree data structure representing an attribute accepted by the network (claim 6; a second Merkle tree may be generated for the software and/or data the integrity of which is to be determined. The root hash values of the two Merkle trees may be compared, and if they are the same, the integrity of the software and/or data corresponding to the second Merkle tree may be verified. If the root hash values are different, it may be determined that the software and/or data corresponding to the second Merkle tree have been compromised). As per claim 9: (Currently Amended) The method according to claim 8, wherein the nodes of the first tree data structure represent all possible attributes of the compliance data accepted by the network (See Natarajan; Col 16, lines 2-9; the receiving node can verify the proof by rebuilding the merkle root hash using the leaves of the received Merkle tree and then checking whether the constructed root hash matches with the root hash in the consensus. If there is a match, then the state is not tampered with. If there is a mismatch the hashes in the level nodes can be checked to identity which bucket or leaf node is tampered with). As per claim 10: (Currently Amended) The method according to claim 1, further comprising updating at least one of the first tree data structure or the second tree data structure to provide at least one of updated compliance data or updated attribute data, respectively, and performing a further comparison of the first tree data structure with the second tree data structure (claim 6; a second Merkle tree may be generated for the software and/or data the integrity of which is to be determined. The root hash values of the two Merkle trees may be compared, and if they are the same, the integrity of the software and/or data corresponding to the second Merkle tree may be verified. If the root hash values are different, it may be determined that the software and/or data corresponding to the second Merkle tree have been compromised). As per claim 11: (Currently Amended) The method according to claim 1, wherein the second tree data structure is provided by the associated electronic device (See Natarajan; Col 16, lines 2-9; the receiving node can verify the proof by rebuilding the merkle root hash using the leaves of the received Merkle tree and then checking whether the constructed root hash matches with the root hash in the consensus. If there is a match, then the state is not tampered with. If there is a mismatch the hashes in the level nodes can be checked to identity which bucket or leaf node is tampered with). As per claim 12: (Currently Amended) The method according to claim 1, further comprising interrogating the electronic device to determine the attribute data, and forming the second tree data structure based on the determined attribute data (claim 6; a second Merkle tree may be generated for the software and/or data the integrity of which is to be determined. The root hash values of the two Merkle trees may be compared, and if they are the same, the integrity of the software and/or data corresponding to the second Merkle tree may be verified. If the root hash values are different, it may be determined that the software and/or data corresponding to the second Merkle tree have been compromised). Claim(s) 6 is rejected under 35 U.S.C. 103 as being unpatentable over Fortney (US Patent 10,726,000) in view of Natarajan (US Patent 11,334,439) and in view of Haddad (US Patent Pub. 2012/0322413). As per claim 6: (Currently Amended) The method according to claim 5, wherein the first tree data structure and the second tree data structure each comprise a probabilistic data structure for evaluating a presence or an absence of one or more hashes associated with the plurality of nodes, the method further comprising using the probabilistic data structures to evaluate the presence or the absence of the one or more hashes (claim 6; a first Merkle tree may be generated for authenticated software and/or data. A second Merkle tree may be generated for the software and/or data the integrity of which is to be determined. The root hash values of the two Merkle trees may be compared, and if they are the same, the integrity of the software and/or data corresponding to the second Merkle tree may be verified. If the root hash values are different, it may be determined that the software and/or data corresponding to the second Merkle tree have been compromised). The combination of Fortney and Natarajan does not specifically disclose wherein the probabilistic data structure comprises a bloom filter (See Haddad; claim 3; wherein the compact representation of verification data of all nodes in the network comprises one of a Bloom Filter and a root of a Merkle tree derived from the verification data of all nodes in the network). Therefore, it 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, having the teachings of Fortney, Natarajan and Haddad in it’s entirety, to modify the technique of Fortney for blockchain based Integrity Checks using merkle tree structures by adopting Haddad's teaching for the representation of verification data of all nodes in the network comprises one of a Bloom Filter and a root of a Merkle tree. The motivation would have been to improve monitoring or validating compliance of attributes of a device on a network. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANTHONY D BROWN whose telephone number is (571)270-1472. The examiner can normally be reached 730-330pm. 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, Linglan Edwards can be reached at 5712705440. 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. /ANTHONY D BROWN/Primary Examiner, Art Unit 2408
Read full office action

Prosecution Timeline

Jun 14, 2024
Application Filed
Sep 26, 2025
Non-Final Rejection — §103, §112
Apr 11, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12598177
THREE-DIMENSIONAL DENSITY KEY AUTHENTICATION
2y 5m to grant Granted Apr 07, 2026
Patent 12592921
ENCODED IDENTIFIERS FOR CREDENTIAL ACCESS AND DISTRIBUTION
2y 5m to grant Granted Mar 31, 2026
Patent 12592933
SYSTEMS AND METHODS FOR MANAGING RESOURCE ACCESS PERMISSIONS
2y 5m to grant Granted Mar 31, 2026
Patent 12592969
METHOD AND SYSTEM FOR PROTECTING SERVERLESS CLOUD ARCHITECTURE USING HONEYPOTS
2y 5m to grant Granted Mar 31, 2026
Patent 12587394
IDENTITY SERVICES AND AUTHENTICATION IN DISTRIBUTED NETWORKS
2y 5m to grant Granted Mar 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
85%
Grant Probability
98%
With Interview (+12.4%)
2y 8m
Median Time to Grant
Low
PTA Risk
Based on 854 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

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

Free tier: 3 strategy analyses per month