Prosecution Insights
Last updated: August 17, 2026
Application No. 18/953,616

System and Method for Granular Application Signatures

Final Rejection §101§103§112
Filed
Nov 20, 2024
Examiner
SARKER, SANCHIT K
Art Unit
2495
Tech Center
2400 — Computer Networks
Assignee
Pc Matic Inc.
OA Round
2 (Final)
79%
Grant Probability
Favorable
3-4
OA Rounds
11m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 79% — above average
79%
Career Allowance Rate
315 granted / 401 resolved
+20.6% vs TC avg
Strong +47% interview lift
Without
With
+46.8%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
18 currently pending
Career history
420
Total Applications
across all art units

Statute-Specific Performance

§101
12.0%
-28.0% vs TC avg
§103
57.0%
+17.0% vs TC avg
§102
4.7%
-35.3% vs TC avg
§112
19.2%
-20.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 401 resolved cases

Office Action

§101 §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 . DETAILED ACTION This Office Action is in response to the Amendment filed on 05/13/2026. In the instant Amendment, claims 1, 5 and 9 have been amended and claims 3-4, 7-8 and 11-12 have been cancelled. Claims 1, 5 and 9 are independent claims. Claims 1-2, 5-6 and 9-10 have been examined and are pending. This Action is made FINAL. Response to Arguments The rejection of claims 1-4 are rejected under 35 U.S.C. 101 are withdrawn as the claims have been amended. The rejection of claims 1-12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, are withdrawn as the claims have been amended. Applicants’ arguments in the instant Amendment, filed on 05/13/2026, with respect to limitations listed below, have been fully considered but they are not persuasive. On page 5, Applicant arguing that Applicant's claim adds rollback information and signature information at build- time and is does not monitor the use of such libraries as does, Amarasinghe but instead, confirms that the code is from a library is legitimate. In response to applicant's argument that the references fail to show certain features of applicant’s invention, it is noted that the features upon which applicant relies (i.e., adds rollback information and signature information at build- time and is does not monitor the use of such libraries) are not recited in the rejected claim. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Further The examiner respectfully disagrees with the applicant’s arguments because Amarasinghe par. 0055-0056 teaches the node manager 430 inserts the constraint libraries, such as DLLs, into all the applications that are protected. The constraints can be deployed in the manner in which signatures (or DAT files) are deployed in an anti-virus system. FIG. 3 identifies components within a single application (e.g., application core 440). A predefined support functions library 350 represents the new constraints that get deployed similar to the way in which a signature of an anti-virus system is deployed, for instance. A managed program execution engine (MPEE) 305 manages the creation and maintenance of the code cache and grantees that all the instructions executed by the program happen within the code cache. See also par. 0144 and 0177. B. On page 6, Applicant also arguing that Fu does not teach “system and method verifies that the provenance of segments of the application were created by a known library”. In response to applicant's argument that the references fail to show certain features of applicant’s invention, it is noted that the features upon which applicant relies (i.e., applicant's claimed system and method verifies that the provenance of segments of the application were created by a known library. For example, if a particular application used OpenSSL version X.X, applicant's novel system and method verifies that the code that has been compiled into the final executable actually came from OpenSSL version X.X, or a version that would have been identically compiled and optimized) are not recited in the rejected claim. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Thus, the amended limitations are still obvious over the prior art of record. Please see amended rejection below for the amended 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 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 of this title, 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-2, 5-6 and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Amarasinghe (US 2011/0185433) and in view of Fu (US 2017/024956). Regarding claim 1, Amarasinghe discloses a system for computer security (Amarasinghe par. 0005; a constraint injection system and technique for protecting software), the system comprising: a first computer having a first processor and a first storage (Amarasinghe par. 0265; The software used for the present invention is stored on one or more processor readable storage devices including hard disk drives. In one embodiment, software implementing the present invention is used to program one or more processors); at least one signed library stored in the storage (Amarasinghe par. 0055; The constraint specific software is represented by a constraint management engine 330, a constraint gateway 340, the predefined support functions library 350, and an external interface for managing constraints 360. The predefined support functions library 350 supplies the common functions libraries that will be used by the constraints, so those functions don't have to be downloaded with each constraint); during manufacture of a program, a digital signature from the at least one signed library and any transformations that are made by a compiler/linker are stored in the program (Amarasinghe par. 0055; The node manager 430 inserts the constraint libraries, such as DLLs, into all the applications that are protected. The constraints can be deployed in the manner in which signatures (or DAT files) are deployed in an anti-virus system. FIG. 3 identifies components within a single application (e.g., application core 440). A predefined support functions library 350 represents the new constraints that get deployed similar to the way in which a signature of an anti-virus system is deployed, for instance. See also par. 0144 and 0177); a computer security program periodically runs on a processor of protected device, the computer security program opens the program and when the computer security program determines that there exist transformations that were recorded and stored in the program, the computer security program rolls back the transformations to create a copy of the program (Amarasinghe par. 0055-0056; A managed program execution engine (MPEE) 305 manages the creation and maintenance of the code cache and grantees that all the instructions executed by the program happen within the code cache. Note that the functionality of MPEE can be used to implement many other capabilities beyond constraint deployment. The constraint specific software is represented by a constraint management engine 330, a constraint gateway 340, the predefined support functions library 350, and an external interface for managing constraints 360. The predefined support functions library 350 supplies the common functions libraries that will be used by the constraints, so those functions don't have to be downloaded with each constraint. An original, unmodified program, which is to receive the constraint, includes a code fragment 321 which has a number of instructions, e.g., instruction A 322, instruction B 324, instruction C 326 and instruction D 328, for instance. The original program refers to the program as it exists before a constraint is injected to protect against attacks. A Managed Program Execution Engine (MPEE) 305 controls the creation and management of a secure code cache 310. See also par. 0073 and 0257 ); the computer security program calculates a hash value of the copy of the program (Amarasinghe par. 0059; A Constraint Management Engine (CME) 330 coordinates with the MPEE 305 so that when the original code fragment 321 is copied from the original program location 320 into the secure code cache 310, it is correctly modified to reflect the modified code fragment 311. See also par. 0073); the computer security program compares the hash check value of the copy of the program with a stored hash value in the digital signature stored in the program and when the hash value of the copy of the program matches the stored hash value in the digital signature stored in the program, the program is allowed (Amarasinghe par. 0059, 0073; The constraint libraries 370 include a detector 372 and a remediator 374, which in turn may call a set of predefined functions from a predefined functions library 350. See section 19. The predefined functions may include, e.g., string copy, string compare, and other functions that multiple constraints may use. The version of the provided module can be compared to the version of the module in memory. If all the checks pass, then, for each patch point in the module (step 630), patch point selection logic is executed (decision block 635). The patch point selection logic relates to matching the constraint application policy (Section 11, below). If the patch point selection logic selects deployment, a hash of the program bits around the patch point is calculated and compared to the provided hash in a hash check (decision block 640). If the hash check indicates a match, the patch point is deployed); and when the hash value of the copy of the program does not match the signature stored in the program, the program is blocked (Amarasinghe par. 0074; The process is completed (step 645) when the module is not loaded (decision block 620), the module versions do not match (decision block 625), the patch point selection logic does not select deployment (decision block 635), or the hash check does not indicate a match (decision block 640). Amarasinghe3KhanKhanKkk teaches3 the computer security program compares the hash value of the copy of the program and when the hash value of the copy of the program matches the signature stored in the program, the program is allowed (Amarasinghe par. 0073-0074). However, Amarasinghe does not explicitly teach the computer security program compares the hash value of the copy of the program with the digital signature stored in the program. However, in an analogous field, Fu teaches the computer security program compares the hash value of the copy of the program with the digital signature stored in the program (Fu par. 0004; In this way, when a manufacturer publishes an application program, hash calculation is performed on data of the application program to obtain a first hash digest of the application program, information about the first hash digest is signed by using a manufacturer private key, to obtain a digital signature of the application program, the digital signature of the application program and the data of the application program are packed as a program package, and then the program package is published. When downloading the program package of the application program, the network device stores the digital signature in the program package to the TPM chip. Subsequently, when the network device starts the application program, the security CPU in the network device performs hash calculation on the data of the application program to obtain a second hash digest of the application program, obtains the digital signature of the application program from the TPM chip of the network device, and decrypts the obtained digital signature by using an embedded manufacturer public key, to obtain the first hash digest of the application program. The first hash digest is compared with the second hash digest. If the two are the same, it is determined that the application program is not tampered with, and integrity verification of the application program passes; otherwise, it is determined that the application program is tampered with, and integrity verification of the application program does not pass. See also par. 0030-0031, 0040 and 0091). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method of compares the check value of the copy of the program with the signature stored in the program of Amarasinghe using compares the check value of the copy of the program with the signature stored in the program taught in Fu in order to determine that integrity verification of the application program passes or does not pass (Fu abstract).7 Regarding claim 2, Amarasinghe and Fu disclose the system of claim 1, Amarasinghe further discloses wherein when the program is blocked, a record of the program is captured and the program is moved to a quarantine area of the protected device (Amarasinghe par 0214; In the case of an access violation, a constraint injection system's exception handler can identify the exception to be related to a constraint, terminate the constraint execution and return to the gateway/prologue-epilogue function with the appropriate status code and let the reminder of the cleanup and bookkeeping be done by that function). Regarding claims 5-6; claims 5-6 are directed to a method associated with the system claimed in claims 1-2 respectively. Claims 5-6 are similar in scope to claims 1-2 and respectively, and are therefore rejected under similar rationale respectively. Regarding claims 9-10; claims 9-10 are directed to a system associated with the system claimed in claims 1-2 respectively. Claims 9-10 are similar in scope to claims 1-2 and respectively, and are therefore rejected under similar rationale respectively. 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 SANCHIT K SARKER whose telephone number is (571)270-7907. The examiner can normally be reached M-F 8:30 AM-5:30 PM. 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, FARID HOMAYOUNMEHR can be reached at 571-272-3739. 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. /SANCHIT K SARKER/Primary Examiner, Art Unit 2495
Read full office action

Prosecution Timeline

Nov 20, 2024
Application Filed
Mar 04, 2026
Non-Final Rejection mailed — §101, §103, §112
May 13, 2026
Response Filed
Jul 24, 2026
Final Rejection mailed — §101, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12705384
NODE AND EDGE DEDUPLICATION FOR A PRIVILEGE GRAPH
3y 1m to grant Granted Aug 11, 2026
Patent 12694137
LOGICAL LOG VISIBILITY CONTROL IN ENCLAVE DATABASE
2y 6m to grant Granted Jul 28, 2026
Patent 12695614
PROCESSOR WITH AN ELLIPTIC CURVE CRYPTOGRAPHIC ALGORITHM AND A DATA PROCESSING METHOD THEREOF
1y 9m to grant Granted Jul 28, 2026
Patent 12675605
SYSTEM AND METHOD FOR A TRUST EVALUATION AND SHARING SYSTEM
1y 8m to grant Granted Jul 07, 2026
Patent 12657328
DATA QUERY METHODS, APPARATUSES, AND SYSTEMS FOR MULTI-PARTY SECURE DATABASE
2y 7m to grant Granted Jun 16, 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

3-4
Expected OA Rounds
79%
Grant Probability
99%
With Interview (+46.8%)
2y 8m (~11m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 401 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